2장. 실용주의 접근법

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

• 스스로 자꾸 물어보라. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.
• 아무 실마리가 없을 경우 다음 두 가지를 해보라.
• 첫 번째로, 언제건 궁극의 ‘바꾸기 쉽게’라는 길을 선택한다.
• 두 번째는 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라는 것이다. 엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스 코드에 이에 대한 표시를 남겨 둬라. 나중에 이 코드를 바꿔야 하는 시점이 왔을 때, 뒤를 돌아보고 자신에게 피드백을 줄 수 있을 것이다. 그러면 비슷한 갈림길에 다시 섰을 때 도움이 될 것이다.
• 소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가 DRY라 부르는 원칙을 따르는 것이라 생각한다. DRY 원칙은 다음과 같다.
  모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
• 설계가 직교적인지 확인하려면 다음과 같이 스스로에게 물어보라.
  ‘특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?’ 직교적인 시스템에서는 답이 ‘하나’여야 한다.
  또한 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는지도 확인해보기 바란다. 전화번호를 고객 식별자로 사용하고 있는가? 지역 번호 체계가 바뀐다면 어떻게 할 것인가? 주민 등록 번호 같이 정부에서 부여하는 식별자, 우편 번호, 이메일 주소, 도메인 이름 등은 모두 외부의 식별자다. 즉, 여러분이 제어할 수 없고, 언제 어떤 이유로든 바뀔 수 있다. 자신의 힘을 제어할 수 없는 속성에 의존하지 말라.
• 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.
• 프로토타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만, 완결된 코드이며, 최종 시스템 골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것이다.

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

• 나는 개발을 하면서 ‘이렇게 짜도 될까?’ 생각을 많이 하는데, ‘바꾸기 쉽게 만든걸까, 어렵게 만든걸까?’ 생각해보는 게 훨씬 도움이 될 것 같다.
• 정리해보자면, 바꾸기 쉽게 중복을 줄이라는 것인데 중복된 코드를 줄이기 위해서는 이 책에서 팀원간의 신뢰가 중요하다고 했다. 덧붙여 팀원 간의 소통도 중요한 것 같다. 서로가 어떤 부분을 개발하는지 잘 알아야 중복되더라도 줄일 수 있으니까. 이런 점에서는 나도 노력해야겠다.

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