4장
대규모 프로젝트의 17%가 프로젝트를 수행한 회사의 존립을 위협할 정도로 나쁘게 진행되었다. 이런 나쁜 아이디어를 어떻게 식별할 수 있을까? 작은 단계로 작업하고, 진행 상황에 대한 실제 반응을 얻고, 지속적으로 아이디어를 검증하고 검토하면, 무언가가 우리의 희망이나 계획과는 다르게 동작하기 시작할 때 최소한의 투자로 가장 빨리 문제를 파악할 수 있다.
애자일은 회의적인 사고를 통해 발전하는 것!
5장
지속적인 피드백을 통해 코드를 발전시키는 걸 보면서 나는 코드를 꼼꼼하게 치는가에 대한 반성을 하게 됨
7장
실험에 대해 끊임없이 의심하고 현실의 경험과 비교하자
8장
TDD로 개발하자, 실패하는 테스트코드도 유효하다
생각해볼 포인트?
- 나는 지금 내 프로젝트나 팀에서 두 접근 중 어느 쪽에 더 기대고 있나? 왜 그런가?
- 회고(retrospective)는 경험주의 도구, A/B 테스트는 실험주의 도구
9장
REST API를 사용하지 않거나, 모듈 경계를 명확히 하지 않으면 발생할 수 있는 문제는?
REST API 없이 모듈 경계가 모호하면 서비스 간 결합도가 높아지고, 입력 검증이나 데이터 추상화가 제대로 이뤄지지 않아 유지보수가 어려워진다. 결과적으로 시스템이 변경에 취약하고 복잡해진다.
- 의존성 주입 잘 하고 있는 사례, 플레이어 맞을까?
10장
코드 기반을 변경하기 위해 여러 곳을 돌아다니며 변경해야 한다면 응집성 있는 시스템이라고 할 수 없다. -> props랑 반대되는 개념인가?‘품목 추가’ 이벤트에 관심이 있다고 등록하면 품목 추가 알림을 받을 수도 있고, 코드의 해당 부분이 이 ‘품목 추가’ 이벤트에 관심이 있다고 등록하지 않으면 추가 알림이 발생하지 않을 수도 있다. → useEffect 같은거라 생각하면 될까?13쟝
- “느슨한 결합(loose coupling)이 긴밀한 결합(tight coupling)보다 좋다”
→ 모듈 간의 의존성을 줄이라는 의미야.
즉, 어떤 클래스나 모듈이 다른 것에 너무 많이 의존하면 변경에 약해지고, 재사용도 어려워짐.
- “좋은 설계는 응집도는 높고 결합도는 낮아야 한다”
- 응집도(cohesion): 하나의 모듈 안에 있는 구성 요소들이 얼마나 밀접하게 연관되어 있느냐 (즉, 하나의 책임에 집중하는 정도).
- 결합도(coupling): 서로 다른 모듈이 얼마나 강하게 연결되어 있느냐 (즉, 외부에 얼마나 의존하느냐).
→ 높은 응집도 + 낮은 결합도는 좋은 설계의 기본 원칙.
🔁 공통된 핵심은?
각 모듈은 자기 일에 집중하고, 다른 모듈에는 가능한 적게 의존하자.
14장
이를 바탕으로 테스트코드 작성해라!
15장
결과 vs 과정 뭐가 더 중요할까?를 말하는 부분