프로덕트 잘 만들려면?

한 번 만들고 말 거라면 잘 돌아가게만 하면 된다. 하지만 계속 발전 시킬려면 잘 만들어야 한다. 잘 만든다는 것은 참 어려운 일이다. 하지만 몇 가지를 지키면 잘 만들었다는 목표에 도달할 수 있는 듯 하다.

1. 코드 읽기가 쉬워야 한다. 하나의 프로젝트가 여러 사람 손을 거칠 수 있기 때문에 일단 코드 읽기가 쉬워야 한다. 너무 단축화 된 코드는 분석이 쉽지 않다.

2. 리팩토링은 별도가 아니라 지속적이어야 한다. 프로젝트 완료하고 리팩토링을 하는 것이 아니라 지속적인 리팩토링을 수행해야 한다. 이를 위한 방법에는 코드 리뷰가 있지만 가장 중요한 것은 개발자 스스로의 마음가짐이다. 개발을 하다보면 의욕이 떨어지는 날이 있다. 그 날 짠 코드를 이후에 보면 마음에 들지 않을 때가 있을 것이다. 그럴 때는 지체없이 수정을 해야한다. 귀찮음 혹은 일정의 압박 때문에 패스하고 리팩토링 기간 때 해야지 생각하면 못한다. 절대.

3. 주석을 잘 기록하고 습관화 시키자. 기획이나 디자인 이슈로 인해 억지스런 코딩이 들어갈 수 있다. 그럴 때는 꼭 주석으로 이러한 이슈로 이렇게 개발되었다는 코멘트를 적어 주는 것이 좋다. 별도의 문서화는 크게 도움이 되지 않는다. 관리도 쉽지 않다. 대신 주석으로 기록하면 관리도 쉽고 별도 문서화의 귀찮음을 겪지 않아도 된다. 더불어 개발 팀장이나 관리자 역시 코드의 주석을 좀 보면 좋겠…

4. 형상관리. svn이나 git은 대부분의 개발자분들이 사용하니 그 부분에 대한 얘기는 제외하고. commit 시 comment를 좀 상세하게 적었으면 좋겠다. 단순한 수정이더라도 어떤 부분을 수정했는지 comment만 봐도 알 수 있을 정도면 이후 rebase할 때도 많은 도움이 된다. 나도 코딩에 집중했을 때는 잘 까먹는 부분이기도 한데 commit은 잘게잘게 자주하는 것이 좋은 듯 하다. 여러 파일 한꺼번에 commit 하면 디버깅 시 너무 힘든 케이스가 많더라.

5. 기획서의 의존은 금물. 개발자도 사람이다보니 코딩하다보면 실수한다. 기획자도 실수하고 디자이너도 실수한다. 이 전제를 봤을 때 리뷰할 때 미쳐 발견하지 못했더라도 뭔가 이상하거나 문제가 있으면 바로 피드백을 해야한다. 기획서가 그리 정의되었으니 그 정의대로 코딩을 한 나는 잘못이 없다라고 면책을 주장해도 책임을 피할 수는 없다. 요즘 개발자 구인을 잘 살펴보면 “커뮤니케이션”에 대한 항목이 요구사항에 있는데 ‘난 시키는대로 잘 하고 화를 안내기 때문에 커뮤니케이션에 대한 문제는 없어’ 라고 생각하는 분들이 종종 있는데 그들이 원하는 커뮤니케이션은 그런 뜻이 아니다. 기획서 내용의 오류를 잡아내는 것도 개발자들의 업무 중 하나라고 생각한다. 사실 귀찮긴 하다.

대충 이렇게 나열해봤다. 더 있을 수도 있지만 최소한 저 5가지만 지켜도 프로젝트가 산으로 가진 않더라. 물론 외압이 없을 때의 가정이지만…

Show your support

Clapping shows how much you appreciated YoonBong Kim’s story.