다시 핵심만 간결하게 복기하기 위한 목적으로 정리하기 때문에, 요약하는 방식으로 글을 작성한다.
역/식자의 말
- 절대적이라 믿으면 안된다 개선의 여지가 있을 것이라 생각해야 한다.
- 이 요소들을 소개하는 이유는 팀/공동체에서 서로 동의하는 합리적인 원칙을 세우기 위함이다. 즉, 교양 서적이라 보는 것이 보다 합당하다.
- 유지보수 작업으로 신경 쇠약에 걸리고 있다면, 책에서 소개하는 내용이 마음에 와닿을 것이다.
- 앞부분에서는 패턴과 규칙을 익히고, 실제 코드를 정리하는 부분은 후반부이다. 후반부에 집중하자.
- 개발자에게 "수학의 정석"과 같은 책이다. 방식을 이해해야 소화할 수 있는 책이다.
- 항상 나라면 어떻게 했을까를 기억하자.
- 세세함에 주의를 기울이는 태도는 현재 전문가에게 필수적인 자질이다. Clean code가 중요한 이유는 여기에 있다.
- 소프트웨어은 제조업에서 영향을 받았다. 다만 유지보수의 비율이 극단적으로 높은 업계이다.
- Scrum: 일본 자동차 제조업 영향
- Agile: 빠른 Delivery를 위한 방법론
- Lean: TPM(Total Productive Management: 유지보수에 초점을 맞춘 품질 관리론)에 영향을 받은 원칙
- 책임있는 개발자라면 제품 생명 주기까지 고려해야 한다.
- 제조업에서 재작업은 비용이나, 소프트웨어에서 재작업은 가치를 가져온다.
- 어떻게 보면 이 책은 방법에 대한 이야기가 아니라, 삶의 태도에 대해 직간접적으로 전하기 위해 만들어졌는지도 모르겠다.
Introduction
코드 품질을 측정하는 유일한 척도는 WTF 횟수/minute 이다.
나는 어떻게 코드를 작성하고 있는가? 낮은 척도를 가지는가, 높은 척도를 가지는가? 팀이나 회사는 어떤가. 어떻게 높은 수치를 가지는 마음을 가질 수 있는가? 답은 장인 정신이다. 장인 정신을 익히기 위한 과정은 두 단계로 나뉜다.
- 이론: 원칙, 패턴, 기법, 경험이라는 지식을 습득한다.
- 실전: 지식을 실천하여 체득한다.
아는 것과 하는 것은 차원이 다르다. 이 책은 고생하면서 읽는 책임을 명심해야 한다. 책의 구성은 다음과 같다.
- 깨끗한 코드를 작성하는 원칙, 패턴, 실기를 설명한다. 여기서 그만두면 good luck이다.
- 여러 사례 연구를 소개한다. 집중력을 요구하는 장이다. 코드와 설명을 번갈아가며 보면서 그 판단의 이유를 추적해야 한다.
- 결말이다. 귀납적으로 도출된 결론을 정리한다. 휴리스틱적으로 느끼는 것들을 명료하게 정리하려 애썼다.
각각의 챕터는 종속되어 있기 때문에, 앞 부분부터 제대로 읽는 것이 중요해 보인다. 결국은 머리에 법률 사례집처럼 기억하고 있는 것이 좋아보인다.
Clean Code
이 책을 왜 읽는가? 프로그래머라서? 더 나은 프로그래머가 되려고? 그렇다면 잘 찾아왔다.
하나의 코드를 두고 다각도로 검증하면서 꺠달음을 갈구하는 책이다. 또한 그 과정에서 좋은 코드, 나쁜 코드를 구분할 수 있을 것이다. 마지막으로 나쁜 코드를 좋은 코드로 바꾸는 실력도 챙길 수 있다.
코드가 존재하리라
미래에는 코드를 자동으로 생성해주지 않을까? 이 책을 읽는 시기 상조가 아닙니까?
그럴리가 없다. 코드는 요구 사항을 상세히 표현하는 수단이기 때문이다. 어느 수준에 이르면, 코드의 도움 없이 요구사항을 표현하는 것은 불가능하다. 프로그래밍 언어의 추상화 수준이 늘어나고, DSL(Domain-specific language)가 많아짐에도 불구하고 결국은 기계가 이해하고 실행할 정도로 엄밀하고 정확하며 상세한 코드가 등장해야 한다.
위의 발언을 한 사람은, 코드가 마법이라 생각하는 착각 때문에 발생한 오류로 보인다. 코드는 요구사항을 표현하는 언어이다. 그 과정에서 요구사항에 가까운 언어를 만들 수 있으나 결국은 정밀한 표현이 필요하다. 코드는 항상 존재한다.
나쁜 코드
출시에 바빠 마구 짠 코드 -> 출시일 지연 -> 회사 파산
본질적인 원인은 나쁜 코드 탓이었다. 왜 나쁜 코드를 짜는가? 바빠서? 급해서? 지겨워서? 상사에게 욕먹을까봐? 이렇게 넘어가고 나중에 손보겠다고 생각하면 경험이 있을 것이다. 안돌아가는 쓰레기보다 돌아가는 쓰레기가 좋다고 자위한 경우가 있을 것이다. 꼭 고치겠다고 다짐했었다. 하지만 그 때는 오지 않는다.
르블랑의 법칙(Leblanc's Law) = 나중은 결코 오지 않는다. 나중에 손보겠다고 한 코드 + 돌아간다는 사실에 안도감을 느끼며 위로함 -> 고치지 않는다.
나쁜 코드로 치르는 대가
이 그림이 정답이다. 초기에는 개발 속도가 빠를지 모른다. 하지만 시간이 지남에 따라 나쁜 코드는 발목을 잡는다. side effect가 계속 발생한다. 이러한 상황에 해결책으로 제시하는 것은 결국 man power를 늘리는 것이다. 하지만 새 인력은 시스템 설계에 대해 모르기 때문에 의도에 맞는 변경과 그에 반하는 변경을 알지 못한다. 그 뿐이 아니다. 생산성의 압박을 받고 있는 시점에 투입된 인력은 더 큰 압박을 받는다. 결과는 더 많은 나쁜 코드의 발생으로 이어진다.
원대한 재설계의 꿈
더 이상 못하겠어요.
팀은 이 코드로는 일을 못하겠다는 반기를 든다. 관리층은 어쩔 수 없이 이 제안을 받아들인다. TF팀이 구성되고, 새로운 product를 만든다. 나머지는 유지 보수를 계속한다. TF팀은 기존 기능을 모두 상회하는 시스템을 내놓아야 한다. 얼마가 걸릴까? 때떄로 10년의 시간이 걸릴 수도 있다. 무엇을 선택하겠는가? 시간을 들여 Clean Code를 작성하는 것은 궁극적으로 비용 절감, 전문가로서 살아남는 길이라는 것을 명심해야 한다.
태도
분명 3시간 작업이라 생각했는데 건드는 소스파일이 30개네? ㅎ..
이 친구는 왜 한순간에 나쁜 코드로 전락했을까?
- 원래 설계를 뒤집는 방향으로 요구사항이 변경되어서
- 일정이 촉박해서
- 관리자의 탓
하지만 이 것은 전적으로 프로그래머의 잘못이다. 우리가 전문가답지 못했기 때문이다. 잘못이 코드에 있다면, 이는 프로그래머의 책임이다. 오히려 이 좋은 코드를 사수하지 못하여 발생하는 일정 지연을 관리자에게 솔직하게 말하는 것이 보다 중요하다. 환자가 수술전에 의사보고 손씻지 말라고 하면 손 안씻을 건가? 갑의 위치에 있다하더라도, 사수해야 하는 영역은 명확히 말해야 한다. 그것이 전문가다.
원초적 난제
아 여기서 그냥 이렇게 하면 기한은 맞추는데 어떡하지..
하지만 진짜 전문가는 이게 오히려 느린 방식이라는 것을 안다. 기한을 맞추는 유일한 방법은, 즉 빨리가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관을 가지는 것이다.
깨끗한 코드라는 예술?
그래서 어떻게 짜는건데?
이 모든 사실을 납득했다고 해보자. 이제 어떻게 작성하는지에 대해 고민할 차례다. 그런데 안타깝게도 깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다. 그림의 미적인 판단을 하는 것은 대부분의 사람이 가능하지만, 그렇다고 해서 모두가 잘 그리는 것은 아니다. 즉, 코드의 품질 판단 가능 여부와 품질이 좋은 코드를 작성하는 능력은 별개이다.
이를 위해서는 "코드 감각"을 일단 얻고, 최고 방식으로 이를 적용해야 한다. 정말 추상적이고 어렵다 ㅠ
깨끗한 코드란?
각 프로그래머다 생각이 다르기 때문에, 다양한 대가들로부터 의견을 구했다.
비야네 스트롭스트룹
C++ 창시자, The C++ Programming Laungague 저자
- 우아한 코드가 좋다. (보기에 즐거운 코드가 좋다.)
- 간단한 논리, 의존성을 줄인다. 그것이 유지보수를 쉽게 만든다.
- 오류는 명백한 전략에 의거해 철저히 처리한다. (세세한 사항까지 꼼꼼하게 신경써라)
- 성능을 최적으로 유지한다. 그래야 사람들이 헛짓거리 안한다. (역시 C++ 창시자)
- 깨끗한 코드를 하나를 제대로 한다.
그래디 부치
Object Oriented Analysis, Design with Application 저자
- 단순하고 직접적인 코드가 깨끗한 코드이다.
- 잘 쓴 문장처럼 읽힌다. (가독성을 강조)
- 설계자의 의도를 숨기지 않는다.
- 명쾌한 추상화와 단순한 제어문으로 가득하다. (불필요한 사실에 얽매이지 않는, 단호하다는 인상을 줘야 한다.)
큰 데이브 토마스
OTI 창립자, 이클립스 전략의 대부
- 작성자가 아닌 사람도 읽기 쉽고 고치기 쉬워야 한다. (가독성 강조, 고치기 쉬운 코드)
- Unit Test, Acceptance Test가 존재한다. (테스트 코드)
- 의미 있는 이름이 붙는다.
- 목적 달성 방법을 하나만 제공한다.
- 의존성은 최소이며 명확하게 정의한다.
- API는 명확하며 최소로 줄인다.
- 코드는 문학적이어야 한다. (인간이 읽기 쉬워야 한다.)
마이클 페더스
Working Effectively with Legacy Code 저자
- 주의깊게 짰다는 느낌이 있다.
- 고치려고 봐도 딱히 손 댈 곳이 없다.
- 모든 사항을 고려했기 때문에, 결국 제자리로 돌아온다.
론 제프리스
Extreme Programming Installed, Exterme Programming Adventure in C# 저자
이 분은 fortran으로 시작하여 거의 모든 언어로 코드를 구현해왔다. 주의 깊게 읽어보자.
- 모든 테스트를 통과한다.
- 중복이 없다. (같은 작업이 반복된다면 아이디어를 제대로 표현하지 못한다는 사실의 반증이다)
- 시스템 내 모든 설계 아이디어를 표현한다.
- class, method, function을 최대한 줄인다.
- 의미 있는 이름을 적는다.
- 여러 기능을 수행하는 객체라면 나눈다.
- 추상 클래스를 만들어 구현을 감싼다. (간단한 추상화를 고려하여 잠시 문제를 미뤄둘 수 있다. 즉 크게 설계하고 세부 사항을 나중에 넣는다.)
중복 피하기, 한기능만 수행하기, 제대로 표현하기, 작게 추상화하기.
워드 커닝햄
Extreme Programming 공동 창시자, 대부
- 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다.
- 짐작대로 돌아가는 코드가 깨끗한 코드다. (단순하는 말)
우리들 생각
Object 문파의 교훈을 따른다면 만끽한 이익을 너도 가질수 있어!
무술의 교파처럼 코드 진영도 마찬가지다. 어느정도의 성향이 있다. 이 책에서 설명하는 것들이 결국 저자도 지지하는 생각이다. 이 기법을 익히면 수준 높은 코드를 작성할 수 있다고 장담한다. 믿고 가자. 하지만 절대적으로 옳지는 않으니, 여러 경험을 토대로 배우는 것을 추천한다.
우리는 저자다
코드는 짜는 시간보다 읽는 시간이 배로 많이 든다.
그렇기 때문에 우리는 잘 읽히는 코드를 짜는 것에 집중해야 한다. 작업하는 것을 영상으로 찍고 빠른 배속으로 돌려보면, 실질적으로 코드를 치는 시간은 많지 않다.
보이스카우트 규칙
캠프장은 처음 왔을 때 보다 더 깨끗하게 하고 떠나라
남자는 지나간 자리가 더 아름답습니다
지속한 개선이야말로 전문가 정신의 본질이다. 한번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름의 개선, if문 정리, 긴 함수 분할이면 충분하다.
결론
방법을 안다고 도사가 되는 건 아니다.
앞으로 경험적 교훈과 체계, 절차, 기법들이 난무할 것이다. 이걸 어떻게 체화하냐는 걸국 독자의 몫이다. "연습해, 연습!!"
Summary
- 나쁜 코드를 가만두지 말아라.
- 중복은 제거하라.
- 메소드의 기능은 잘개 쪼개라.
- 네이밍은 명확하게 지어라.
- 테스트케이스를 작성하라.
- 오류 처리를 철저하게 하라.
- 장인 정신을 가지고 습관으로 만들어라
Reference
