해당 포스트는 Clean Code의 내용을 참고하여 작성되었습니다.
르블랑의 법칙
우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다.
나중은 결코 오지 않는다.
나쁜코드로 치르는 대가
나쁜 코드는 개발 속도를 크게 떨어트린다. 프로젝트 초반에는 번개처럼 나가다가 1-2년만에 굼뱅이처럼 기어가는 팀도 많다. 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
그러다가 마침내 생산성은 0에 근접한다.
태도
관리자와 마케팅은 약속과 공약을 내걸며 우리에게 정보를 구한다. 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다. 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다. 우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다.
좋은 코드를 사수하는 일은 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
Clean Code
클린 코드는 다음과 같은 특징이 있다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스 메서드 함수 등을 최대한 줄인다.
- 추상화와 단순한 제어문으로 작성한다.
- 원칙없는 최적화를 수행하지 않는다.
- 의존성을 최소화 하며 각 의존성을 명확히 정의한다.
깨끗한 코드는 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.