나쁜 코드
나쁜 코드는 고행(wading)이라 부른다.
80년대 후반 킬러 앱 하나를 구현한 회사가 있었는데, 제품 출시 주기가 점점 늘어지더니 얼마 못가 망했다.
회사가 망한 원인은 바로 나쁜 코드 탓이었다.
- 출시에 바빠 코드를 마구 짰음
- 기능을 추가할수록 코드는 엉망이됨
- 결국 감당 불가능해짐
리팩토링을 나중으로 미루고 쓰레기 코드를 작성하면 안된다.
이는 르블랑의 법칙(Leblanc's Law) 때문이다.
르블랑의 법칙이란 "나중은 결코 오지 않는다."라는 법칙이다.
좋은 코드를 짜기 위해서 고민하지 않는다고 프로젝트 개발 속도가 빨라질까? - 아니다.
오히려 나쁜 코드를 작성하면 프로젝트 초반에는 번개처럼 나아가다 1-2년만에 굼뱅이처럼 기어간다.
태도
프로젝트 기간이 짧아서, PM이 재촉한다고 좋은 코드를 작성하지 않으려 한다는 것은 전문가적인 태도가 아니다.
환자가 의사에게 손을 씻지 말고 수술해달라 부탁한다고해서 손을 씻지 않고 수술하는, 전문적이지 않는 의사가 어디 있을까? 개발자 또한 마찬가지여야 한다.
좋은 코드를 사수하는 것은 바로 우리 프로그래머의 전문성이자 책임이다.
원초적 난제
결국 나쁜 코드를 작성해도, 좋은 코드를 작성해도 마감 기한을 지키기 힘든게 사실이다.
나쁜 코드를 양산하면 엉망진창에다가 기한도 맞추지 못하니, 언제나 코드를 최대한 깨끗하게 유지하는 습관이 기한을 맞추는 적절한 방법이다.
깨끗한 코드
깨끗한 코드를 작성하는 개발자는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 일치한다.
여러 개발자가 생각하는 깨끗한 코드를 종합하면 다음과 같다.
- 우아하고 효율적인 코드
- 의존성을 최대한 줄인 유지보수가 쉬운 코드
- 단순하고 직접적인 코드
- 작성자가 아닌 사람도 읽기 쉽고 고치기 쉬운 코드
- 적절한 테스트 케이스가 존재하는 코드
- 모든 것을 명확하게 최소화한 코드
- 주의 깊게 짰다는 느낌을 주는 코드
- 고치려고 살펴봐도 딱히 손 댈 곳이 없는 코드
- 중복이 없는 코드
우리는 저자다
Javadoc에서 @author 필드는 저자를 소개한다. 즉, 우리는 저자이고 독자는 어딘가에 존재한다.
저자에겐 독자와 잘 소통할 책임이 있다.
새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
또한 새로 코드를 짜는 시간보다 기존 코드를 읽는 시간이 압도적으로 길다.
고로 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다.
보이스카우트 규칙
보이스카우트 규칙이란 캠프장에 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라는 것이다.
코드는 시간이 지나도 언제나 깨끗하게 유지해야 한다.
이 것은 어떻게 가능할까? - 항상 처음보다 더 깨끗한 코드를 푸시하면 된다.
개선이야말로 전문가 정신의 본질이다.
