🔖 오늘 읽은 범위 : 4장. 실용주의 편집증

❗ 소감 3줄 요약

- 완벽한 소프트웨어는 없다. - '그런 일은 일어나지 않을거야.' 라는 생각을 하지말고 증명하자. - 신중하게 작은 단계부터 계획을 세워 피드백을 받자.

😃 책에서 기억하고 싶은 내용을 써보세요.

[ 계약에 의한 설계 ]

정직한 거래를 보장하는 최선의 해법 중 하나는 "계약" 이다.

DBC

버트런드 마이어는 에펠이라는 언어를 만들면서 계약에 의한 설계 개념을 개발했다. DBC는 단순하지만 강력한 기법으로 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다.

소프트웨어 시스템의 모든 함수와 메서드는 뭔가를 한다. 그 뭔가를 시작하기 전에 해당 함수는 세상의 상태에 대해 어떤 전제 조건을 갖고 있을 테고, 루틴이 끝난 후에는 세상의 상태가 어떠할 것이라고 선언할 수 있을 것이다. 마이어는 이런 전제와 선언을 다음과 같이 설명한다.

- 선행 조건

루틴이 호출되기 위해 참이어야 하는것. 즉 루틴의 요구사항이다.
제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임이다.

- 후행 조건

루틴이 자기가 할 것이라고 보장하는 것.
루틴에 후행 조건이 있다는 것은 곧 루틴이 종국에는 종료될 것이라는 걸 의미한다.
무한 반복은 허용되지 않는다.

- 클래스 불변식

호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다.

- 루틴과 그 루틴을 호출하려는 코드간 계약

만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료시 모든 후행 조건과
불변식이 참이 되는 것을 보장한다.

- 클래스 불변식과 함수형 언어

에펠이 객체 지향 언어였던 탓에 마이어는 개념을 클래스 불변식이라고 이름 붙였다.
이 용어가 진짜로 의미하는 것은 상태다.

- DBC 구현

코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지,
루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을
나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다.

- 클래스 불변식과 함수형 언어

에펠이 객체 지향 언어였던 탓에 마이어는 개념을 클래스 불변식이라고 이름 붙였다.
이 용어가 진짜로 의미하는 것은 상태다.

[ 죽은 프로그램은 거짓말을 하지 않는다. ]

'그런 일은 절대 일어날 리 없어.' 라는 사고에 빠지기 쉽다.
우리가 코드를 작성할 때 파일이 성공적으로 닫혔는지, 혹은
트레이스 문이 우리 예상대로 찍혔는지 확인하지 않았던 적이 있을 것이다.

반면에 실용주의 프로그래머는 만약 오류가 발생했다면
정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다.
일단 그놈의 오류 메시지 좀 읽어라.

망치지 말고 멈춰라

- 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다.

[ 단정적 프로그래밍 ]

모든 프로그래머가 자기 경력을 쌓는 초기부터 암기해야 하는 계명이 있는 것 같다.
요구 사항, 설계, 코드, 주석 등 우리가 하는 거의 모든 것에 적용하도록 배우는
컴퓨팅의 근본 교리이자 핵심적 믿음이다. 그것은 이렇게 시작한다.

'하지만 물론 그런일은 절대 일어나지 않을 거야.' 라는 생각이 든다면
그런일을 확인하는 코드를 추가하라.

[ 헤드라이트를 앞서가지 말라 ]

캄캄한 늦은 밤, 폭우가 쏟아지고 있다.
스포츠카 한 대가 굽이굽이 이어진 좁은 산길을 거칠게 질주한다.
간신히 코너를 빠져나오나 했는데 그만 다음 급커브를 놓치고 말았다.
부실한 가드레일을 들이받더니 허공을 날아 계곡 아래에 화염을 일으키고 만다.
경찰관들이 현장에 도착한다.
수사관 하나가 고개를 절레절레 흔들며 말한다.
"헤드라이트를 앞서간 것이 틀림없어."

스포츠카가 정말로 빛의 속도보다 빠르게 달렸을까? 그럴리가.
빛의 속도는 고정불변이다.
수사관이 한 말은 운전자가 헤드라이트 불빛이 비춘 것을 보고 반응하여
차를 멈추거나 핸들을 꺾는 능력을 가리킨 것이다.

- 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. 너무 큰 단계나 작업은 하지 않게 될 것이다.

❗ 소감 3줄 요약

- 혼자 진행하는 프로젝트더라도 기록을 남기자 - 완벽한 코드는 없다. 버그는 항상 존재한다고 생각하자 - 올바른 디버깅 순서, 디버깅 방법

😃 책에서 기억하고 싶은 내용을 써보세요.

[ 일반 텍스트의 힘 ]

실용주의 프로그래머로서 우리의 기본재료는 나무나 쇠가 아니라 지식이다.
지식을 저장하는 최고의 포맷이 일반 텍스트라고 믿는다.

일반 텍스트란?

일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다. 쇼핑 목록처럼 간단할 수도 있다.

우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 한다.

텍스트의 힘

HTML, JSON, YAML 등은 모두 일반 텍스트다. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.

지원 중담에 대한 보험

일반 텍스트 파일은 포맷을 부분적으로밖에 알지 못하더라도 파싱할 수 있다.

더 쉬운 테스트

시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.

[ 셸 가지고 놀기 ]

GUI의 장점은 WYSIWYG (What You See Is What You Get), 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG (What You See Is All You Get), 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것

자신만의 셸

목수가 작업 공간을 자신에게 맞추어 바꾸듯이 개발자도 셸을 자신에게 맞추어야 한다.

- 색깔 조합 설정

- 프롬프트 설정

- 별칭과 셸 함수

- 명령어 자동 완성

[ 버전 관리 ]

우리가 사용자 인터페이스에서 중요하게 여기는 것 중에 실행 취소undo 키가 있다. 실수를 용서해 주는 버튼.

하지만 실수가 지난주에 발생했고 그 이후로 컴퓨터를 열 번은 껐다 켰다면 어떨까? 이것이 바로 버전 관리 시스템 (version control system), VCS을 사용하는 데서 생기는 여러 가지 이득 가운데 하나다.

버전 관리 시스템은 소스 코드나 문서의 모든 변경 사항을 기억한다. 바르게 설정된 버전 관리 시스템이 있으면 소프트웨어의 이전 버전으로 언제든지 되소프트웨어의 이전 버전으로 언제든지 되돌아갈 수 있다.

혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 버리기로 한 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라.

브랜치 사용하기

브랜치의 장점 중에 다른 브랜치로부터 격리된다는 것이 있다.

프로젝트 허브로서의 버전 관리

• 확실한 보안과 권한 관리
• 직관적인 UI
• 명령 줄에서도 모든 작업 수행 가능(작업을 자동화할 때 필요하다.)
• 자동화된 빌드와 테스트
• 브랜치 병합(풀 리퀘스트pull request라고 부르기도 한다)을 잘 지원
• 이슈 관리. 커밋이나 브랜치 병합과 연계가 가능하고 지표도 구할 수 있으면 이상적이다.
• 적절한 보고서 기능. 칸반 보드Kanban board 형식으로 처리할 이슈나 작업을 표시할 수 있으면 매우 유용하다.
• 원활한 팀 의사소통을 돕는 기능. 변경 사항이 있을 때 이메일 혹은 다른 수단으로 알려준다든지, 위키를 제공한다든지 하는 등등

[ 디버깅 ]

버그라는 단어는 14세기 이래 공포의 대상을 지칭하는 단어로 사용되어 왔다. 코볼COBOL의 창안자인 해군 제독 그레이스 호퍼 박사는 최초로 컴퓨터에서 버그, 그러니까 벌레를 발견한 것으로도 알려져 있다.

지금도 컴퓨터 시스템은 여전히 여러분이 명령하는 것명령하는 것을 할 뿐, 여러분이 원하는 것원하는 것을 알아서 하지 않는다.

디버깅의 심리

• 디버깅은 단지 문제 풀이문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
• 남을 비난하기보다 문제문제를 고치는 데에 집중해야 한다.

디버깅 사고방식

• 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각생각해 보는 것이 정말 중요하다.
• 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.

실마리 찾기

• 버그를 살펴보기 전에살펴보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라.
• 우리는 우연한 사건들을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다.
• 자세한 정보를 충분히 얻으려면 해당 버그를 보고한 사용자가 시연하는 것을 눈으로 직접 확인해야 할 수도 있다.

디버깅 전략

여러분이 무슨 일이 벌어지고 있는지 파악했다는 생각이 들었다면, 이번에는 프로그램은 어떻게 생각하는지 알아낼 차례다.

버그 재현하기

• 버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.
• 우리는 명령 하나로 재현할 수 있기를 바란다. 버그가 출현하는 시점까지 열다섯 단계를 거쳐야 한다면 버그 수정은 훨씬 어렵다.
• 디버거를 붙인 다음 여러분의 실패하는 테스트를 이용하여 문제를 재현하라.
• 디버거에서 호출 스택 위아래로 어떻게 이동하고, 스택의 지역 변수를 어떻게 확인하는지 숙지하라.

디버깅 전략

• 예상치 못한 놀라운 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다.
• 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 안다고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락이 맥락 안에서, 이 데이터이 데이터로, 이 경계 조건이 경계 조건하에서 증명하라.
• 버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 바로 지금 그것들을 찾아서 고쳐야 한다. 어떤 일이 일어났어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.
• 버그를 고치는 데 시간이 오래 걸린다면 왜 그런지 자문하라. 무엇을 하면 다음번에는 이 버그를 좀 더 쉽게 고칠 수 있을까? 더 나은 테스트 훅을 만들어 넣거나, 로그 파일 분석기를 작성할 수도 있겠다.

❗ 소감 3줄 요약

- 좋은 설계를 하기 위해선 어떻게 해야 될까? - 예광탄코드와 프로토타이핑의 차이 - 프로젝트 일정을 추정할때는 어떤 방법이 좋을까?

😃 책에서 기억하고 싶은 내용을 써보세요.

[ 좋은 설계의 핵심 ]

ETC 원칙을 따른다. 바꾸기 바꾸기 더 쉽게더 쉽게(Easier to Change). ETC. 이게 전부다.

왜 결합도를 줄이면 좋은가? - 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.

왜 단일 책임 원칙(single responsibility principle1)이 유용한가? - 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.

왜 이름 짓기가 중요한가? - 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.

ETC는 규칙이 아니라 가치 - 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 바꾸기 쉽게라는 길을 선택한다. 바로 여러분이 작성하는 코드를 교체하기 쉽게 만들도록 노력하는 것이다.

- 엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스 코드에 이에 대한 표시를 남겨 둬라.

[ DRY: 중복의 해악 ]

프로그래머로서 우리는 지식을 수집하고, 조직하고, 유지하며, 통제한다. 
우리는 지식을 명세(specification)로 문서화하고, 실행 코드를 통해 그 지식에 생명을 부여한다.

모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위있게 표현되어야 한다. 

- 개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.

- 일일 스크럼 스탠드업 미팅을 운영해 볼 수 있다. 슬랙(Slack) 채널같이 공통의 문제를 다루기 위한 공간을 만들라.

- 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라.

[ 직교성 ]

직교성은 기하학에서 빌려 온 용어다. 
그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다.

컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기(decoupling)를 의미한다.

직교성의 장점 - 직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다.

- 생산성 향상 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다 직교적인 접근법은 재사용도 촉진한다. 시스템이 더 느슨하게 결합되어 있을수록 재조합하고 개량하기 쉽다.

- 리스크 감소 감염된 코드가 격리되어 있다. 시스템이 잘 깨지지 않는다.

툴킷과 라이브러리 - 외부에서 만든 툴킷이나 라이브러리를 도입할 때 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보기 바란다.

코딩

- 코드의 결합도를 줄여라 부끄럼쟁이shy 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.

- 전역 데이터를 피하라 싱글턴을 사용할 때는 주의를 기울여라. 싱글턴은 불필요한 결합을 만들 수 있다.

- 유사한 함수를 피하라 - 테스트 - 문서화

[ 가역성 ]

당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.

가역성 - 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

유연한 아키텍쳐 - 여러분의 코드가 로큰롤(rock-n-roll)을 할 수 있게 하라. 락을 할 수도 있고 필요한 경우 롤을 할 수도 있게 하는 것이다.

[ 예광탄 ]

어둠 속에서 빛을 내는 코드 - 예광탄이 효과적인 까닭은 일반 탄환과 동일한 환경 및 제약 조건에서 발사되기 때문이다. 탄환이 순식간에 목표물에 도달하기 때문에 기관총 사수는 즉각적인 피드백을 얻을 수 있다.

- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다. - 개발자가 들어가서 일할 수 있는 구조를 얻는다. - 통합(integration) 작업을 수행할 기반이 생긴다. - 보여줄 것이 생긴다. - 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

예광탄 코드 대 프로토타이핑 - 프로토타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것이다.

[ 프로토타입과 포스트잇 ]

프로토타입을 어떻게 사용할 것인가? 프로토타입을 만들 때 무시해도 좋은 세부 사항은 무엇인가?

- 정확성 적절히 가짜 데이터를 사용할 수 있다. - 완정성 프로토타입은 제한된 방식으로만 작동하기도 한다. 어쩌면 미리 선정한 입력데이터 하나와 한 가지 메뉴 항목만 작동해도 될 것이다. - 안정성 오류 검사를 빼먹거나 아예 무시할 수도 있다. - 스타일 프로토타입 코드에는 주석이나 문서가 많지 않아야 한다.

프로토타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다.

프로토타입 코드를 사용하지 않도록 하려면? - 프로토타입을 코드로 만들 때는 시작하기 전에 항상 모든 사람에게 여러분이 폐기 처분할 코드를 작성하고 있다는 사실을 이해시켜야 한다. - 프로토타입임을 모르는 사람에게는 오해를 살 정도로 매력적일 수도 있기 때문이다. - 코드는 폐기할 것이고, 불완전하며, 완성할 수 없다는 사실을 분명히분명히 주지시켜야 한다.

[ 추정 ]

미국 워싱턴 D.C.의 의회 도서관은 현재 75테라바이트의 디지털 정보를 온라인에 올려 두고 있다고 한다. 
빠르게 대답하라! 1Gbps 네트워크로 이 정보를 모두 전송하려면 시간이 얼마나 걸릴까? 
백만 개의 이름과 주소를 저장하려면 저장 공간이 얼마나 필요할까? 
100Mb의 텍스트를 압축하는 데 시간이 얼마나 필요할까? 
프로젝트가 끝나려면 몇 개월이 더 필요할까?

얼마나 정확해야 충분히 정확한가?

추정치는 어디에서 나오는가?

- 무엇을 묻고 있는지 이해하라 - 시스템의 모델을 만들어라 - 모델을 컴포넌트로 나눠라 - 각 매개 변수에 값을 할당하라 - 답을 계산하라 - 여러분의 추정 실력을 기록하라

프로젝트 일정 추정하기

- 미사일에 페인트칠하기

A: 이 집에 페인트를 칠하려면 얼마나 걸릴까요?
B: 글쎄요. 아무 문제가 없고 페인트 제품 설명에 나오는 리터당 도포 면적이 정확하다면
10시간 만에도 될 겁니다. 
B: 하지만 사실 그보다는 더 걸릴 것 같군요. 18시간이 더 현실적인 숫자인 것 같습니다. 
B: 물론 날씨가 나빠지면 30시간 넘게도 걸릴 수 있지요.

미 해군이 폴라리스라는 잠수함 발사용 탄도 미사일 개발 프로젝트 계획을 세울 때 프로그램 평가 검토 기법(Program Evaluation Review Technique) 혹은 줄여서 PERT라고 부르는 방법론을 만들면서 이런 추정 방식을 도입했다.

과업을 의존성에 따라 네트워크 형태로 배열한 후, 간단한 통계 기법을 사용하여 전체 프로젝트의 예상 최소 및 최대 소요 시간을 계산한다.

하지만 우리는 PERT를 썩 좋아하지 않는다. 사람들은 벽을 가득 채우는 큰 차트에 프로젝트의 모든 과업을 그려 놓고는 은근히 자신들이 정확한 추정치를 갖고 있으리라 믿는다.

- 코끼리 먹기

- 요구 사항 확인하기 - 위험을 분석하고 위험도가 높은 부분을 우선하기 - 설계, 구현, 통합 - 사용자와 함께 검증하기

초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복 주기의 끝으로 삼아라. 첫 반복 주기의 경험을 바탕으로 반복 주기의 수와 각 반복 주기에서 무엇을 할지에 대한 처음의 추측을 다듬을 수 있을 것이다.

이런 추정은 보통 각 반복 주기가 끝날 때 팀 리뷰 회의 시간에 한다.

이 방법은 경영진에게 별로 인기가 없다. 경영진은 보통 프로젝트가 시작되기도 전에 하나의 정확한 숫자를 원하기 때문이다.

이를 공식화하고 더 정확한 일정을 추정하는 것을 각 반복 주기의 일부로 삼았을 때, 여러분이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있을 것이다.

누군가 추정해 달라고 하면 뭐라고 대답해야 할까? - "나중에 연락드릴게요." 라 말해야 한다. 잠시 손을 멈추고 시간을 내어 이번 항목에서 설명한 단계를 밟아 나간다면 대부분의 경우 더 좋은 추정치를 얻을 수 있을 것이다. 커피 머신 앞에서 허투루 말한 추정치는 커피와 마찬가지로 여러분에게 해를 끼칠 것이다.

❗ 소감 3줄 요약

- 책임지기 - 깨진창문, 망가뜨리지 말라 - 지식 포트폴리오, 커뮤니케이션

😃 책에서 기억하고 싶은 내용을 써보세요.

[ 당신의 인생이다 ]

당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 
업무환경이 엉망인가? 하는일이 지루한가? 문제를 고치기위해 노력하라. 
하지만 오랫동안 노력하지는 말라. 당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.

기술에 뒤쳐지는 기분이 든다면 여가시간을 쪼개서 재미있어 보이는것을 공부하라.

[ 고양이가 내 소스 코드를 삼켰어요 ]

팀 내 신뢰, 책임지기

자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점에도 인정해야만 한다.

결과에 대한 책임을 지기지기로 했다면 나중에 그 결과를 감당해야 할 것이다. 실수를 저지르거나 (누구나 실수를 한다) 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.

변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지할 수 있는지 설명하라.

부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.

잘 모르겠어요.라고 말했다면, 꼭 바로 이어서 하지만 알아볼게요.라고 말하라. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.

[ 소프트웨어 엔트로피 ]

엔트로피는 시스템 내의 무질서한 정도를 가리키는 물리학 용어다.
소프트웨어의 무질서도가 증가할 때 우리는 이를 소프트웨어의 부패라고 일컫는다.

깨진 창문, 우선, 망가트리지 말라

명백히 망가진 상황을 무시하는 것은 아무것도 고쳐지지 않을 것 같다는 생각, 아무도 신경 쓰지 않는다는 생각, 망조가 들었다는 생각을 더 굳어지게 만든다.

깨진 창문을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것판자로 덮는 것만이라도 하라.

더 이상의 손상을 예방하기 위해 어어떤 조치든떤 조치든 취하고 여러분이 상황을 잘 관리하고 있음을 보여 줘라.

방치는 다른 어떤 요인보다도 부패를 더 가속가속시킨다.

엔트로피가 우리를 지배하도록 내버려 두지 말라.

어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라. 깨진 창문은 하나로 충분하다.

깨진 창문 이론이 나온 최초의 실험에서는 버려진 자동차 한 대가 일주일 동안 방치되었어도 아무도 손대지 않았다. 하지만 창문 딱 하나가 깨지자 몇 시간몇 시간 만에 자동차 내부는 도난을 당했고 차체는 엉망이 되었다.

비록 불길이 일어날지라도(데드라인, 출시 날짜, 시사회 데모 등) 코드를 엉망진창으로 만들고 필요 이상의 손상을 가하는 첫 번째 사람이 자신자신이 되는 것만은 피하려 할 것이다.명심하라. 깨진 창문은 없어야 한다.

프로젝트를 함께 하는 동료의 생각을 조사하여 팀을 더 튼튼하게 만들라. 깨진 창문을 두세 개 고른 다음, 여러분의 동료들과 함께 무엇이 문제고 그걸 고치기 위해 무엇을 할 수 있는지 토론하라.

[ 적당히 괜찬은 소프트웨어 ]

타협 과정에 사용자를 참여시켜라

그저 프로그램에 새 기능을 추가하거나 코드를 한 번 더 다듬기 위해서 이런 사용자의 요구 사항을 무시하는 것은 전문가답지 못하다.

불가능한 시간 약속을 하거나 데드라인에 맞추기 위해 기본적인 걸 빼 버리거나 하는 것 역시 똑같이 전문가답지 못하다.

사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.

멈춰야 할 때를 알라

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라.

[ 지식 포트폴리오 ]

새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다.
여러분의 지식 가치가 점점 떨어짐에 따라 회사나 클라이언트가 보는 여러분의 가치 역시 떨어진다. 
우리는 이런 일이 일어나지 않도록 예방하고 싶다.

지식 포트폴리오

- 진지한 투자자는 주기적으로 투자하는 습관이 있다.

- 장기적인 성공의 열쇠는 다각화다.

- 똑똑한 투자자는 보수적인 투자와 위험이 크지만 보상이 높은 투자 사이에서 포트폴리오 균형을 잘 맞춘다.

- 투자자는 최대 수익을 위해 싸게 사서 비싸게 팔려고 한다.

- 포트폴리오는 주기적으로 재검토하고 재조정해야 한다.

비결은 일단 스스로 한 번 해본 다음, 습관을 들이는 것이다. 따라 할 절차를 만든 다음 여러분의 뇌에 각인될 때까지 반복하라. 그러고 나면 새로운 지식을 무의식적으로 빨아들이는 자신을 발견할 수 있을 것이다.

포트폴리오 만들기

- 주기적인 투자

- 다각화 더 여러 가지여러 가지를 알수록 자신의 가치는 더욱 높아진다. 오늘 인기 있는 기술이 내일이면 거의 쓸모없어지거나 그 정도는 아니어도 수요가 없어지기도 한다. 기술 외의 분야도 포함하여 여러분에게 필요한 다른다른 역량도 잊지 말라.

- 리스크 관리 여러분의 기술 달걀을 모두 한 바구니에 담지 말라.

- 싸게 사서 비싸게 팔기 자바가 막 나와서 유명하지 않았을 때 자바를 학습하는 게 당시엔 리스크가 있었을 것이다. 자바가 산업의 중심을 차지하면서 얼리 어답터들은 큰 이득을 얻었다.

- 검토 및 재조정

목표

- 매년 새로운 언어를 하나는 배워라 - 기술 서적을 한 달에 한 권씩 읽어라 현재 프로젝트와 관련 있는 흥미로운 주제의 기술 서적을 서점에서 찾아보라. 현재 사용하는 기술을 일단 완전히 익혔다면, 가지를 쳐서 지금 하는 프로젝트와 관련 없는없는 분야까지 공부 범위를 넓혀라.

- 기술 서적이 아닌 책도 읽어라 컴퓨터도 사람사람이 사용한다는 걸, 그리고 우리는 바로 이 사람들을 만족시키려고 노력하고 있다는 걸 꼭 기억해야 한다.

- 수업을 들어라

- 지역 사용자 단체나 모임에 참여하라. 고립은 경력에 치명적일 수 있다. 가만히 듣고만 오지 말고 적극적으로 참여하라.

- 다른 환경에서 실험해 보라

- 요즘 흐름을 놓치지 말라 현재 프로젝트에서 사용 중인 것과는 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라 한 기술의 새로운 용어나 기능에 익숙해지면 다음으로 나아가라. 또 다른 것을 배워라.

학습의 기회

거기서 멈추지 말라. 답을 찾기 위한 개인적인 도전으로 생각하라. 주위에 물어보라. 웹을 검색해 보라. 사용자용 문서뿐 아니라 학술 자료도 찾아보아야 한다.

스스로 답을 찾지 못하겠거든 답을 찾아줄 수 있는찾아줄 수 있는 사람을 찾아라. 중단하지 말라.

비판적 사고

읽거나 듣는 것에 대해 비판적으로비판적으로 생각하는 것이다.

상업주의의 힘을 절대 과소평가하지 말라. 웹 검색 엔진의 첫머리에 나온 결과라고 해서 그것이 최선이라는 의미는 아니다.

[ 소통하라! ]

최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다.
코드를 작성하는 것은 우리의 의도를 기계에게 전달하는 것이기도 하지만, 생각을 기록하여 다음 세대의 개발자들에게 전달하는 것이기도 하다.
여러분이 의사소통에 사용하는 언어(그게 한국어든 영어든)도 또 다른 프로그래밍 언어일 뿐이라 여겨라.

청중을 알라

그저 말하는 것만으로는 부족하다. 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.

그저 질문을 기다리지 말고 먼저 물어보라. 손짓, 몸짓과 표정을 관찰하라.

소통하면서 청중에 대한 지식을 쌓아 나가라.

말하고 싶은 게 무언지 알라

무엇을 말할지 미리 계획하라. 개요를 작성하라. 그리고 자문하라. 이렇게 하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나? 그렇게 될 때까지 다듬어라.

의사소통하고 싶은 아이디어들을 적은 다음 제대로 전달하는 데 필요한 전략을 몇 개 세워라.

때를 골라라

청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.

스타일을 골라라

이 분야에서 상대의 기술 수준이나 경험이 어떤가? 전문가인가, 아니면 신참인가? 손을 잡고 이끌어 줘야 할까, 아니면 짧게 세 줄 요약만 해주면 될까? 뭐가 좋을지 모르겠거든 물어보라.

멋져 보이게 하라

여러분의 아이디어는 중요하다. 그러니 마땅히 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다. 모양새에 신경 쓰지 않으면 부엌에서 수 시간 뼈 빠지게 일한 노력이 헛수고가 될 수 있다는 것을 말이다.

맞춤법을 확인하라. 우선은 자동으로, 그다음엔 직접 눈으로 검사하라. 검사기가 잡아내지 못하는 맞춤법 실수도 있다.

청중을 참여시켜라

독자가 문서 초안에 참여하도록 하라. 피드백을 받고 그들의 머릿속을 도용하라.

경청하라

질문을 해서 사람들이 이야기를 하도록 북돋우거나, 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라.

응답하라

언제나 이메일과 음성 메시지에 답을 하라. 심지어 응답이 단순히 다음에 답해 드리겠습니다.이더라도.

문서화

모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다.

코드에 주석을 쓸 때는 왜왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다.