TIL (Today I Learned)

2022.02.19

오늘 읽은 범위

추천사 ~ 1장. 깨끗한 코드

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

• 사소한 곳에서 발휘하는 정직은 사소하지 않다. (추천사)

• 궁극적으로 코드는 요구사항을 표현하는 언어다. (p.3)

• 질병과 감염의 위험은 환자보다 의사가 더 잘아니까. 환자 말을 그대로 따르는 행동은 전문가답지 못하니까. 프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다. (p.7)

• ... 이런 상항이 발생하면 나는 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다... 이제 실제 기능은 아주 간단한 방식으로 구현해도 괜찮다. 다른 코드는 추상 클래스나 추상 메서드가 제공하는 기능을 사용하므로 실제 구현은 언제든지 바꿔도 괜찮다. 지금은 간단하게 재빨리 구현했다가 나중에 필요할 때 바꾸면 된다. (p.14)

• 중복을 피하라, 한 기능만 수행하라, 제대로 표현하라, 작게 추상화하라. (p.14)

• 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. (p.18)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 코드를 작성하는 순간 뿐만 아니라, 소프트웨어를 매 순간 깨끗하게 유지하기 위해서 라는 목표를 보며, 소프트웨어 장인 정신을 느꼈다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 르블랑의 법칙 - ["Later equals never"](

  http://on-agile.blogspot.com/2007/04/why-you-wont-fix-it-later.html)

• 1. When you cut corners in order to deliver on time, you're giving management and your customer a false sense of how fast you can reliably deliver.
  

  고객가치를 창출하기 위한 속도 측정이 부정확해지고, 다음 이터레이션에서도 반복되며 기술부채를 쌓을 것이기 때문에, 나중에 고칠 수 있는 순간은 오지 않는다.

• 2. When you skimp on automated tests, and even when you write tests but don't ensure they are readable, atomic, and easily-maintained unit tests, you limit your ability to effectively refactor.
  

  바쁘다는 이유로 테스트 코드가 없는 코드로 마무리하게 되면, 리팩토링이 어려워지고, 버그를 그때마다 다른 방식으로 고치게 된다. 결국 디버깅과 버그를 고치는 데에 더 많은 시간을 쓰게 되고, 테스트를 작성하고 리팩토링할 시간은 없어진다.