클린코드 스터디 - 001
1장 깨끗한 코드
나쁜 코드
나중은 결코 오지 않는다. 르블랑의 법칙
나쁜 코드로 치르는 대가
코드가 하도 엉망이라 프로젝트 진도가 안 나가는 경험도 있으리라. 나쁜 코드는 개발속도를 크게 떨어뜨린다. 프로젝트 초반에는 번개처럼 나가다가 1~2년만에 굼뱅이처럼 기어가는 팀도 많다. 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다. 매번 얽히고 설킨 코드를 ‘해독’해서 얽히고 설킨 코드를 더한다. 시간이 지나면서 쓰레기 더미는 점점 높아지고 깊어지고 커진다. 청소할 방법이 없다. 불가항력이다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다. 생산성이 떨어지면 관리층은 나름대로 복구를 시도한다. 어떻게? 생산성을 증가시키려는 희망을 품고 프로젝트에 인력을 추가로 투입한다. 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않다. 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못한다. 게다가 새 인력과 팀은 생산성을 높여야 한다는 극심한 압력에 시달린다. 그래서 결국은 나쁜 코드를 더 많이 양산한다. 덕택에 생산성은 더더욱 떨어져 거의 0 이 된다. (그림 1-1 참조. )
원초적 난제
프로그래머는 근본적인 가치에서 난제에 봉착한다. 한두 해 이상 우리 분야에 몸 담은 프로그래머라면 누구나 나쁜 코드가 업무 속도를 늦춘다는 사실을 익히 안다. 그럼에도 모든 프로그래머가 기한 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낀다. 간단히 말해, 그들은 빨리 가려고 시간을 들이지 않는다. 진짜 전문가는 두 번째 부분이 틀렸다는 사실을 잘 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드
코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 주변코드를 읽지 않으면 새코드를 짜지 못한다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.
보이 스카우트 규칙
“캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.” 체크아웃 할 때보다 좀 더 깨끗한 코드를 체크인하다면 코드는 절대 나빠지지 않는다.