2007년 07월 30일
전체적인 코드 수정의 아이러니
다른 사람이 짠 코드(그것도 여러 사람이 건드려 놓은 코드)를 보게 되는 일(그리고 수정까지 해야되는 일)이 생겼다.
코드를 분석해보니 이거 영 엉망으로 짜여져 있(는 것 같)다. (물론 코드를 짜놓은 사람들의 잘못만은 아니겠지?)
이때부터 고민이 시작된다.
이걸 어찌해야하나.....
문득 <소프트웨어 공학의 사실과 오해>에 나온 말이 떠오른다.
만약 컴포넌트의 20~25% 이상을 수정하고자 한다면 차라리 처음부터 다시 작성하는 것이 더 효율적/효과적이다.- 소프트웨어 공학의 사실과 오해 中 -
역시 Paromix군이 생각한데로 다시 구현해버릴까? 시간이 좀 걸리긴 하겠지만 깔끔하게 짤 수 있을 것 같은데 말이지.
그런데 문득 <조엘 온 소프트웨어>에서 조엘님이 밝힌 의견이 떠오른다.
프로그래머가 항상 코드를 버리고 새로 시작하기를 원하는 미묘한 이유가 있습니다. 이런 이유는 예전 코드가 엉망진창이라는 생각 때문입니다. 그런데 이런 생각은 거의 틀리다는 흥미로운 관찰 결과가 있습니다. 예전 코드가 엉망진창이라는 생각은 다음과 같이 기본적이며 근원적인 프로그래밍 법칙 때문에 생깁니다."코드 쓰는 작업보다 읽는 작업이 더 어렵다"- 조엘 온 소프트웨어 中 -
하하. 이거 고민된다.
요새 이 문제로 머리 꽤나 아파하는 Paromix군. 물론 약간 다른 상황이긴 하지만 말이지. :D
"Paromix"
# by | 2007/07/30 00:59 | □■ 프 로 그 램 ■□ | 트랙백 | 핑백(2) | 덧글(11)





☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
... 0 metoo Code review를 할 때마다 하게 되는 고민. 요걸 요렇게 바꾸면 좋을 것같은데. 요것도. 저것도. 이러다 넷스케이프 꼴 나는 건 아니어야 할텐데... 오후 11시 18분 ... more
... 빠르고 더 심플한 launcher, Namely 오후 11시 6분 참 기발하다. launchy를 이용한 각종 팁 오후 11시 7분 Code review를 할 때마다 하게 되는 고민. 요걸 요렇게 바꾸면 좋을 것같은데. 요것도. 저것도. 이러다 넷스케이프 꼴 나는 건 아니어야 할텐데… 오후 11시 18분 이 글은 cychong님의 미투데이 2 ... more
사람이 경험이나 생각이 그때그때 바뀌고 좋은 방향으로 자라기 때문이죠.
그냥 내가 해오던것과 다를뿐이죠. 계속 보다 보면 익숙해지고, 익숙하면 자기가 아는것이 되는거죠.
블럭단위로 이해가 가능한 정도라면 그냥 두는게 좋지 않을까 하는 생각입니다.
물론, 시간이 허락한다면(분석,개발,디버깅,배포) 다시 하는게 더 좋겠죠.^^;
그냥 허접한 제 의견입니다.ㅎㅎ
스팟 님 // 자신이 짠것도 나중에 보면 엉망이라는데 저도 한표.^^ 시간이 허락하지 않아서 (제 메인업무가 따로 있었거든요^^) 일단 구조는 그대로 두고 다음 릴리즈에 뒤집어 버리기로 결정했답니다.^^
비공개 님 // 있던 코드에 추가로 구현하는 일이었답니다.^^
저는 이럴때 이 컴포넌트를 얼마나 오래 사용할 건가를 한번 생각해보곤 하죠.
1주일 지나면 저절로 답이 나옵니다.
이전의 자신과 비교하는 것이 참 어렵고, 간지러운 일입니다.
당황스럽기도 하죠. 이전의 내가 지금보다 더 현명했다는 사실을 깨달았을때... 흑~
그래서 제가 짠 코드를 보고 한참을 고민했습니다. 왜 이렇게 짜놨을까 하는 -_-
그래도 큰 문제없이(알려진 오류 없이) 잘 동작하는 코드라 잠시 고민을 했는데 일단 저질렀습니다.
일주일 내내 코드 좀 수정하고 블럭 시험해서 결국 지난 주에 check-in을 했습니다.
Netscape가 망한 이유중의 하나가 그거라고 들었습니다. 어느 순간 코드를 새로 짜야겠다고 맘을 먹고나서부터 일정을 전혀 맞추질 못했다고.
하지만 일정 지연없이 수정이 가능하다고 생각했고(그들도 그렇게 생각했지만) 앞으로 추가될 기능을 생각하면 구조를 다져놓은 것이 두고두고 편할 거라고 생각했습니다. 큰 문제가 없길 바랄 뿐입니다. 실은 시간날때마다 regress test를 해야죠 :-)
멤피스 님 // 반갑습니다.^^ <조엘 온 소프트웨어>에서 코드를 다시 짜지 말아야한다고 주장하는 근거로 네스케이프를 예를 들고 있죠.^^ 일정이 지연되지 않는 선에서 꾸준히 최대한 손보고 있답니다.^^ 회귀 테스트 이게 중요한데 말이에요. 좋은 말씀 감사드립니다.