실용주의 프로그래머 key takeaway for myself.

1장

깨진 창문을 그대로 두지말자.
깨진 창문에는 Not Implemented 혹은 Dummy data를 추가하는 방식으로 구현해둘 것.

카펫을 더럽히는 일(기존 코드를 바꾸는 작업)은 필요한 순간이 온다.
카펫을 더럽히기 싫어서 가던 곳으로 가지 말고 필요하다면 과감하게 바꿀 것.

적당히 괜찮은 것이 늦어지는 것보다 낫다.
약간의 버그를 감내하더라도 그걸 다듬는다고 망치지마라. 언제 멈춰야할지를 알자.어차피 완벽한 코드란 없다.

지식이란 투자 포트폴리오와 같다.
지식을 다각화하고 (한 분야의 외골수보다 다양한 분야로) 계속해서 투자(계속해서 공부할 것)하며 리턴과 리스크의 조정을 적절히 하고 (기술 배울 때 선택) 주기적으로 재점검 하자.
- one new language per year
- 기술서적을 분기마다 하나씩. (볼 것을 좀 정해두면 좋겠다)

소통도 분위기를 파악해가며 하자.
말을 하기 전에 미리 적절히 정리해놓을 것. 말할 타이밍을 잘 계산하고 말할 것.

2장

강력하게 Coupling 된 Task는 하나만 해도 다른 하나가 업데이트 되도록 자동화를 시켜두자.
테스트 코드가 문서에 따라 자동으로 만들어지는 사례가 있었다. 만약 문서와 코드의 관계가 깊게 coupling 된 관계라면 문서 혹은 코드를 업데이트할 때 이와 관련 된 작업 혹은 the other one도 똑같이 자동으로 업데이트 할 수 있도록 개선하자.

직교성(Orthogonality)은 중요하다.
프로그래밍에서 직교한다라는 말은 하나가 수정되어도 다른 것에 영향을 주지않는다는 의미로 Decoupled 상태라고 볼 수 있다. 회의에서 직교성을 살펴보는 방법도 재미있다. 어떤 주제로 회의를 하려고 할 때 불러야 하는 사람 수가 많아질수록 직교성이 낮다는 것을 의미한다.
잘못 된 객체지향 코드는 때때로 절차지향 코드보다도 더욱 더 스파게티 코드가 될 확률이 높다.

예광탄 코드를 먼저 쏘아올리자.
POC(Proof Of Concept)와 비슷하지만 좀 더 큰 개념. 동일한 환경과 제약을 가진채 Full feature가 아닌 적당한 간보는 수준의 Feature를 먼저 구현하면 걸림돌을 사전에 발견할 수 있다. 단, 이것은 쓰고 버리는 코드가 아니다. 목표물은 맞추되 그 외의 기능은 배제한채로 빠르게 구현해서 눈에 보이도록 하는 것이다. 프로토타입은 쓰고 버릴 코드이고, 예광탄 코드는 완결 된 하지만 Full feature는 아닌 코드를 의미한다는 것을 기억하자.