Rule 1. 단순하게 짜라
단순성을 측정하기 : 양이 얼마나 많은가? 몇 가지 개념을 도입했는가? 설명하는 데 얼마나 시간이 걸리는가?
Rule 2. 버그는 전염병이다
"인터페이스에 묘사되어 있지 않은 것과 undefined 는 완전히 다르다. 어떤 식으로든 유저 (다른 개발자) 가 오해하지 못하도록 만들어라. (e.g., assert)
Rule 3. 이름은 중요하다
"일관성의 핵심은 모든 것이 기계적이어야 한다는 데 있다. 서커펀치에서는 변형된 헝가리안 표기법을 쓴다."
Rule 4. 세 가지 사례가 없으면 일반화하지 마라
추측에 근거해 더 일반적인(범용적인) 코드를 짜지 마라.
섣부른 일반화가 진짜 위험한 이유는, 코드베이스의 방향을 변경하기 어려운 쪽으로 틀어버린다는 것이다.
Rule 5. 최적화하지 마라
...는 첫번째 교훈이고, 두 번째 교훈은 아래와 같다.
- 측정하기
- 버그 없음을 확인하기 (필자는 이 부분에 대해 스스로의 통찰에 자부심을 느낀다고 한다)
- 데이터 측정하기 (코드를 깊게 이해하기)
- 계획하고 프로토타입 구현하기
- 최적화하고 반복하기
"코드의 성능을 개선해야 할 때 드는 첫 번째 충동은 '코드가 더 빠르게 동작하도록' 만드는 것이다. 이것은 나쁜 충동이며, 최후에나 해볼 법한 최적화다. 같은 작업을 더 빠르게 수행하도록 바꾸는 대신, 불필요한 작업을 제거해 성능을 개선하라"
Rule 5 에 대한 문답
"최적화에 대해 걱정하지 말라, 가 아니라 단순한 코드는 이후에 최적화하기 쉬우니 단순하게 작성하라, 가 더 정확한 표현이다"
Rule 6. 코드 리뷰는 중요하다
코드 리뷰는 조기에 버그를 발견할 수 있게 도와주는데 구체적으론 아래 나열된 순서대로 자주 발견된다:
- 리뷰 전 자기 코드를 검토하다가 자각
- 리뷰 중 리뷰어에게 설명하다가 자각
- 리뷰 중 리뷰어가 던진 질문에 대답하다가 자각
그러나 이것은 부차적인 이유고, 더 큰 목적은 지식 공유에 있다.
단, 주니어 리뷰이 - 주니어 리뷰어 페어는 위험한다. 이들의 대화가 팀 전체의 판단처럼 비춰질 수 있다.
코드 리뷰의 진정한 가치는 건전한 피어 프레셔 - 즉, 누군가 내 코드를 보고 있다는 사실을 자각시키는 것이다.
Rule 7. 실패 케이스를 제거하라
"이 기능/인터페이스를 사용하는 사람들이 제 무덤을 파는 것을 얼마나 어렵게 만들어야 할까? 그 대답은 당연히 아주 어렵게, 이다."
이미 여덟 개의 아규먼트를 지닌 함수를 아홉 번째 아규먼트를 추가하기 쉽다.
Rule 8. Orphan 코드 (unreachable) 는 제거하라
"findAllies 의 사용을 멈췄을 때 findAllies 를 지우지 않은 것이 바로 실수였다. 그 때 이미 그 코드는 작동하지 않게 되었다고 봐야한다"
Rule 11. 두 배 이상 좋을 때만 큰 변경을 하라
Rule 13. root cause 를 고쳐라
"눈사태가 일어나는 도중에 승리를 선언하는 것은 조약돌이 여전히 존재한다는 것을 의미하고, 어느 시점에서든 그 조약돌은 다시 한 번 눈사태를 일으킬 수 있다"
Rule 15. 잡초가 보이면 뽑아라
Rule 16. 최종 결과를 먼저 상상하라
json 을 쓰기로 한 시점부터는 모든 설정 파일이 json 으로 보일 것이다. 진짜 원하는 결과는 무엇이었나? 섵불리 도구를 손에 잡지 말 것
Rule 17. -
(17장의 내용엔 별로 관심이 없다)
"단순하고 지루한 방법은 거의 항상 최고의 방법이다"
Rule 18. 스스로 말하는 코드를 작성하라
주석은 실행되지 않는다는 점에서 Rule 8과 맞닿는 면이 있다.
주석에 대해서, 최근에 읽은 https://buttondown.com/hillelwayne/archive/why-not-comments 가 마음에 든다. Negative Infromation (무엇이 여기에 없는가) 를 코멘트로 적는게 좋다, 는 취지의 글이다.
Rule 20. 계산하라
비용 대 혜택이 50:50 이라면 자동화를 하지 마라.
Rule 21. 때로는 직접 못질을 해야 된다
올바른 문제 해결책을 알고 있는데 작업량 때문에 주저하고 있다면 용기를 내서 작업을 진행하라. 기본값이 있는 아규먼트를 추가하지 말고 5000개의 메소드를 일일이 바꿔라.
"단조로운 일에 착수하는 것은 어렵다. 이를 극복하는 첫 번째 단계는 자신이 하고 싶지 않기 때문에 그 일을 회피하고 있다는 사실을 인지하는 것이다. 두 번째 단계는 한 발 물러나서, 그 일을 처리함으로써 얻게 될 장기적인 혜택을 계산하는 것이다. 장기적으로 보상을 가져오는 일이라면, 단기적으로는 고도니 일이라 하더라도 세 번째 단계인 못질에 착수해야 한다"
소감: 고스트 오브 쓰시마가 해보고 싶어졌다.
