절대 코딩하지 마라

"코딩은 늦게 할수록 프로젝트가 빨리 끝난다."

대부분의 개발자들은 이 말을 제대로 이해하지 못한다. 그래서 프로젝트 일정이 촉박하면 무조건 코딩부터 시작하곤 한다. 코딩을 빨리 시작하면 프로젝트가 빨리 끝날 것으로 믿곤 한다. 말은 그렇게 하지 않더라도 일정이 부족하면 문서 작성할 시간도 없고 무조건 코딩부터 시작한다.

물론 프로젝트에 따라서 대충해도 되는 경우가 많다. 그런 프로젝트를 예로 들어서 모든 프로젝트에 확대 적용하지는 말자. 즉, 개집은 어떻게 만들어도 다 되는 것이다. 

코딩 시작은 빨리 시작할수록 재작업은 급속히 늘어난다. 코딩을 최대한 뒤로 늦춤으로써 재작업 가능성을 낮춘다. 물론 스펙이 완전히 끝나야 코딩을 시작할 수 있는 것은 아니다. 스펙을 합리적으로 작성하는 요령 중 하나가 미리 확정할 수 있는 라이브러리나 Sub system들은 인터페이스를 미리 확정하고 코딩을 먼저 시작할 수 있다.

보통 프로젝트에서 분석을 해보면 코딩부터 할 수 없다는 것을 알게 된다. 코딩부터 시작하는 경우는 무엇을 개발할지도 모르고 코딩을 시작하는 것이다. 그렇게 미리 작성된 코드는 스펙이 정해지면 버리고 다시 짜야 하는 경우가 많다. 아키텍처에 요구사항이 제대로 반영되지 않는다. 그럼에도 미리 코딩을 해 놓으면 코드를 버리기가 아까워서 그냥 사용하게 된다. 그러다보면 아키텍처는 엉망이 된다.

개발자들은 자신이 작성한 코드를 살리기 위해서 요구사항을 거부하기도 하고 코드에 꼼수를 부리기도 한다. 

가끔은 코딩만하기에도 정말 일정이 부족한 프로젝트들이 있다. 이런 경우도 코딩부터 한다고 프로젝트가 빨리 끝나는 것은 아니다. 무모한 시도를 하는 것이다. 스펙을 작성할 시간도 없는 프로젝트는 안하는 것이 낫다. 그렇다고 회사에서 프로젝트를 거부할 수는 없다. 최대한 빨리 스펙을 써서 합리적으로 가능한 일정와 범위를 제시하는 것이 더 좋은 방법이다.

일정이 촉박하다고 매번 코딩부터 시작하면 10년을 개발해도 별로 나아지는 것이 없을 것이다.

주석을 달기 어려운 이유

코딩을 하면서 주석을 적절히 잘 달아야 한다는데는 이견이 없을 것이다. 하지만 현실은 주석이 제대로 달린 코드를 찾아보기 어렵다.

"주석이 제대로 달렸다"의 애매한 기준을 명확하게 정리해보면 다음과 같습니다.

• 과도한 주석은 나쁘다. 비용이 너무 많이 들어간다.
• 소스코드를 활용하고 유지보수하는데 어려움이 없어야 한다.
• 업데이트가 되어서 소스코드와 일치되어야 한다. 
• 전체적으로 일관된 표준을 지켜야 한다.  

주석하나 없이 깨끗한 소스코드나 있어도 소용없는 주석은 개발에 보통 어려움이 있는 것이 아니다. 약간의 시간을 투자해서 주석을 달게 되면 투자대비 몇배의 효과를 볼 수 있다.

그럼 가장 효과적으로 주석을 다는 방법에 대해서 알아보자.

회사의 주석 표준을 정한다.

Doxygen이나 Javadoc등의 표준 주석 Notation을 따르면 여러 툴의 많은 도움을 받을 수 있고 가독성이 높아진다. 신입사원이 들어와도 널리 알려진 표준이므로 쉽게 따라할 수 있게 된다.

주석은 소스코드보다 먼저다.

주석은 코딩하면서 짬짬히 다는 것이 아니다. 코딩 이전에 설계 시 Public function을 정의하면서 주석을 먼저 작성한다. 이렇게 설계를 해서 완벽할 때 구현(코딩)에 들어가면 된다.
코딩을 하면서 Public interface가 자주 바뀌면 주석도 바꾸기 매우 귀찮아지게 된다.
하위 설계는 코드와 주석을 적당히 이용하게 되면 문서로 작성할 필요가 없이 대부분 소스코드로 작성할 수 있다.

Public function 위주로 주석을 단다.

모든 소스코드에 주석을 달아야 한다고 하면 헬스클럽 1년 끊어 놓고 일주일 운동하고 포기하는 사태가 발생하게 된다. 당장 바쁜데 언제 시간을 내서 주석을 달 수 있겠는가? 
Public function은 다른 개발자들이 가장 빈번하게 참조를 해야 할 함수들이다. 같은 시간에 주석을 달아서 가장 효율성이 높다. 
하지만 모든 함수가 Public function이라면 효과도 없고 프로그램은 뒤죽박죽이 된다. 미리 Public function을 정하게 되면 최소화를 할 수 있다. 가능하면 거의 모든 함수를 속으로 숨기고 밖으로 최소한의 Interface만 open할 경우 프로그램도 간결하게 되고 유지보수도 쉬워진다. 
Doxygen이나 JavaDoc을 이용하면 API 메뉴얼이 근사하게 나오게 된다. 이 문서만 봐도 개발자들이 개발하는데 대단히 큰 도움을 준다.
이는 소스코드와 주석/설계문서를 지속적으로 일치 시키는데 지대한 도움을 준다.

주석같은 소스코드가 좋다.

복잡한 소스코드를 작성하고 주석으로 설명하는 것보다는 약간 효율이 떨어져도 가독성 높게 소스코드를 풀어서 쓰는 것이 좋다. 따라서 함수의 크기는 작게 유지하면서 읽어 내려가기 쉽게 작성하는 것이 좋다.
성능에 목숨거는 알고리즘을 개발하는 것이 아니라면 가독성 높은 소스코드를 작성하는 것을 높은 우선순위로 두는 것이 좋다. 왜냐하면 소스코드는 개발비보다 유지보수비가 몇배 더 들기 때문이다.

Prototyping 시에는 주석이 필요없다.

Prototyping한 소스코드는 버려야 한다. Prototype은 주석도 없고 에러처리도 안하고 가장 빠르게 검증을 해보는 것이다. 제품화 할 코드는 이것보다 몇배의 시간이 더 걸린다. 따라서 Prototyping을 한 소스코드는 꼭 버리고 제대로 설계를 해서 다시 만들어야 한다. 단, 참조는 가능하다.

처음에는 강제화가 필요하다.

강제화를 위해서는 리뷰가 필수이다. 코드 리뷰보다는 설계 리뷰가 중요하다. 설계 단계에서 대부분의 Public interface의 주석을 미리 완성하고 코딩에 들어가면 협업도 원활하고 재작업도 줄어든다. 그리고나서 코딩단계에서의 주석은 크게 강조하지 않아도 될 것이다.
규칙으로 무조건 주석을 달라고 강제하는 것보다는 정공법으로 분석/설계 리뷰를 통해서 설계가 끝났을 때 주석이 이미 달린 소스코드 헤더가 나오는 것이 좋다.


무조건 코딩부터 달려드는 것보다는 한번 더 생각해보고 Public interface를 먼저 정의하고 주석을 작성해서 리뷰하고 코딩을 하는 것이 전체 개발시간을 현저하게 단축 시켜준다. 시간이 없어서 주석도 없는 코딩만 마구 해대는 것은 핑계에 불과하다. 

효과적으로 주석을 다는 습관을 가지고 있다면 여러 동료들에게 사랑을 받고 후배들의 존경을 받을 것이다.

Copy & Paste의 종말

직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.

그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.