오늘 TIL 3줄 요약

- 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
- DRY: 반복하지 말라 (Don’t Repeat Yourself)
- 최종 결정이란 없다.

TIL (Today I Learned) 날짜

2022. 03. 21

오늘 읽은 범위

2장. 실용주의 접근법

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

- `Tip 14` 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
- 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다.
- **바뀌기 더 쉽게 (Easier to Change).**
- 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 '바꾸기 쉽게'라는 길을 선택한다. 바로 여러분이 작성하는 코드를 교체하기 쉽게 만들도록 노력하는 것이다.
- 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다.
- 프로그래머는 늘 유지 보수 모드에 있다. 우리의 이해는 날마다 바뀐다. 우리가 프로젝트에 열중해 있는 동안에도 새로운 요구 사항이 도착하고 기존 요구 사항은 진화한다. 어쩌면 환경이 변할 수도 있다. 이유가 무엇이건, 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.
- 우리는 DRY가 '실용주의 프로그래머'의 도구 상자에서 가장 중요한 도구 중 하나라고 생각한다.
- 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라. 이런 도구는 일반적으로 문서와 목(Mock) API, 기능 테스트를 생성해 주고, API 클라이언트도 여러 가지 언어로 생성해 준다. 이상적으로 이 도구를 이용하여 모든 API 정의를 중앙 저장소에 넣어 두고 여러 팀이 공유할 수 있게 하면 좋다.
- 개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.
- 우리가 느끼기에 최선책은 개발자 간에 적극적이고 빈번한 소통을 장려하는 것이다.
- 그리고 일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라. 다른 사람의 것을 기웃거리는 게 아니고, 거기서 배우는 것이다.
- (직교성은) 일종의 독립성이나, 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
- 직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다.
	- 생산성 향상
		- 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다. 새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸지 않아도 된다.
	- 리스크 감소
		- **직교적인 시스템은 그 안의 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 아무래도 테스트를 더 많이 하게 된다.**
- '특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?' 직교적인 시스템에서는 답이 '하나'여야 한다.
- '부끄럼쟁이' 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라. 객체의 상태를 바꿀 필요가 있다면 여러분을 위해 객체가 직접 상태를 바꾸게 하라.
- 일반적으로는 필요한 컨텍스트를 모듈에 명시적으로 넘겨주면 코드를 이해하고 유지 보수하기 쉬워진다.
- '리팩터링' - 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하는 과정
- **단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회다.** 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.
- 당연한 말이겠지만 DRY 원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것이다. 디버깅, 테스트, 유지 보수 또한 쉬워질 것이다.
- 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지는 못하기 때문이다. 우리가 소프트웨어를 개발하는 속도는 요구 사항, 사용자, 하드웨어의 변화를 앞지를 수 없다.
- 결정이 바뀌지 않을 것이라고 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.
- `Tip 19` 유행을 쫓지 말라.
- 전에 만들어진 적이 없는 전혀 새로운 것을 만들고 있다면 더욱 그렇다. 움직이는 목표물을 맞히려면 실제 조건하에서 즉각적인 피드백을 받아야 한다. 우리는 이것을 시각적으로 묘사하기 위해 '예광탄 개발'이라는 말을 쓴다.
- 코딩에서 동일한 효과를 얻으려면 우리를 요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가를 찾아야 한다.
- 시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.
- **예광탄 개발 방법은 '프로젝트는 결코 끝나지 않는다.'는 견해와도 일맥상통한다. 변경 요청과 기능 추가 요청은 언제나 계속 들어오기 마련이다. 예광탄 개발 방법은 점진적인 접근 방법이다.**
- **프로토타이핑은 학습 경험이다.** 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다. 이것이 프로토타이핑의 진정한 핵심이다.
- 우리는 언제나 애플리케이션 도메인의 어휘를 사용해서 코드를 작성하려고 노력한다.
- `Tip 22` 문제 도메인에 가깝게 프로그래밍하라.
- 모든 추정치는 문제의 모델에 기반한다. 그런데 모델을 작성하는 기술에 대해 깊이 파고들기 전에 항상 좋은 답을 알려주는 기본적인 추정의 비법을 하나 밝히겠다. 이미 그 일을 해본 사람에게 물어보라.
- 어떤 종류의 추정을 하건 첫 단계는 상대방이 무엇을 묻고 있는지 이해하는 것이다. 조건이 질문에 명시적으로 드러나지 않는 경우도 많지만, 여러분이 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다.
- 그러므로 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복 주기의 끝으로 삼아라. 첫 반복 주기의 경험을 바탕으로 반복 주기의 수와 각 반복 주기에서 무엇을 할지에 대한 처음의 추측을 다듬을 수 있을 것이다.
- 여러분이 계산한 추정치를 기록으로 남겨라. 그리고 각 추청치가 얼마나 정확했는지도 기록으로 남겨라.

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

DRY에 대해서는 많이 들어봤는데 코드 말고도 중복을 피해야 할 곳이 많다는 사실을 알았다.

우리가 내린 결정과 요구 사항, 사용자는 계속 변화하기 때문에 유연한 시스템을 만들어야 한다.

프로토타입과 예광탄 개발을 구분하고, 앞으로는 예광탄 개발을 해봐야겠다.

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

- 도메인 언어와 추정은 한 번 더 읽어보자!

오늘 읽은 다른사람의 TIL

[TIL 2] 실용주의 프로그래머 #2. 실용주의 접근법 (https://hyuuny.tistory.com/56)