Clean Code, Chapter 1: Clean Code

1. 깨끗한 코드

이 책은 좋은 프로그램 작성 요령을 설명하는 책이고 온통 코드들이다. 코드를 최대한 다양한 각도에서 살펴본다. 책을 읽은 후에는 코드에 대해 많은 사실을 배우게 되고 좋은 코드와 나쁜 코드를 구분하는 능력도 생긴다. 좋은 코드를 작성하는 방법도 익히고, 나쁜 코드를 좋은 코드로 바꾸는 실력도 쌓인다.

코드가 존재하리라

시대에 뒤떨어지는 주제라 생각할 수 있다. 코드가 문제가 아니라 모델이나 요구사항에 집중해야 한다고 생각할 수도 있다.

코드는 사라질 일이 없다. 코드는 요구사항을 상세히 표현하는 수단이기 때문이다. 코드의 도움 없이 요구사항을 상세하게 표현하는 건 불가능하다. 기계가 실행할 수 있게 상세하게 요구사항을 명시하는 작업, 이것이 프로그래밍이다. 이렇게 명시한 결과가 코드다.

창의력과 직관을 가지고 있어도 고객의 막연한 감정만 갖고 성공적인 시스템을 구현하지 못한다. 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용해도 좋다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 어느 순간 정밀한 표현이 필요한데 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재한다.

나쁜 코드

우리는 좋은 코드가 중요하다는 사실을 알고 있는데 오랫동안 나쁜 코드에 시달려왔기 때문이다.

출시에 바빠 코드를 마구 짜게 될 때 기능을 추가할 수록 코드는 엉망이 되고 결국은 감당이 불가능한 수준에 이른다. 회사가 망하는 원인 중 하나가 될 수도 있는데 나쁜 코드 탓이다.

나쁜 코드에 발목이 잡혀 고생한 경험이 있다면 '고행wading'이라 부르기도 한다. 그러면 왜 나쁜 코드를 짜는가?

급해서
서두르느라
제대로 짤 시간이 없다고 생각해서
코드를 다듬느라 시간을 보냈다가 상사한테 욕 먹을까봐
지겨워서 빨리 끝내려고
다른 업무가 너무 밀려 빨리 해치우고 밀린 업무로 넘어가려고

모두 겪어본 상황일 것이다.

자신이 짠 쓰레기 코드를 보며 나중에 손보겠다고 생각한 경험이 있다. 대충 짠 프로그램이 돌면 안도감을 느끼고 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 생각한 적도 있을 것이다. 나중에 돌아와 정리하겠다고 다짐도 한다.

르블랑의 법칙leblanc's Law을 알고 있다면 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도를 크게 떨어뜨린다. 프로젝트 초반에는 생산성이 좋지만 시간이 지나면 떨어진다. 코드를 고칠 때 마다 엉뚱한 곳에서 문제가 생기고 시간이 지나면서 쓰레기 더미는 높아지고 깊어지고 커진다.

나쁜 코드가 쌓이면 팀 생산성은 떨어진다. 생산성 증가를 목적으로 새로운 인력을 투입하지만 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못한다. 새 인력과 팀은 생산성을 높여야 한다는 압박에 시달리고 결국 나쁜 코드를 더 많이 양산한다.

원대한 재설계의 꿈

재설계를 위해 타이거팀을 구성한다. 처음부터 아름다운 작품을 창조할 기회이므로 가장 유능하고 똑똑한 사람들만 타이거팀으로 차출된다.

타이거팀은 기존 시스템의 기능을 모두 제공하는 새 시스템을 만들어야 한다. 그 동안 기존 시스템을 유지보수하면서 생긴 변경도 적용해야 한다.

이 경주는 아주 오랫동안 이어진다. 새 시스템이 기존 시스템을 따라잡을 쯤에는 초창기 타이거 팀원들은 다 떠나고 없고 새로운 팀원들이 같은 방식으로 새 시스템을 설계하자고 한다.

이 이야기는 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법이고 전문가로 살아남는 길이라는 사실을 보여준다.

태도

코드가 왜 나쁜 코드가 되었을까 온갖 이유가 있다. 요구사항 변경, 촉박한 일정, 멍청한 관리자, 조급한 고객, 쓸모없는 마케팅 부서 등등. 하지만 프로그래머가 전문가답지 못했기 때문이라는 사실을 인정해야 한다.

관리자가 지시한대로 해야 한다고 하지만 대다수 관리자는 진실을 원한다. 일정에 쫓겨도 좋은 코드를 원한다. 일정과 요구사항을 밀어 붙이는 이유는 그게 그들의 책임이기 때문이다. 반면 좋은 코드를 사수하는 일은 프로그래머의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다.

원초적 난제

나쁜 코드가 업무 속도를 늦춘다는 사실을 알고 있다. 그런데도 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낀다. 빨기 가려고 시간을 들이지 않는다.

전문가라면 반대로 나쁜 코드를 양산하면 기한을 맞추지 못한다는 사실을 안다. 기한을 맞추고 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술?

"깨끗한 코드를 어떻게 작성할까?" 깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용없다.

잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력이 아니다. 마찬가지로 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 개끗한 코드를 작성할 줄 안다는 뜻은 아니다.

깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. '코드 감각'이 필요한데 타고날 수도 있고 투쟁해서 얻어야 할 수도 있다. '코드 감각'이 있으면 좋은 코드와 나쁜 코드를 구분한다. 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.

깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.

깨끗한 코드란?

유명하고 노련한 프로그래머들에게 의견을 물었다.

비야네 스트롭스트룹Bjarne Stroustrup, C++ 창시자이자 The C++ Programming Language 저자

우아한 단어를 사용해 깨끗한 코드는 '보기에 즐거운' 코드라고 해석한다. CPU 자원을 낭비하는 비효율적인 코드다 우아하지 못하다. 나쁜 코드는 나쁜 코드를 '유혹'한다. 나쁜 코드를 고치면서 더 나쁜 코드를 만든다. 실용주의 프로그래머 데이브 토마스David Thomas와 앤디 헌트Andrew Hunt는 같은 이야기를 다르게 표현했는데, 그들은 깨진 창문이라는 비유를 사용했다. 창문이 깨진 건물은 누구도 상관하지 않는다. 창문이 깨지고 나면 쇠퇴하는 과정이 시작된다. 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드로 대충 넘어가지 않는 오류 처리다. 깨끗한 코드는 한 가지를 잘 한다고 단언한다.

그래디 부치Grady Booch, Object Oriented analysis and Design with Application 저자

가독성을 강조한다. 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다. 명쾌한 추상화는 재밌는 모순어법이다. 명쾌한crisp 이라는 단어는 구체적인concrete라는 단어와 유사할 수 있다. 의미는 강력하고 분명한데 코드는 추측이 아닌 사실에 기반해야 하고 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.

'큰big' 데이브 토마스Dave Thomas, OTI 창립자이자 이클립스 전략의 대부

깨끗한 코드는 다른 사람이 고치기 쉽다고 단언한다. 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.

깨끗한 코드는 테스트 케이스와 연관 지을 수 있다. 테스트 주도 개발이라는 분야는 업계에 영향을 미치면서 원칙 중 하나가 되었다. 코드가 우아하고 가독성이 높아도 테스트 케이스가 없으면 깨끗하지 않다.

크기가 작은 코드에 가치를 둔다. 소프트웨어에서 반복하는 중요한 교훈이기도 하다.

코드가 문학적이어야 한다고 말한다. 읽기 좋은 코드를 작성해야 한다는 뜻이다.

마이클 패더스Michael Feathers, Working Effectively with Legacy Code 저자

코드를 주의 깊게 짜는 방법을 언급한다. 깨끗한 코드는 주의 깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다. 세세한 사항까지 꼼꼼하게 신경 쓴 코드다.

론 제프리스Ron Jeffries, Extreme Programming Installed와 Extreme Programming Adventure in C# 저자

중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.

워드 커닝햄Ward Cunningham

위키Wiki 창시자, 피트Fit 창시자, 익스트림 프로그래밍 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 스몰토크와 객체 지향의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부

깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다고 얘기한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다. 명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드다. 각 모듈은 다음 무대를 준비한다. 모듈을 읽으면 다음에 벌어질 상황이 보인다. 깨끗한 코든느 너무 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다.

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 언어라 불러도 된다. 언어를 단순하게 보이도록 만드는 책임은 프로그래머에게 있다.

우리들 생각

이 책은 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다. 여기서 가르치는 교훈과 기법은 우리 진영이 믿고 실천하는 교리다. 여기서 가르치는 기법을 따른다면 깨끗하고 수준 높은 코드를 작성하리라 장담한다. 하지만 절대적으로 '옳다'라는 단정은 금물이다. 다른 경험이 많은 집단과 전문가가 존재하므로 마땅히 그들에게서도 배워야 한다.

오랫동안 고민하고 숙고한 교훈과 기법을 권고하고 있고 수십 년에 걸친 경험과 반복적인 시행착오로 습득한 교훈과 기법이다. 그래서 동의하든 동의하지 않든 이런 시각을 이해하고 존중해야 한다.

우리는 저자다

코드를 짜는 프로그래머는 저자다. 저자에게는 독자가 있다. 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실과 이 코드를 보고 판단을 내릴 독자가 있다는 사실을 기억해야 한다.

코드를 읽는 시간 대 코드를 짜는 시간 비율은 10:1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 그러므로 읽기 쉬운 코드가 매우 중요하다. 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기 쉬워진다.

이 논리에서 빠져나갈 방법은 없다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기 어려우면 새 코드를 짜기도 어렵다. 그러므로 서둘러 끝내고 쉽게 짜려면, 읽기 쉽게 만들면 된다.

보이스카우트 규칙

잘 짠 코드라도 시간이 지나면서 엉망으로 전락할 수 있다. 적극적으로 코드의 퇴보를 막고 언제나 깨끗하게 유지해야 한다.

보이스카우트의 규칙은 소프트웨어 전문가에게도 유용하다.

캠프장은 처음 왔을 대보다 더 깨끗하게 해놓고 떠나라

체크아웃할 때 보다 더 깨긋한 코드를 체킌한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리하지 말고 조금씩 정리한다.

지속적인 개선이야말로 전문가 정신의 본질이다.

프리퀄과 원칙

2002년에 출판한 Agile Software Development: Principles, Patterns, and Pratices(PPP)의 프리퀄이다. (번역서 정보: 클린 소프트웨어 - 애자일 원칙과 패턴, 그리고 실천 방법)

PPP는 객체 지향 설계 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개한 책이다. 이 책을 먼저 읽은 후에 나중에 읽으면 좋다. 왜냐하면 이 책에서 하는 이야기를 이어가기 때문이다. PPP에서 나온 이야기는 여기서 코드로 재발견할 수 있다.

결론

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다. 책은 예술가가 사용하는 도구와 기법, 생각하는 방식을 소개할 뿐이다. 이 책 역시 마찬가지다. 여러가지 많은 세세한 정보로 가득하지만 나머지는 연습하기에 달렸다. (After that, it’s up to you)

참고 문헌

[Beck07]: Implementation Patterns, Kent Beck, Addison-Wesley, 2007.
- 켄트 벡의 구현 패턴 - 읽기 쉬운 코드를 작성하는 77가지 자바 코딩 비법
[Knuth92]: Literate Programming, Donald E. Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992.

jongfeel / BookReview