[패턴을 활용한 리팩터링] 3,4 장

[책읽는잉여]

3,4 장 내용에 대한 온라인 토론을 시작합니다~

[책읽는잉여]

3,4 장 내용은 아니지만 이야기 나누어 봤음 하는 것이 있어서 글을 개시합니다.

현재 유지 보수 중인 프로젝트의 소스 코드를 보면

코드를 수정하면서 기존 코드를 그대로 주석으로 남겨둔 부분들을 자주 보게 됩니다.

형상관리 툴을 사용하고 있음에도 수정 후 버그로 인한 롤백 필요 또는

언젠가 기존 코드 조각 중 필요한 것이 있을 지 모른다는 불확실성에 대한 불안감이 작용한게 아닌가 싶은데요.

전 이런 주석으로 남겨진 코드 조각들은 주석의 의미를 퇴색시켜버리고

프로젝트 곳곳에 쌓여가는 부채로 보는데요.

여러분의 생각은 어떠신가요.

[이 성민]

 그 부분에 대해서는 심히 공감하며, 저 그리 좋게 보지는 않습니다.

 예전에 있던 회사에서 그러한 주석이 상당히 많이 있었죠. 임시로 테스트를 위해 넣었던 코드를 나중에 다시 쓰기 위해 주석처리 한것도 있었고, 어떠한 이유로 주석 처리를 한건지 멘트를 남기지 않은 코드 주석들도 있었습니다. 이러한 것은 나중에 다른 사람이 보았을때 혼동을 주기 쉽더군요. 그리고 그러한 주석들은 대부분 롤백은 되지 않고 여기저기 난잡하게 존재하게 되었으며, 관리 자체를 할 수가 없어 코드의 가독성을 더욱 떨어트리는 원인이 되기도 하였습니다.

 그리고 다른 팀으로 옮기고 난 후 그 팀에서는 롤백을 위한 코드를 주석 처리 보다는 전처리문을 사용하였습니다. 그리고 주기적으로 전처리에 의해 사용하지 않게 된 코드는 삭제를 해 주는 작업을 했었습니다. 팀에서 이러한 방식을 사용 했었던 이유가 수정사항 적용 후 문제 발생시 빠른 롤백을 위함이라고 하더군요. 하지만 이 방법도 나중에는 문제가 되었습니다. 삭제를 할때에는 해당 작업자가 주도적으로 삭제를 해야만 했으며, 삭제를 하였더라도 논리적인 의존성 문제로 빌드 오류가 나게되어 추가적인 작업이 필요하게 되었습니다. 그러다가 삭제 주기가 조금씩 미루어지면서 점점 쌓여가게 되었고, 결국에는 아무도 손 댈 수 없는 #define 목록과 #ifdef #endif의 비활성 코드가 잔뜩 존재하게 되어 코드 가독성 문제와 관리 자체를 할 수 없게 되었습니다.

2013. 6. 5., 오전 10:23, 책읽는잉여 <sys...@gmail.com> 작성:

--
Google 그룹스 'GameCodi Study Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 gamecodi-study-g...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.
 
 

[책읽는잉여]

3 장에 나오는 Bobby 와 John 의 이야기는 한 번쯤 생각해 볼 필요가 있다는 생각이 듭니다.

패턴에 대한 이해 정도가 패턴에 기초한 리팩터링에 대한 인식에 큰 영향을 주며, 저자의 관점은

'나는 팀 구성원 전체가 패턴을 너무 복잡한 것으로 보고 배우기를 피하기보다다는, 패턴을 배우기를 바란다.'

라고 하고 있습니다.

Bobby - John 의 이야기와 유사한 경험이 있으시면 해당 사례에 대해 공유하고 이야기를 나누어 보면

좋을 것 같습니다. 혹은 이러한 상황에 대한 자신의 견해를 이야기 해보는 것도 좋겠습니다.

2013년 5월 31일 금요일 오후 2시 8분 1초 UTC+9, 책읽는잉여 님의 말:

[날자고도]

디자인패턴을 접근하는 철학의 문제가 아닌가 싶네요.

프로그래밍을 할때 어떤해결해야할 문제들이 있습니다.

사람마다 저 나름대로 문제를 해결하지만, 

일정하게 비슷한 방법으로 해결을 하게 되죠.

문제의 해결방법은 사람마다 크게 다르지 않습니다.

디자인패턴이란것은 배우고 학습하는것이 아니라,

사람마다 문제해결방법을 팀원과 의견을 주고 받아야 하는데,

대화상에서 코드를 설명하기에는 난감한 면이 있습니다.

디자인패턴이란것은 자신의 문제해결방법에 대한 네이밍일뿐입니다.

비슷한예로 웹2.0이라던지, ajax등이 있습니다.

웹2.0이라고 표명하기 이전에도 그와 같은 방법을 사용하고 있었으며,

ajax또한 마찬가지입니다.

자바스크립트와 서버사이드언어등의 조합을 통해서 이전에도 사용해왔지만,

그러한 기술에 대해서 대화를 주고받을려면 적절한 네이밍이 필요합니다.

다시 디자인패턴을 얘기하자면, 디자인패턴에 대해서 학습한다는것은

이전에 자신이 어떤 문제해결방법에 대해서 사람들이 이름을 지었는데,

그 이름에 대한 학습정도라고 할수 있죠.

문제해결에 대한 이름을 모르면, 팀원이 잘못된 방법으로 문제해결을 할때,

그 방법보다는 OO가 더 낫다라는 의견을 주고 받기가 힘듭니다.

디자인패턴을 암기하고 사용하는것이 아니라,

어떤문제에 대해서 자신은 어떤 방식으로 해결하려고 하지만,

다른 방법이 있는지 참고정도가 맞지 않을까 하네요.

자신의 프로젝트에 대한 해결책은 꼭 맞춤의 패턴은 책에는 없을테니깐요.

2013년 6월 8일 토요일 오전 10시 57분 55초 UTC+9, 책읽는잉여 님의 말:

[책읽는잉여]

책의 서두에서도 언급하듯이 패턴의 결과적 모습 자체를 암기하는 것은 경계해야 하지만,

패턴이 도출되게된 과정에 집중한다면 패턴의 공부는 권장할 만한 일이라고 생각합니다.

패턴에는 그 패턴이 도출되기 까지 많은 사람들의 노력과 지혜가 담겨있다는건 사실이니까요.

[책읽는잉여]

크로스님 발표 자료 올려주세요~

2013년 5월 31일 금요일 오후 2시 8분 1초 UTC+9, 책읽는잉여 님의 말:

3,4 장 내용에 대한 온라인 토론을 시작합니다~

[책읽는잉여]

8 일 스터디에서 잠시 이야기 했던

switch ~ case 문을 delegator 로 바꾸는 부분의 예제 코드를 작성해 보았습니다.

switch ~ case

class IDialog;
class IControl
{
public:
long m_id;
};
class Page
{
IDialog* m_pDlg;
void OnUIEvent(IDialog* pDlg, IControl* pCtrl, unsigned int nEvent);
void event_function1( void );
void event_function2( void );
void event_function3( long l );
void event_function4( long l );
/*...*/
};
void Page::OnUIEvent(IDialog* pDlg, IControl* pCtrl, unsigned int nEvent)
{
switch(pCtrl->m_id)
{
case 0:
event_function1();
break;
/*...*/
default:
break;
}
}

function map

using std::function;
using std::bind;
using std::unordered_map;
class IDialog;
class IControl
{
public:
long m_id;
};
class Page
{
IDialog* m_pDlg;
unordered_map<unsigned int, function<void()>> event_handle_map;
unordered_map<unsigned int, function<void(long)>> event_handle_map2;
void InitEventHandler();
void OnUIEvent(IDialog* pDlg, IControl* pCtrl, unsigned int nEvent, long nInfo);
void event_function1( void ) {}
void event_function2( void ) {}
void event_function3( long l ) {}
void event_function4( long l ) {}
/*...*/
};
void Page::InitEventHandler()
{
event_handle_map[0] = bind(&Page::event_function1, this);
/*...*/
}
void Page::OnUIEvent(IDialog* pDlg, IControl* pCtrl, unsigned int nEvent, long nInfo)
{
do {
unordered_map<unsigned int, function<void()>>::iterator it = event_handle_map.find(pCtrl->m_id);
if(it != event_handle_map.end())
{
it->second();
break;
}
unordered_map<unsigned int, function<void(long)>>::iterator it2 = event_handle_map2.find(pCtrl->m_id);
if(it2 != event_handle_map2.end())
{
it2->second(nInfo);
break;
}
} while(0);
}