# 1장 깨끗한 코드
Robert C. Martin 저 "Clean Code: A Handbook of Agile Software Craftsmanship"을 읽고 정리한 내용입니다. ( 박재호, 이해영 번역책도 참고하였습니다.)
Lean은 서양개발 문화가 내놓는 점차 주목받는 buzzword이다.
린원 = 낭비를 발견하고 제거함으로써 어떻게 고객에게 가치를 빠르게 제공할 수 있을 것인가에 대한 생각이자 사고방식 이다.
코드가 존재하리라
우리가 요구사항 명세분야에서 배운 교휸이라면, 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용해도 좋다는 사실이 있다. 궁긍적으로 코든느 요구사항을 표현하는 언어라는 사실을 명심해야 한다.
나쁜코드
어째서 나쁜코드를 짯는가? 급해서? 서두루느라 아마 그랬으리라. 제대로 짤시간이 없다고 해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕먹을까봐, 지겨워서 빨리 끝내고 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고... 모두가 겪어본 상황이다. 나중은 결코 오지 않는다. (르블랑의 법칙, leblanc's law)
나쁜코드로 치르는 대가
나쁜코드가 쌓일수록 팀생산성은 떨어진다. 그러다 생산성은 0에 근접한다. 희망을 품고 새인력을 추가한다. 하지만 새인력은 시스템설계에 대한 조예가 깊지 않다. 설계 의도에 맞는 변경과 설계의도에 반하는 변경을 구분하지 못한다. 결국 더 많은 나쁜코드를 만들어낸다. 마침내 팀이 반기를 든다. 재설계를 요구하고 새로운 타이거팀이 구성된다. 모두 타이거팀에 합류하고 싶어한다. 하지만 가장 유능하고 똑똑한 사람들만 차출된다. 나머 지는 현재 시스템을 유지보수한다. 이제 두팀의 경주가 시작된다. 타이거팀은 기존시스템이 제공하는 기능을 좋은코드로 모두 구현해야한다. 때로는 이경주가 10년동안 지속될 수도 있다.
태도
일정에 쫒기더라도 대다수의 관리자는 좋은 코드를 원한다. 비유를 하나 들어, 자신이 의사라고 가정하자. 환자가 수술전에 손을 씻지 말라고 요구한다. 환자는 상사다. 하지만 의사는 환자의 말을 그대로 따르는 행동은 전문가 답지 못하다. 프로그래머도 마찬가지다. 나쁜코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다.
전문가들에게 깨끗한 코드란?
Bjarne Stroustrup, C++ 창시자
C++ 창시자에 따르면은...
논리가 간단해야 버그가 숨어들지 못 한다.
의존성을 최대한 줄여야 유지보수가 쉽다.
오류는 전략에 의거해 처리한다.
성능을 최적화로 유지한다.
Grady Booch, Object Oriented Analysis and Design with Applications 저
잘쓴 문장처럼 읽힌다.
의도를 숨기지 않는다.
명쾌한 추상화와 단순한 제어문으로 가득하다.
Dave Thomas, OTI 설립자이자 이클립스 전략의 대부
읽기 쉽고 고치기 쉽다.
단위 테스트케이스와 인수 테스트 케이스가 존재한다.
목적을 달성한느 방법은 하나만 제공한다.
의존성은 최소이며 각 의존성을 명확히 정의한다.
API는 명확하며 최소로 줄인다.
Michael Feathers, Working Effectively with Legacy Code 저자
주의깊게 짰다는 인상을 준다. 손댈 곳이 없다.
작품에 감사를 느낀다.
Ron Jeffries, Extreme Programming Installed와 Extreme Programming Adventures in C# 저자
모든 테스트를 통과한다.
중복이 없다.
시스템 내 모든 설계 아이디어를 표현한다.
클래스, 메서드, 함수 등은 최대한 줄인다.
Ward Cunningham, 위키와 피트(fit) 창시자이자 익스트림 프로그래밍 공동창시자
짐작했던 기능을 각 루틴이 그대로 수행한다.
코드가 그 문제를 풀기 위한 언어처럼 보인다.
앞으로 오브젝트 멘토진영이 생각하는 깨끗한 코드를 설명한다.
Last updated