<aside> 🔑 오늘 TIL 3줄 요약

</aside>

• 시스템의 안정을 위해서 반복하지말고 직교성( 독립성 )을 유지하라.
• 신중하게 그리고 밑그림 그리듯 ( 예광탄, 프로토타입 )이 프로그램을 짜고 예상 기간을 추정한다.
• 프로그래머는 정말 많은 걸 생각해야한다. 그 생각이 결국 질 높은 프로그램을 만드는 척도가 될 것이다.

TIL (Today I Learned) 날짜

2022. 3. 20 ~ 2022. 03. 21

오늘 읽은 범위

~2장. 실용주의 접근법

<aside> 📝 책에서 기억하고 싶은 내용

</aside>

1. 시스템을 통틀어 어떤 지식을 중복으로 갖지 말라고 경고(DRY : 중복의 해악) 하고, 하나의 지식을 시스템의 여러 컴포넌트에 걸쳐 쪼개 놓지 말라( 직교성 )고 조언한다.
2. 왜 결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다. 왜 단일 책임 원칙( SRP )이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다. 왜 이름 짓기가 중요한가? 이름이 좋은 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.
3. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ 파일을 저장할 때 마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.
4. 프로그래머로서 우리는 지식을 수집하고, 조직하고, 유지하며, 통제한다.
5. 유지 보수를 하려면 사물의 표현 양식, 즉 애플리케이션에 표현되어 있는 지식을 찾아내고 또 바꿔야 한다. 문제는 명세와 프로세스, 개발하는 프로그램 안에 지식을 중복 해서 넣기 쉽다는 것이다.
6. 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
7. 모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자(accessor) 함수를 사용하라. 그러면 나중에 기능을 추가하기 더 쉬워질 것이다. ( p50 )
8. 여러분은 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다. ( p51 )