실용주의 프로그래머 3일차. 2장 실용주의 접근법

오늘 TIL 3줄 요약

• 새로운 아이디어는 먼저 아이디어를 검증하고 피드백 받아보는 것이 중요하다.
• ETC(Easier to Change) : 바꾸기 쉽게.
• DRY(Don't Repeat Yourself) : 반복하지 말라.

TIL (Today I Learned)

2022.03.22

 

오늘 읽은 범위

2장 실용주의 접근법

 

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

• 좋은 설계의 핵심은 코드는 바꾸기 쉬워한다는 것이다.

: 결합도를 줄이면 관심사를 분리함으로써 각각이 더 바꾸기 쉬워진다. 단일 책임의 원칙이 중요한 이유는 요구사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다. 이름 짓기가 중요한 이유는 이름이 좋으면 코드 읽기가 쉬워지고 코드를 바꾸려면 코드를 읽어야 하기 때문이다.

 

 

• 프로그래머는 늘 유지보수에 신경써야 한다. 

: 지식은 고정적이지 않다. 지식은 변화한다. 요구사항이 의뢰인과의 미팅으로 바뀔 수 있고 정부의 규제로 비즈니스 로직이 쓸 수 없게된다. 또채택됐던 알고리즘이 테스트해보니 틀렸을 수 있다.  

유지보수는 애플리케이션이 출시 때부터가 아니고 전체 개발 과정의 일상적인 부분이다. 

=> 유지보수하기 쉽게 만드는 길 : DRY(Don't Repeat Yourself) 원칙

 

 

• 언제나 객체의 속성을 일고 쓸 때 접근자 함수를 이용하라. 

: 자바 Object 만들때, getter함수와 setter함수를 만들어 객체 속성에 접근한다. => 나중에 기능 추가하기 쉬어진다. 

 

 

• 직교성(독립성, 결합도 줄이기) 

: 전역 데이터를 피하라. => 불필요한 결합을 만들 수 있기 때문이다. 

: 유사한 함수를 피하라. => 리팩토링 

: 테스트 => 테스트를 마친 뒤 코드를 병합할 때 버그 수정에 대한 태그를 붙여라. 버그 수정마다 수정한 소스 파일 개수를 수집하여 그 경향을 분석한 월 단위 리포트를 만들 수 있다. 

 

 

• 프로토타입 VS 예광탄 코드

: 프로토타입 => 나중에 버리는 코드이다. 예광탄 코드를 만들기 전 수행하는 것 (정찰, 정보수집), 전체시스템의 감 잡는 것, 세부사항은 무시한다. 적절히 사용하면 시간과 돈, 고통을 줄일 수 있다. 

: 예광탄 코드 => 최종 시스템 골격 중 일부가 된다. 세부사항을 포기할 수 없는 개발 상황에 적절.

 

 

 

• 도메인 언어가 프로그래밍 해결 방안을 제안하기도 한다. 

 

 

• 반복주기가 몇 번이나 필요한지 초기 기획 단계에서 정하라고 요구하면 그것은 잘못된 방식이다. 누군가 추정해 달라고 하면 "나중에 연락드릴게요"라고 말해야 한다. => 각 반복주기가 끝날때마다 추측을 다듬다보면 일정에 대한 확신이 커진다. 

 

 

• 추정치 

: 모델 만들기 > 모델을 컴포넌트로 분해 > 각 매개 변수에 값을 할당 > 답을 계산 

 

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

코드를 수정하기 쉽고 재사용 가능하게 하기 위해 무엇보다 쉽게 만들어야 하는 이유를 알았다. 코드 리팩토링이 중요하다고 강조하고 있다. 어떤 개발자는 코드를 너무 간결하게 만들면 그 개발자의 코드 구현을 보고 그 개발자의 코드 레거시를 알 수 없다고도 하는데, 이 부분은 개발자로 현업에서 경험을 해봐야 알 수 있을 것 같다. 

 

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

추정치 계산은 알고리즘 속도와도 관련이 있어 공부가 더 필요하다.