0. 장인 정신
이 책에서 얘기하는 장인 정신을 익히는 과정은 두 단계로 나뉜다.
첫째, 장인에게 필요한 원칙, 패턴, 경험이라는 지식을 습득해야 한다. (이론)
둘째, 열심히 일하고 연습해 지식을 몸과 마음으로 체득해야 한다. (실전)
1. 코드는 존재하리라
코드란, 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업의 결과물이다.
코드는 요구사항을 상세히 표현하는 수단으로, 일정 수준부터는 코드 없이는 요구사항을 상세하게 명세할 수 없다.
언젠가 코드가 사라지리라 생각하는 사람들은 언젠가 비정형적인 수학이 나오리라 기대하는 수학자와 비슷하다고 비유한다. 이는 요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 수행하는 그런 기계를 기대하는 것이다.
절대로 불가능하다.
창의력과 직관을 보유한 우리 인간도 고객의 막연한 감정만 가지고 성공적인 시스템을 구현하지 못한다.
2. 나쁜 코드
프로그래머라면 누구나 나쁜 코드로 고생한 경험이 있다. 어째서 나쁜 코드를 짰을까?
제대로 짤 시간이 없어서. 코드 다듬느라 시간 보냈다가 상사한테 욕 먹을까봐.
지겨워서 빨리 끝내려고. 다른 업무가 밀려있어 후딱 해치우려고...
모두가 나중에 다시 돌아와서 정리하겠다고 다짐했을 것이다.
하지만 우리는 르블랑의 법칙을 잘 알아야 한다.
나중은 결코 오지 않는다. (Later equals never)
나쁜 코드로 치르는 대가
나쁜 코드는 생산성을 떨어뜨린다.
원대한 재설계의 꿈
시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하고 전문가로서 살아남는 길이다.
태도
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따는 행동은 전문가답지 못하다.
당신이 의사고 환자가 상사라고 하자.
당신은 상사의 "수술 전에 손을 씻지 말라" 요구에 응할 것인가?
원초적 난제
모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느끼지만, 나쁜 코드를 양산하면 기한을 맞추지 못한다.
기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
꺠끗한 코드라는 예술?
깨끗한 코드를 구현하는 것은 그림을 그리는 것과 비슷하다.
잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아니다.
깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻이 아니다.
3. 깨끗한 코드란?
- 비야네 스트롭스트룹 (C++의 창시자, 'The C++ Programming Language'의 저자)
깨끗한 코드는 '보기에 즐거운' 코드다.
잘 만든 오르골이나 잘 디자인된 차를 접할 때처럼, 보는 사람에게 즐거움을 선사해야 한다는 뜻이다.
'효율' 또한 언급하였는데 이는 속도 뿐만이 아닌 사용 자원을 뜻한다.
그리고 '유혹'이란 단어로 그 결과를 표현하였다. 이는 나쁜 코드는 나쁜 코드를 '유혹'하며 흔히 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다는 뜻이다.
깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하고, 한 가지에 '집중'한 코드이다.
- 그래디 부치 ('Object Oriented Analysis and Design with Application'의 저자)
비야네와 흡사한 의견이지만 가독성을 강조한다.
또한, 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다.
- '큰' 데이브 토마스 (OTI 창립자이자 이클립스 전략의 대부)
'가독성'을 강조하지만 한 가지 더. 다른 사람이 고치기 쉬운 코드가 깨끗한 코드이다.
그리고 깨끗한 코드를 테스트 케이스와 연관짓는다. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.
- 마이클 페더스 ('Working Effectively with Legacy Code'의 저자)
깨끗한 코드는 주의 깊게 작성한 코드이다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다.
- 론 제프리스 ('Extreme Programming Installed'와 'Extreme Programming Adverture in C#'의 저자)
중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.
- 워드 커닝햄
깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다고 한다.
보이스카우트 규칙
잘 짠 코드가 전부는 아니다. 시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다. 적극적으로 코드의 퇴보를 막아야 한다.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
변수 이름 하나를 개선하고,
조금 긴 함수 하나를 분할하고,
약간의 중복을 제거하고,
복잡한 if문 하나를 정리하면 충분하다!
4. 결론
책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.
'코드 감각'을 확실히 얻는다는 보장도 없다.
뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술, 기교, 도구를 소개할 뿐이다.
그러니 연습해라.
이 책의 Tip) 객체 지향 설계의 5가지 원칙
- SRP(Single Responsibility Principle)
클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다. - OCP(Open Closed Principle)
클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다. - LSP(Liskov Substitution Principle)
상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다. - DIP(Dependency Inversion Principle)
추상화에 의존해야 하며, 구체화에 의존하면 안 된다. - ISP(Interface Segregation Principle)
클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.
이렇게만 보면 아직 이해가 되지 않는 부분이 있다. 이는 공부할 목록에 기록하고 다음에 공부해보고자 한다.
