오늘 TIL 3줄 요약

• 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

• 바꾸기 쉽게 설계하고 반복하지 말라.(중복을 최소화하라)(Easier To Change, Don't Repeat Yourself)

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

TIL (Today I Learned) 날짜

2022. 05. 15

오늘 읽은 범위

2장. 실용주의 접근법

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

• Easier to Change. 잘 설계되었다는 것은 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 것이다. 이는 지켜야하는 규칙이 아닌 우리가 결정을 내리는데 도와주는 가치이다. 가치를 내면화하기는 어렵지만 의식적으로 노력하여 습관화 해 보도록 하라.

• 프로그래머는 늘 유지 보수 모드에 있다. 우리의 이해는 날마다 바뀐다. 우리가 프로젝트에 열중해 있는 동안에도 새로운 요구 사항이 도착하고 기존 요구 사항은 진화한다. 어쩌면 환경이 변할 수도 있다. 이유가 뭣이건, 유지보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.

• 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다. (Don't Repeat Yourself) 이는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. 이는 코드에 국한 된 것이 아닌 코드 외부에도 적용이 되는 것이다.

• 코드가 가지고 있는 의도와 지식을 파악하라. 쓸데없는 주석으로 의도를 두 번 설명하기보단 함수의 이름에 명시적으로 표현하라.

• 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자accessor 함수를 사용하라. Bertrand Meyer가 설명한 단일 접근 원칙을 준수하도록 노력하라.

• 시스템을 설계하고 빌드하는데 직교성(orthogonality)을 준수하라. 설계가 직교적인지 확인하는 손쉬운 방법이 있다. 컴포넌트들을 나누었을 때 다음과 같이 스스로에게 물어보라. '특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?' 직교적인 시스템에서는 답이 '하나'여야 한다. 또한 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는지도 확인해 보기 바란다. 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.

• 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각해라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

• 시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라. 이후 통합해보라. 이것이 당신의 프로젝트의 가이드라인이 되어줄 예광탄 코드이다. 단, 예광탄 코드가 목표물을 맞추고 있다고 단정짓지 말라. 예광탄 코드는 당신이 짠 코드가 가르치는 방향을 보여줄 뿐이지, 그 방향이 목표를 맞추고 있는지는 당신 스스로가 판단해야 한다.

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

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

• 추정하는 법을 배우고 추정 능력을 계발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘할 수 있게 될 것이다.

• 얼마나 정확해야 충분히 정확한가? 어떤 의미에서 모든 답은 추정치다. 단지 어떤 답이 다른 답보다 좀 더 정확할 뿐이다. 그러므로 누군가 추정치를 물었을 때 스스로 물어보아야 할 첫 번째 질문은 여러분의 답변이 사용될 상황이 무엇인지다. 질문자가 매우 높은 정확도의 답을 요구하는가, 아니면 단순히 큰 그림만을 요구하는가?

• 우리는 여러분이 기간을 추정할 때 다음과 같은 단위를 사용하기를 추천한다.

  • 1~15일 : 일

  • 3~6주 : 주

  • 8~20주 : 달

  • 20주 이상 : 추정치를 말하기 전에 다시 한번 생각해 보라.

• 누군가 추정해 달라고 하면 뭐라고 대답해야 할까? -> "나중에 연락드릴게요."라 말해야 한다.

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

• 1장에서 읽었던 실용주의 철학의 관점을 프로그래밍의 기법으로 자연스럽게 녹아낸 장인 것 같다. 보다 구체적인 예시와 실현 방법에도 불구하고 단 한마디로 정리한다면 오늘의 요약과 같을 것이다. "바꾸기 쉽게 설계하고 반복하지 말라."

• 바꾸기 쉽계 설계한다는 것은 돌발적인 변수에 유연하게 대처할 수 있다는 의미다. 또한 반복하지 않는 다는 것은 코드가 명시적이면서 매일 다른 내가 봐도 이해하기 쉽다는 의미일 수 있다. 물론 이것은 매우 어렵겠지만, 어려운 것을 보다 쉽게 해내기 위해서 우리는 이 책을 읽고 있지 않은가?

• 반면 2장을 읽으면서 줄곧 생각나는 것은 1장의 개구리다. 큰 그림을 바라보고, 한 가지 일에 집중하고 있다고 해서 그 문제에 매몰되어 다른 문제를 방치하거나 버려두는것과 같다는 느낌이 든다. 이 글을 읽고 나는 하나의 코드를 작성할 때도, 이 코드가 전체 시스템 틀 속에서 어떤 역할을 가지고 있는지 끊임없이 생각해야할 필요성을 느긴다. 또한, 끊임없는 비판과 피드백은 전체적인 뼈대를 공고하게 하고, 내가 만들고자 하는 시스템의 기초공사를 좀 더 철처히 할 수 있다라는 생각이 든다.

• 2장에서 얻은 것은 다음과 같다. 큰 그림을 그리고(프로토타입), 뼈대를 만들라(예광탄). 뼈대를 만들었다면 내용은 한번으로 간단하게 채우라(ETC,DRY). 디테일을 추가하겠다고 덧칠하는 것은 결과적으로 전체적인 형상을 무너뜨릴 수 있다. 큰 그림을 그리기 힘들다면 모래성을 지어보라.(프로토타입), 단 모래성은 무너뜨려야 한다는 것을 명심하라.

• 추가적으로, 내가 개인적으로 좋아하는 말인 비트겐슈타인의 "말할 수 없는 것엔 침묵해야 한다."라는 말이 다시금 와 닿는다. 물론 말 할수 없다고 아무것도 안하는 것이 아닌 말 할 수 있도록 노력해야겠다는 생각이 든다.

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

• 도메인 언어에 대해서는 정말 하나도 모르겠다. 누군가 도메인 언어에 대해서 설명할 수 있다면 도와주기를...

오늘 읽은 다른사람의 TIL