지-코바/실용주의 프로그래머
실용주의 프로그래머 2장 - 실용주의 접근법
moonseok
2024. 10. 24. 22:42
DRY원칙 (Don't Repeat Yourself : 반복하지 마라)
코드중복
- 모든 지식은 시스템 내에서 한 번만, 애매하지 않고 권위있게 표현해라.
- 코드의 하나를 바꿀때 코드, 문서, DB 스키마, 스키마담는 구조 등도 바꾸는가? 그건 DRY하지 않다.
문서화 중복
- 주석으로 코드를 두번 설명하지 마라.
- 함수명에서 하는 일을 알려줘라.
내부 API 중복
- 정의할 수 있는 도구 찾기 : MOCK API, 기능테스트 생성, 클라이언트도 다양한 언어도 생성해준다. 이 도구로 API 정의를 중앙저장소에 넣고 여러 팀이 공유하면 된다.
직교성
- 직교성 은 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는 데에 있어 매우 중요한 개념으로 일종의 독립성이나, 결합도 줄이기를 의미한다.
- 하나가 바뀌어도 나머지에 대한 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
- 비직교적인 시스템은 본질적으로 변경과 조정이 더 복잡하다.
- 직교적인 시스템을 작성하면 생산성 향상 과 리스크 감소 라는 장점이 있다.
- 생산성 향상 : 변화를 국소화하여 개발 시간과 테스트 시간 감소 및 컴포넌트 재사용 촉진
- 리스크 감소 : 특정 코드에 문제가 있더라도 해당 코드는 격리되어 있고, 제품 혹은 플랫폼에 덜 종속적
- 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.
- 전화번호, 주민등록번호와 같은 외부 식별자는 내가 제어할 수 없고 언제 어떤 이유로든 바뀔 수 있다.
- 객체의 상태를 바꿀 필요가 있다면 객체가 직접 상태를 바꾸게 한다.
- 코드가 전역 데이터를 참조할 때마다 코드는 해당 데이터를 공유한는 다른 컴포넌트와 묶이게 되므로 전역 데이터를 피해야 한다.
- 싱글톤은 불필요한 결합을 만들 수 있다.
- 중복 코드는 구조에 문제가 있다는 징후로, 전략 패턴 사용을 고려해보아야 한다.
- 자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라.
- 문제가 발생했다면 버그 수정을 얼마나 국소화할 수 있는지 평가해보라.
예광탄
- 예광탄 개발 : 목표물을 조준하기 위해 실제 조건 하에서 즉각적인 피드백을 받을 수 있도록 시스템 개발, 점진적인 접근 방법
- 거대 공학적 접근 방식(모듈을 조립하여 하위 부품을 만들고, 결국 전체 시스템을 완성시키는 방식)과 대비된다.
- 일이 어떻게 될지 100% 확신할 수 없는 상황에서 사용된다.
- 의문점이나 리스크가 큰 부분에 대하여 코드를 먼저 작성하도록 개발 우선순위를 조정한다.
- 예광탄 코드는 한 번 쓰고 버리려고 만드는 것이 아니며, 앞으로도 살을 붙여가며 사용할 코드다.
- 장점
- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
- 개발자가 들어가서 일할 수 있는 구조를 얻는다. (코드를 구체화한 이후에는 더 이상 무에서 유를 창조하지 않아도 된다.)
- 통합 작업을 수행할 기반이 생긴다. (한꺼번에 모든 것을 통합하지 않고 매일 통합을 할 수 있게 된다.)
- 보여줄 것이 생긴다.
- 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.
- 실험 과정 이후 구현한 것을 모두 버리게 되는 프로토타입 방식과는 차이가 있다.
- 예광탄 개발 방식의 주요 관심은 '애플리케이션이 전체적으로 어떻게 연결되는가?'이다.
프로토타입과 포스트잇
- 프로토타입을 반드시 코드로 작성할 필요는 없다.
- 세부 사항을 포기할 수 없는 환경이라면 프로토타입보다는 예광탄 방식의 개발이 더 적절하다.
- 프로토타이핑의 가치는 생산한 코드가 아닌 이를 통해 배우는 교훈에 있다.
- 프로토타입 개발 시 정확성, 완전성, 안정성, 스타일 은 꼭 지킬 필요는 없다.
추정
- 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다.
- 프로젝트 일정 추정
- PERT (프로그램 평가 검토 기법, 낙관적 추정치와 가장 가능성이 높은 추정치, 비관적 추정치에 따라 전체 프로젝트의 예상 최소 및 최대 소요시간 계산)
- 점증적 개발 주기를 기준으로 전체 일정 추정