The Clean Coder

Photo by Max Nelson on Unsplash

책 링크: http://www.acornpub.co.kr/book/clean-coder#toc

알라딘: http://aladin.kr/p/MJJw1

 

최대한 간결하게 감상을 적어보자

 

개발자로서 프로다운 모습, 장인의 면모를 갖추자는 것이다.

할 만큼 했다는 식은 프로답지 못하다. 하라는 데로 하겠지만 얼마나 잘되지 보자는 심보는 최악이다. (수동적 공격성: passive-aggressive)

 

프로는 지식을 쌓아야 하고 그것을 책임있게 행동으로 옮긴다.

 

테스트하기 쉽게 코드를 짜야 한다.

구조가 좋아야 코드를 쉽게 변경할 수 있다.

아닌건 아니라고 말할 수 있는 용기가 있어야 한다.

 

몰입은 좋은게 아니다. 큰 그림을 놓치게 되고, 다른 사람과의 협업을 방해한다.

짝 프로그래밍은 좋은 해법이다.

 

테스트 주도  개발을 하자. 테스트의 진정한 목적은 사양을 명확하고 세세하게 정리하는 것이다.

일정을 추정하는 것은 어렵다. PERT, wideband delphi 등의 기법을 써보자.

 

하나의 팀을 잘 숙성시켜서 이를 유지하며 여러 프로젝트를 처리하는 것이 맞다.

프로젝트에 팀원들이 나뉘고 갈리는 것은 잘못된 것이다.

 

주요 밑줄과 정리들

 

추천의 글 - 매튜 휴저	"이 책은 어떤 식으로 프로다운 모습을 보이고 다른 사람들을 대해야 할지 한 단계씩 알려준다. 진부하거나 글로만 가능한 내용이 아니라 할 수 있는 일을어떻게  해야할 지 알려준다."
옮긴이의 말	"억지를 부리며 일정을 줄여보라는 마이크에게 끝까지 안 된다고 말하는 폴라가 인상적이었습니다." "덧없이 가련하오 지난 세 번의 여름이여."
들어가며	챌린저 우주왕복선의 폭파 - 기술자는 7년 전부터 문제제기를 해왔다. - 기술자들은 위험이 너무 크다는 사실을 알고 있었다. - 회의에서 자료를 발표하고, 화를 내고 구슬리고 항의하기도 했지만 "결국 관리자들은 기술자들을 무시했다."   → 하지만 기술자들이 정말 최선을 다했을까?
이 책에서 다루는 내용	- 소프트웨어 프로란 무엇이며 어떻게 행동해야 하는가? - 사람들간 대립, 일정, 불합리한 관리자를 어떻게 감당하는가? - 언제 예, 아니오라 말해야 하는가? - 주위의 압박을 어떻게 처리하는가?   "기술장인이 되겠다는 막중한 책임을 기꺼이 짊어지겠다는 의지다." "기술자라면 시스템과 프로젝트에 대해 관리자는 알기 힘든 깊은 지식을 알아야 한다. 그 지식을 가지고 행동으로 옮겨야할 책임이 있다."
미리 읽어두기	프로 프로그래머: 태도, 원칙, 행동 (attitude, discipline, action) 가 결정한다. "이 책을 내가 잘못한 일의 목록, 내가 저지른 범죄의 사건일지, 내가 초년생 때 했던 실수를 톡자들이 피할 수 있도록 만들어주는 안내서로 생각하자."
1장. 프로의 마음가짐	"프로페셔널리즘은 책임이 전부라 해도 과언이 아니다." "책임감을 가지고 미리 톰에게 테스트가 끝나지 않아서 제때 선적할 수 없다고 말했어야 옳았다."   "내가 말하고자 하는 바는 완벽하지 않다는 사실에 책임을 져야한다 는 것이다. 완벽한 소프트웨어를 만드는 일이 사실상 불가능하다는 것이지 완벽하지 않아도 괜찮다는 뜻은 아니다."   "코드에 결함이 있는 걸 알면서도 QA 에게 코드를 보내는 일은 매우 프로답지 못한 행동이다."   "그러니까 테스트를 자동화해야 한다." "어떤 코드는 테스트하기 어렵지 않나? 그렇다. 하지만 그 이유는 코드를 테스트하기 어렵게 설계했기 때문이다. 해결책은 테스트하기 쉽게 코드를 설계하는 것이다. 가장 좋은 방법은 테스트 코드를 먼저 작성한 다음, 그 테스트를 통과하도록 코드를 작성하는 것이다."   "전체 구조 (structure) 를 희생하면서까지 기능을 추가하는 일이 헛수고라는 사실은 프로라면 당연히 알고 있다. 구조가 좋아야 코드가 유연해진다." "한마디로 변경을 할때 터무니없는 비용을 치르지 않고 변경할 수 있어야 한다." → 최소한의 변경 비용   소프트웨어가 유연하려면 자주 구부려야 한다. 자주 수정하고 고쳐야 한다는 것이다. → 코드에 익숙해지고 또한 개선점이 보일 것이다.   코드 바꾸기가 무섭다 → 망가뜨릴까봐 → 왜 망가뜨릴까 무섭나? → 테스트가 없기 때문이다.   "자신의 경력은 자신이 책임져야 한다." → 알아서 공부하고 계발하라.   프로 소프트웨어 개발자라면 알아야 하는 최소한의 기술 목록 - 디자인 패턴, 설계원칙, 방법론, 원칙, 도구   끊임없이 배우고 연습하라 함께 일하고, 멘토링하라 업무 도메인의 지식을 익혀라 "회사의 문제가 자신의 문제다." 겸손하라
2장. 아니라고 말하기	"Do, Or do not. There is no try" - 요다 "프로라면 권위에 맞서 진실을 말해야 한다. 프로는 관리자에게 아니라고 말하는 용기를 가져야 한다."   어설프게 해볼깨요 말하면 안된다. Do, or do not 뿐이다. "절 해고해도  예측일은 바뀌지 않아요, 사장님"   "마이크, 당신을 위해 일을 끝내는 건 내가 할 일이 아니에요. 정말 내가 해야 할 일은 돈에게 알리는 거에요. 마이크가 안하면 내가 할 거에요."   "프로가 영웅이 될 때는 업무를 충실히 제 시간에 예산 안에서 완수했을 때다. 구세주라는 명예를 얻기 위해 존을 프로답지 못한 행동을 했다."
3장. 예라고 말하기	"말하고 진심을 담고 실행하라." "1. 하겠다고 말한다. 2. 진심을 담는다. 3. 실제로 실행한다."   Do not break discipline! "이 시점에서 피터는 원칙을 깨고 싶다는 유혹을 받는다. 테스트를 작성하지 않으면 빨리 끝날지 모른다. 리펙터링을 하지 않으면 빨리 끝날지 모른다. 전체 회귀 테스트 묶음을 실행하지 않으면 빨리 끝날지 모른다. 여기가 바로 프로가 선을 그아야 할 자리다."
4장. 코딩	충분히 건강한 몸과 마음상태에서 코딩하자. 근심이 있다면 얼른 해결하고 코딩하자.   몰입은 좋은게 아니다. "문제는 영역 (몰입)에 빠진 상태에서는 큰 그림을 놓쳐, 나중에 되돌려야 할 결정을 내리기 쉽다는 점이다." → 짝 프로그래밍은 몰입에 대한 좋은 해법이다.   동료가 도움을 요청하면 기꺼이 돕자. 신경질적이 된다는 것은 업무에 몰입했다는 것이다.   막혔을때 동료와 함께 보면 잘 풀리게 된다. 러버덕 디버깅, 페어 프로그래밍 업무외 다양한 창의적 입력을 받아들여라. 소설, 영화, 여행 등등 개인마다 다를 것이다.   테스트 주도 개발은 디버깅 시간을 엄청나게 줄여준다. 일정은 최선, 최악, 가능 셋으로 공유하라.   테스트를 만들어 그것을 통과해야 "완료" 한 것이다.
5장. 테스트 주도 개발	TDD 는 이제 논란의 여지가 없다. "중요한 것은 TDD 는 잘 돌아간다는 점이고, 이를 받아들여야 한다." 세가지 법칙 1) 실패한 단위테스트 먼저 만들기 2) 실패한 단위테스트가 하나도 없어야 다음 실패한 단위테스트 만들기 3) 실패한 단위테스트를 통과하는 코드를 만든 이후에 더 이상의 코드를 만들지 않는다.   확신: 단위테스트를 통과하면 제품을 출시해도 된다는 확신을 준다. 결함 주입 비율: TDD를 하면 새로운 코드를 추가하며 결함을 만드는 비율이 줄어든다. 용기: 두려움 없이 코드 변경이 가능하다. 문서화: 단위테스트 자체가 예제이자 문서이다. 설계: 테스트 하기 쉽게 만들려면 좋은 설계를 고민하게 된다. (의존성을 낮추게 된다. )
6장. 연습	"품새 연습은 단축키와 코드 관용구 (idiom) 탐색을 익히는 좋은 방법이다. TDD 나 지속적 통합 (CI: Continuous Integration) 을 익히는 데도 좋다."   로버트 C 마틴이 가장 좋아하는 품새 볼링게임: http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata 인수분해: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata 줄바꿈: http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html   다양하게 연습할 수 있다. - 합맞추기: 서로 잘아는 코드를 눈앞에서 짜보게 하기. 하나가 테스트를 만들고 다른 하나가 풀기 - 대련: 돌아가면서 테스트를 만들고, 통과 시킨다. - 다양한 프로그래밍 언어 사용하기 - 오픈소스 기여하기
7장. 인수 테스트	요구사항은 불확실하다. 실제 동작하게 해주면 그걸보고 요구사항은 새로워진다. 요구사항은 정밀도가 낮다. 그걸로 추정해보았자 불확실하다.   "요구사항에서 모든 모호함을 제거하는 일이 프로 개발자(그리고 이해당사자) 의 책임이다." (프로개발자에게) "완료란 다 됐다는 뜻이다."   인수테스트는 자동화 되어 있어야 한다. "프로 개발자들은 인수 테스트 자동화의 보장에 책임을 진다."   Unit Test: "단위테스트는 프로그래머가 프로그래머들을 위해 만든다." Acceptance Test: "인수테스트는 사업부를 위해 사업부가 작성한다. "   "테스트의 주 목적은 시스템의 디자인, 구조 및 행동을 공식적으로 문서화 하는 것이다." "테스트의 진정한 목적은 사양의 명세다."   "지속적 통합 시스템 (CI) 을 사용해 모든 단위 테스트와 인수 테스트를 하루에 몇 번이라도 실행할 수 있도록 확실히 하라. CI 시스템의 시작점은 소스코드 제어시스템 (VCS) 이 되어야 한다."
8장. 테스트 전략	"팀원으로서 QA 의 가장 중요한 역할은 명세 서술 (sepcifier) 과 특징 묘사 (charactorizer) 다." 사업부는 happy-path 테스트를 만들고 (이렇게 이렇게 하면 되야해), QA 는 unhappy-path 테스트를 만든다. (이렇게 이상하게 해도 문제 없을까?)   테스트 자동화 피라미드 - 단위 테스트: 프로그래머가 프로그래머를 위해 만든 테스트 - 컴포넌트 테스트: 인수 테스트의 일종. 테스트 대상이 아닌 컴포넌트는 테스트로부터 분리시킨다. - 통합 테스트 (integration): 컴포넌트들간의 소통 테스트 - 시스템 테스트: 시스템을 올바르게 빌드했는가? - 수동 탐색 테스트: 인간의 두뇌와 창의력으로 테스트   "TDD 는 강력한 원칙이며, 인수테스트는 요구사항을 표현하고 강화하는 가치있는 방법이다."
9장. 시간 관리	"어떤 논쟁이든 5분 안에 해결되지 않으면 논쟁으로는 해결할 수 없다." - 켄트 벡 "논쟁이 길어지는 이유는 양쪽 모두 근거가 되는 명백한 증거가 없기 때문이다."   수동적 공격성 (passive-aggressive) 어쩔 수 없이 동의하긴 하지만 얼마나 잘되나 보자 하는 심보 "가장 프로답지 못한 행동이다."   "프로는 개인적 두려움과 바람은 제쳐두고 각 업무의 우선순위를 검토하고 우선순위에 따라 순서대로 업무를 진행한다."   "프로는 막다른 길보다 진흙탕을 더 무서워한다." - 아예 안되는 게 확실한 것보다 질질 끌려가며 흘러가는 것
10장. 추정	"사업부는 추정을 약속으로 보길 좋아한다. 개발자는 추정을 어림짐작으로 보고 싶어한다."   PERT (Program Evaluation and Review Technique) - 운 좋을때 추정값, 가장 예상되는 추정값, 최악의 상황의 추정값을 정하고 적절한 확률 분포와 표준편차를 계산해낸다. - 5일쯤 걸릴 가능성이 높지만, 운 좋으면 3일, 재수 없으면 12일이 걸릴거라고 말할 수 있게 된다.   광대역 델파이 (wideband delphi) 기법 - 업무들에 대해서 여러명이 의견을 동시에 표현하고, 대충 비슷하면 넘어가지만 많이 다르면 논의한다. - Planning Poker: 계획 포커 방식은 카드를 사용한다. - Affinity Estimation: 관계추정은 각자 업무카드를 난이도에 따라 위치를 바꿔준다. 자주 바뀐 녀석들을 논의 한다.   큰 수의 법칙 - 작은 업무들의 추정의 합으로 전체 일정을 추정한다.
11장. 압박	"어떤 때라도 지저분함은 느리다는 의미다!"   Discipline: 위기일때에 규율을 지켜라. 위기로 정신이 없을때야 말로 규율에 따라 행동할 때이다. "애초에 규율을 세운 이유는 압박이 심해질 때 길잡이로 삼기 위해서다."
12장. 함께 일하기	"왜 이런 코딩을 해야 하고 그 코드로부터 회사가 어떤 이득을 얻을지 알아야 한다" "한마디로 프로는 탑승한 배가 어떻게 항해하는지 관심을 기울인다."   "나는 개인이 아니라 팀이 코드를 소유하길 바란다."   프로개발자가 짝 프로그래밍을 하는 이유는 1) 문제를 푸는 가장 효율적인 방법 2) 지식을 나누는 최고의 방법 3) 코드 리뷰하는 최고의 방법
13장. 팀과 프로젝트	사람이 프로젝트에 속하게 하지 말고, 팀이 프로젝트들을 관리한다. - 즉, A 는 P1, P2 를 담당하고 B 는 P1, P3 을 담당하게 하는게 아니라 - 팀이 P1, P2, P3 를 담당하게 하는 것이다. 이 경우 P2 가 갑자기 중요하게 되면 팀 자원을 한 곳으로 몰아주기 쉽다.   "팀원들이 각자의 차이점을 극복하고 서로를 받아들이고 진정한 한 덩어리가 되기에는 시간이 걸린다. 6달 정도 걸리기도 한다." "일단 한 덩어리가 되고 나면 프로젝트가 끝났다고 팀을 해체하는 일은 우스운 것이다. 팀원을 한데 모아 프로젝트를 던져주는 것이 최선이다." "프로 개발 조직은 이미 한 덩어리가 된 팀에 프로젝트를 배정하지 프로젝트 위주로 팀을 만들지 않는다."   "영구적인 팀을 만들어 이 프로젝트에서 저 프로젝트로 움직이게 하고 한 번에 여러 프로젝트를 맡기는 게 낫다."
14장. 스승과 제자 그리고 장인 정신	"어쩐 일인지 소프트웨어 개발 업계는 프로그래머는 그냥 프로그래머이기 때문에 학교만 졸업하면 코딩을 할 수 있다고 생각한다. " "나는 합리적인 훈련과 감독을 받는 실습 기간이 있어야 한다고 제안한다."   "장인 (craftsman) 이란 서두르지 않으면서도  일을 빠르게 처리하ㅕ 합리적인 평가를 제공하고 임무를 처리하는 사람이다. 그들은 "아니요"라고 말을 할 때를 알지만 "예"라고 대답하려고 노력한다. 장인은 프로다."
부록. 도구 활용	적을 내용 없음