안정적인 소프트웨어를 작성하는 데는 여러 가지 고민해야 될 사항이 있겠지만,
그 중 딱 2가지만 고르라고 한다면,
하나는 '설계'를, 그리고 다른 하나는 'Unit test'를 고를 것 같습니다.
(설계...)
초기에 프로젝트를 할 때였죠.
왜 그런지 몰라도, 항상 프로젝트는 시간이 부족합니다.
팀장님은 몇 달 만에 이 프로젝트를 완료해야 한다고 하시죠.
급한 마음에 팀장님은 대충 윤곽만 잡고는
모듈을 하나씩 떼어 주십시오.
새내기의 급한 마음에 코딩을 시작합니다.
며칠이 지나니 뭔가가 돌아가고, 순조로워 보입니다.
그런데 조금 가다 보면 질문들이 자꾸 생겨나기 시작합니다.
이 ID는 무슨 의미죠? 이 table은 누가 관리하는 거예요?
팀장님은 팀원들을 모아 회의를 시작합니다.
"선배님, 이 ID가 그런 의미였어요? 제가 작성한 코드 다 고쳐야겠는데요. 이런~"
"어 그 table은 내가 관리하고 있었는데, 자네도 작성한 거야? 시간도 없는데"
작성한 코드를 많이 수정해야 하지만
이렇게 모여서 한 번 정리를 하면 조금 더 나아갈 수 있게 됩니다.
그러나 얼마 가지 않아 또 질문들이 생기게 되죠.
회의를 하고, 코드를 고치고,
또 질문이 생겨나고,
문제는 후반부로 가면 갈수록 수정해야 되는 코드의 양이 늘어난다는 거죠.
이런 방식으로 몇 번의 프로젝트를 하고는 깨달은 것 같습니다.
'해결해야 하는 문제는, 언젠가는 해결해야 하는 것이고...'
'조금 일찍 해결할수록, 다시 작성해야 하는 코드의 양은 주는 것이고...' 하하
몇 년 동안의 고생 끝에,
요즘은 '충분히 설계'를 한 후에, 코딩을 시작해야 한다고 용기를 냅니다.
설계란 거창해 보이지만, 결국 '생각할 수 있는 모든 질문에 답을 하는 것' 뿐입니다.
그러면, '충분한 설계'란 어디까지 일까요?
그건 설계하는 사람의 능력마다 다르다고 생각합니다.
'자신이 감당할 수 있을 만큼 상세하게' 가 답에 가깝지 않을까 합니다.
천재라서 모든 코드 레벨까지 다 설계할 수 있으면 좋겠지만,
저의 경우에는 그런 것은 상상하지도 못하죠.
완벽한 설계가 100이라고 했을 때 80~90정도 가면, 더 이상 복잡해서 설계할 수 없게 됩니다.
그러면 코딩을 시작합니다.
근데 코딩을 하다 보면, 설계의 잘못 된 부분이나, 비효율적인 면들이 보이죠.
그러면서 나머지 10~20의 설계를 완성시키게 되는 것 같습니다.
그나마 다행인 것은, 설계의 고통스러운 노력 덕분에
코딩은 거의 한 번에 할 수 있으니,
그 시간을 상당히 즐길 수 있다는 것이겠죠.
게다가 덤으로,
깔끔하고 안정적인 코드와
훌륭하게 설계된 소프트웨어를 얻게 되는 것 같고요.
근데, 시간이 부족한 프로젝트에서 충분한 설계를 할 수가 있는 건가요?
제 경험상, 안타까운 일이지만
잘못 스케줄링 된 프로젝트는 대부분 D-Day를 넘기게 되더라고요.
D-Day를 한참 지나서야, 시작부터 제대로 했었으면 하고 돌아보게 되죠.
어차피 D-Day를 넘길 무리한 프로젝트라면,
겉으로는 몰라도, 속으로는 설계에 충분한 시간을 보내는 것이
그 프로젝트의 성공에 진정으로 도움이 되는 일이라고 생각합니다.
이때 필요한 것이 용기와 지혜이겠죠.
사실 어려운 일입니다.
하지만, 해볼만한...
고맙습니다.
