동구의 블로그

Chapter 1. 클린코드 (35p)

1       코드가 존재하리라 (36p)

l  앞으로 코드가 사라질 가망은 전혀 없다.

n  코드는 요구사항을 상세히 표현하는 수단이다.

n  요구사항에 더욱 가까운 언어, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있지만, 어느 순간에는 정밀한 표현이 필요하다.

2       나쁜 코드 (37p)

l  80년대 후반 킬러 앱 Killer App 하나를 구현한 회사가 시간이 지나 망했다.

n  출시에 바빠서 코드를 마구 짬->기능을 추가할수록 코드 엉망->회사 망함

l  나중은 결코 오지 않는다. (로블랑의 법칙)

n  자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각함

3       나쁜 코드로 치르는 대가 (38p)

l  남들이 저질러놓은 쓰레기 코드로 고생한다.

n  나쁜 코드는 개발 속력을 크게 떨어뜨린다.

n  코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다.

n  간단한 변경은 없다. 매번 얽히고설킨 코드를 ‘해독’해 얽히고설킨 코드를 더한다.

l  생산성이 떨어지면 관리층은 나름대로 복구를 시도한다.

n  생산성이 높아지리라는 희망을 품고 프로젝트에 인력을 추가로 투입한다.

n  새 인력은 시스템 설계를 충분히 이해하지 못함->설계 의도에 맞는 변경과 설계의도에 반하는 변경을 구분하지 못함->팀은 생산성을 높여야 한다는 압력을 받음->결국 나쁜 코드를 더 많이 생산-> 생산력은 0이 됨

3.1       원대한 재설계의 꿈 (39p)

l  마침내 팀이 반기를 듬-> 관리층에 재설계 요구-> 관리층 재설계 허락->새로운 타이거 팀2 구성->기존 유지 보수 팀과 타이거 팀의 경주 시작-> 새 시스템이 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀원들은 모두 팀을 떠나고 새로운 팀원들이 새 시스템을 설계하자고 나섬. 왜? 현재 시스템이 너무 엉망이라서

2 소프트웨어 업계에서 새로 출시할 소프트웨어 오류나 보안 허점 등을 찾아내 해결할 목적으로 구성하는 전문 개발 그룹을 가리킨다.

3.2       태도 (39p)

l  우리는 좋은 코드가 순식간에 나쁜 코드로 전락하는 것은 우리의 책임도 크다.

n  관리자와 마케팅은 약속과 공약을 내걸면서 우리에게 정보를 구한다. 우리에게 정보를 구하지 않더라도 우리가 적극적으로 정보를 제공해야 마땅하다.

n  사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다.

n  프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다.

l  “아니, 잠깐만요! 상사가 시키는 대로 안 하면 짤린다구요!”

n  자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 질병과 감염의 위험은 의사가 환자보다 더 잘 아니까. 환자 말을 그대로 따르는 행동은 전문가 답지 못하니까. 프로그래머도 마찬가지. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

3.3       원초적 난제 (40p)

l  기한을 맞추려고 나쁜 코드를 양산하는 프로그래머는 진짜 전문가가 아니다.

n  진짜 전문가는 나쁜 코드를 양산하면 오히려 기한을 못 맞춘다고 생각한다. 나쁜 코드로 속력이 즉각 늦어져서 결국은 기한을 놓친다. 언제나 코드를 최대한 깨끗하게 유지하는 습관을 길들여야한다.

3.4       클린 코드라는 예술 (41p)

l  “클릭 코드를 어떻게 작성할까?”

n  ‘청결’이라는 힘겹게 습득한 감각으로 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 열쇠는 ‘코드 감각’이다. ‘코드 감각’이 있으면 좋은 코드와 나쁜 코드를 구분한다. 코드 감각은 타고나거나 투쟁해서 얻는다.

n  절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략을 파악한다.

n  ‘코드 감각’이 없는 프로그래머는 나쁜 모듈을 알아보는 것만으로 끝나지만 ‘코드 감각’이 있는 프로그래머는 나쁜 모듈을 보고서 좋은 모듈로 개선할 방안을 떠올린다.

n  결론은 클린 코드를 작성하는 프로그래머는 빈 캔버스를 우아한 작품으로 바꿔가는 화가와 같다.

3.5       클린 코드란? (41p)

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

n  “나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 클린 코드는 한 가지를 제대로 한다”

n  바야네는 ‘우아한’이라는 단어를 사용한다. 잘 만든 오르골이나 잘 설계한 차를 접할 때처럼 클린 코드는 보는 사람에게 즐거움을 선사해야 한다.

n  바야네는 효율도 언급한다. 속력, CPU 자원 낭비 등은 우아하지 못하고 보기에 즐겁지도 못한다. 나쁜 코드는 나쁜 코드를 ‘유혹’한다! 흔히 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다는 뜻이다.

n  실용주의 프로그래머에서 데이브 토마스와 앤드헌터는 깨진 창문이라는 비유를 사용했다. 창문이 깨진 건물은 누구도 상관하지 않는다는 인상을 풍김->사람들도 관심을 끊음->창문이 더 깨져도 상관하지 않음->자발적으로 창문을 깸, 외벽에 그려진 낙서를 방치하고 차고에 쓰레기가 쌓여도 치우지 않게됨. 일단 창문이 깨지고 나면 쇠퇴하는 과정이 시작된다.

n  바야네는 철저한 오류 처리도 언급한다. 클린 코드는 세세한 사항(메모리 누수, 경쟁 상태, 일관성 없는 명명법 등등)까지 꼼꼼하게 처리하는 코드다.

n  바야네는 한 가지를 잘한다고 단언한다. 수많은 소프트웨어 설계 원칙이 이 간단한 교훈 하나로 귀결된다는 사실은 우연이 아니다. 클린 코드는 한 가지에 ‘집중’한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한 길만 걷는다.

l  그래디 부치(Grady Booch), [Object Oriented Analysis and Design with Application] 저자

n  “클린 코드는 단순하고 직접적이다. 클린 코드는 잘 쓴 문장처럼 읽힌다. 클린 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.”

n  그래디는 비야네와 흡사한 의견을 표명하지만 가독성을 강조한다. 지금까지 자신이 읽은 책 중 진짜로 좋았던 책을 떠올려보라. 책을 읽는 동안 단어가 사라지고 이미지가 떠오르지 않았는가? 마치 한 편의 영화를 보듯이 말이다. 물론 클린 코드를 읽는 느낌이 반지의 제왕을 읽는 느낌과 같을 리는 없다. 좋은 소설과 마찬가지로 클린 코드는 해결할 문제의 긴장을 명확히 드러내야한다. 긴장을 쌓으며 클라이맥스에 이르렀다가 명백한 해법을 제시하며 긴장과 문제를 풀어야한다. 독자가 “아! 당연하지!”라며 무릎을 탁 치도록!

n  그래디가 언급한 ‘명쾌한 추상화’는 참으로 재미넌 모순 어법이다. ‘명쾌한’이라는 단어는 ‘구체적인’이라는 단어와 유사하지 않던가? 코드는 추측이 아니라 사실에 기반을 두어야 한다. 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 주어야 한다.

l  “큰 형님”데이브 토마스(Dave Thomas), OTI 창립자이자 이클립스 전략의 대부

n  “클린 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 수용 테스트 케이스가 존재한다. 의미 있는 이름이다. 특정한 목적을 달성하는 방법은 (여러 가지가 아니라) 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 때로는 필요한 정보 전부를 코드만으로 명확하게 드러내기 어려우므로 언어에 따라 문학적 표현이 필요하다.”

n  데이브도 그래디와 마찬가지로 ‘가독성’을 강조하지만, 한 가지 중요한 반전을 더한다. 데이브는 클린 코드란 다른 사람이 고치기 쉽다고 단언한다. 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.

n  데이브는 클린 코드를 테스트 케이스와 연관 짓는다. 테스트 주도 개발Test Driven Development이라는 분야는 우리 업계에 심오한 영향을 미치며 오늘날 가장 근본적인 원칙 중 하나가 되었다. 아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 못하다.

n  데이브는 큰 코드보다 작은 코드에 가치를 둔다. 작을수록 좋다.

n  데이브는 코드가 ‘문학적’이어야 한다고 말한다. 요점은 인간이 읽기 좋은 코드를 작성하라는 말이다.’

l  마이클 페더(Michael Feather), [Working Effectively with Legacy Code] 저자

n  “클린 코드가 보이는 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 클린 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로. 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.”

n  한 마디로 요약하면 ‘주의’다. 이것이 이 책의 주제다. 부제를 붙이라면 ‘코드를 주의 깊게 짜는 방법’이 적당하겠다.

n  마이클은 정곡을 찌른다. 클린 코드는 주의 깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다. 세세한 사항까지 꼼꼼하게 신경 쓴 코드다. 주의를 기울인 코드다.

l  론 제프리(Run Jeffries), [Extreme Programming Installed]와 [Extreme Programming Adventure in C#] 저자

n  론은 스트레티직 에어 커맨드 사에서 포트란으로 프로그래밍을 시작한 이래로 거의 모든 플랫폼에서 거의 모든 언어로 코드를 구현해왔다. 그러므로 그의 의견은 신중하게 고려할 가치가 있다.

n  “최근 들어 나는 켄트 벡이 제안한 간단한 코드 규칙으로 구현을 시작한다.(그리고 같은 규칙으로 구현을 거의 끝낸다). 중요한 순으로 나열하자면 간단한 코드는

Ø  모든 테스트를 통과한다.

Ø  중복이 없다.

Ø  시스템 내 모든 설계 아이디어를 표현한다.

Ø  클래스, 메소드, 함수 등을 최대한 줄인다.

 물론 나는 주로 중복에 집중한다. 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다. 나는 문제의 아이디어를 찾아내 좀더 명확하게 표현하려 애쓴다.

 내게 있어 표현성은 의미 있는 이름을 포함한다. 보통 나는 확정하기 전에 이름을 여러 차례 바꾼다. 이클립스와 같은 현대적인 개발 도구는 이름을 바꾸기가 상당히 쉽다.그래서 별다른 고충 없이 이름을 바꾼다. 하지만 표현성은 이름에만 국한되지 않는다. 나는 여러 기능을 수행하는 개체나 메소드도 찾는다. 개체가 여러 기능을 수행한다면 여러 개체로 나눈다. 메소드가 여러 기능을 수행한다면 메소드 추출Extract Method 리팩토링 기법을 적용해 기능을 명확히 기술하는 메소드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.

 중복과 표현성만 신경을 써도(내가 생각하는) 클린 코드라는 목표에 성큼 다가선다. 지저분한 코드를 손볼 때 이 두 가지만 고려해도 코드가 크게 나아진다. 하지만 나는 한 가지를 더 고려한다. 조금 설명하기 까다롭다.

 오랜 경험 끝에 나는 모든 프로그램이 아주 유사한 요소로 이루어진다는 사실을 깨달았다. 한 가지 예가 ‘집합에서 항목 찾기’다. 직원 정보가 저장된 데이터베이스든, 키/값 쌍이 저장된 해시 맵이든, 여러 값을 모아놓은 배열이든, 프로그램을 짜다 보면 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이런 상황이 발생하면 나는 추상 메소드나 추상 클래스를 만들어서 실제 구현을 감산다. 그러면 여러 가지 장점이 생긴다.

 이제 실제 기능은 아주 간단한 방식으로, 예를 들어 해시 맵으로, 구현해도 괜찮다. 다른 코드는 추상 클래스나 추상 메소드가 제공하는 기능을 사용하므로 실제 구현은 언제든지 바꿔도 괜찮다. 지금은 간단하게 재빨리 구현했다가 나중에 필요할 때 바꾸면 된다.

 게다가 집합을 추상화하면 ‘진짜’ 문제에 신경을 쓸 여유가 생긴다. 간단한 찾기 기능이 필요한데 온갖 집합 기능을 구현하느라 시간과 노력을 낭비할 필요가 없어진다.

 중복 줄이기, 표현성 높이기, 초반부터 간단한 추상화 고려하기. 내게는 이 세 가지가 클린 코드를 만드는 비결이다.”

n  짤막한 문단 몇 개로 론은 이 책의 내용을 요약했다. 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. 이상이다.

l  워드 커닝엄(Ward Cunningham), 위키wike 창시자, 피트Fit 창시자, 익스트림 프로그래밍 eXtreme Programming 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 스몰토크Smalltalk와 OO의 정신적 지도차, 코드를 사랑하는 프로그래머들의 대부

n  “코드를 읽으며 짐작했던 기능을 각 루틴이 그대로 수행한다면 클린 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.”

n  클린 코드 코드는 읽으면서 놀랄 일이 없어야 한다고 워드는 말한다. 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다. 읽으면서 짐작한 대로 돌아가는 코드가 클린 코드다. 이만큼 클린 코드는 너무도 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다. 모든 뛰어난 설계처럼 설계자가 코드를 어이없을 정도로 단순하게 설계했기 때문이다.

n  우리는 항상 언어가 문제에 적합하지 않다며 언어를 비난한다. 하지만 워드는 그 책임을 우리 자신에게 돌린다. “코드가 그 문제를 풀기 위한 언어처럼 보인다면” 아름다운 코드라 말한다. 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다는 뜻이다! 우리 업계에는 특정 언어를 신봉하는 광신자가 아주 많다. 하지만 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다.

4       우리들 생각 (48p)

l   이 책은 우리 오브젝트 멘토 진영이 생각하는 클린 코드를 설명한다. 여기서 가르치는 교훈과 기법은 우리 진영이 믿고 실천하는 교리다. 우리가 가르치는 교훈을 따른다면 우리가 만끽한 이익을 여러분도 만끽하리라 감히 장담한다. 우리가 가르치는 기법을 따른다면 깨끗하고 수준 높은 코드를 작성하리라 감히 장담한다. 하지만 우리의 생각이 절대적으로 ‘옳다’는 단정은 금물이다. 실제로 이 책에서 주장하는 기법 다수는 논쟁의 여지가 많다. 하지만 다른 한 편으로 이 책은 우리가 오랫동안 고민하고 숙고한 교훈과 기법을 권고한다. 수십 년에 걸친 경험과 반복적인 시행착오로 습득한 교훈과 기법이다. 그러므로 여러분이 동의하던 동의하지 못하든 우리 시각을 이해하고 존중하려 애써주면 좋겠다.

5       우리는 저자다 (49p)

l   우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.

l   새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. (필자의 이맥스Emacs 개발 편집기는 사용자가 입력한 모든 키를 기억했는데, 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10:1을 훌쩍 넘겼다)

n   읽기 쉬운 코드가 매우 중요하다. 비록 읽기 쉬운 코드를 짜기가 쉽지는 않더라도 말이다. 하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.

6       보이 스카우트 규칙 (50p)

l   “캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라” – 미국 보이 스카우트

n  코드를 잘 짰다고 전부가 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 체크인할 때보다 좀더 클린 코드를 체크인한다면 코드는 절대로 나빠지지 않는다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

7       전편과 원칙 (51p)

l     많은 면에서 이 책은 필자가 2002년에 출판한 [Agile Software Development: Principles, Patterns, and Practices(PPP)] (한국어판: 소프트웨어 개발의 지혜)의 전편이다. PPP 책은 객체 지향 설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개한다. PPP는 이 책에서 하는 이야기를 이어간다. SRP(Single Responsibility), OCP(Open Closed Principle), DIP(Dependency Inversion Principle) 등이 그 예다. 각 원칙은 PPP에서 자세히 설명한다.

8       결론 (51p)

l     이 책을 읽는다고 우수한 프로그래머가 된다는 보장은 없다. ‘코드 감각’을 확실히 얻는다는 보장도 없다. 단지 우수한 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다. 나머지는 여러분에게 달렸다.

9       참고 문헌 (51p)

l    [Beck07]: Implementation Patterns, Kent Beckm Addison-Wesley, 2007

한국어판: 켄트 백의 구현 패턴, 켄트 백 지음, 전동환 옮김, 에이콘 출판 2008년 출간

l    [Knuth92]: Literate Programming, Donald E. Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992.