[실용주의 프로그래머] 2장. 실용주의 접근법
1 주차
일, 월 | Assignment #03
2장. 실용주의 접근법
📘 책에서 기억하고 싶은 내용
- 좋은 설계의 핵심 (p.38)
- 왜 단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 떄문이다.
- ETC (Easier to Change)
- 스스로 자꾸 물어봐라, '내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?'
- 실마리가 없을 때 언제든지
바꾸기 쉽게 라는 길을 선택하고, 이에 대한 추측을 정리하여 직고나을 발전시키는 기회로 삼아라
- 중복의 해악 (p.41)
- 프로그래머는 늘 유지 보수 모드에 있다. 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.
- DRY (Don't Repeat Yourself)
- 코드를 그대로 설명하는 주석도 원칙에 위배된다.
(특정 상수를 고치면 주석과 코드 모두 고쳐야 하기 때문)
- 개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.
- 일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라, 거기서 배우는 것이다.
- 직교성 (p.54)
직교성 은 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는 데에 있어 매우 중요한 개념으로 일종의 독립성이나, 결합도 줄이기를 의미한다.- 하나가 바뀌어도 나머지에 대한 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
- 비직교적인 시스템은 본질적으로 변경과 조정이 더 복잡하다.
- 직교적인 시스템을 작성하면
생산성 향상 과 리스크 감소 라는 장점이 있다.
- 생산성 향상 : 변화를 국소화하여 개발 시간과 테스트 시간 감소 및 컴포넌트 재사용 촉진
- 리스크 감소 : 특정 코드에 문제가 있더라도 해당 코드는 격리되어 있고, 제품 혹은 플랫폼에 덜 종속적
- 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.
- 전화번호, 주민등록번호와 같은 외부 식별자는 내가 제어할 수 없고 언제 어떤 이유로든 바뀔 수 있다.
- 객체의 상태를 바꿀 필요가 있다면 객체가 직접 상태를 바꾸게 한다.
- 코드가 전역 데이터를 참조할 때마다 코드는 해당 데이터를 공유한는 다른 컴포넌트와 묶이게 되므로 전역 데이터를 피해야 한다.
- 싱글톤은 불필요한 결합을 만들 수 있다.
- 중복 코드는 구조에 문제가 있다는 징후로, 전략 패턴 사용을 고려해보아야 한다.
- 자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라.
- 문제가 발생했다면 버그 수정을 얼마나 국소화할 수 있는지 평가해보라.
- 가역성 (p.66)
- "당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다." - 에밀 오귀스트 샤르티에
- 특정 서드파티를 사용하기로 결정했다면 큰 비용을 치르지 않고는 되돌릴 수 없는 행동을 하기로 묶여버린 셈이다.
- 결합도를 줄여야 하는 결정적인 이유 : 프로젝트 초기에 늘 최선의 결정을 내리지 못하여 자주 변경이 발생하기 때문
- 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각해야 한다. 언제든지 큰 파도가 글씨를 지워버릴 수 있기 때문.
- 예광탄 (p.71)
- 예광탄 개발 : 목표물을 조준하기 위해 실제 조건 하에서 즉각적인 피드백을 받을 수 있도록 시스템 개발, 점진적인 접근 방법
- 거대 공학적 접근 방식(모듈을 조립하여 하위 부품을 만들고, 결국 전체 시스템을 완성시키는 방식)과 대비된다.
- 일이 어떻게 될지 100% 확신할 수 없는 상황에서 사용된다.
- 의문점이나 리스크가 큰 부분에 대하여 코드를 먼저 작성하도록 개발 우선순위를 조정한다.
- 예광탄 코드는 한 번 쓰고 버리려고 만드는 것이 아니며, 앞으로도 살을 붙여가며 사용할 코드다.
- 장점
- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
- 개발자가 들어가서 일할 수 있는 구조를 얻는다. (코드를 구체화한 이후에는 더 이상 무에서 유를 창조하지 않아도 된다.)
- 통합 작업을 수행할 기반이 생긴다. (한꺼번에 모든 것을 통합하지 않고 매일 통합을 할 수 있게 된다.)
- 보여줄 것이 생긴다.
- 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.
- 실험 과정 이후 구현한 것을 모두 버리게 되는 프로토타입 방식과는 차이가 있다.
- 예광탄 개발 방식의 주요 관심은 '애플리케이션이 전체적으로 어떻게 연결되는가?'이다.
- 프로토타입과 포스트잇 (p.79)
- 프로토타입을 반드시 코드로 작성할 필요는 없다.
- 세부 사항을 포기할 수 없는 환경이라면 프로토타입보다는 예광탄 방식의 개발이 더 적절하다.
- 프로토타이핑의 가치는 생산한 코드가 아닌 이를 통해 배우는 교훈에 있다.
- 프로토타입 개발 시
정확성, 완전성, 안정성, 스타일 은 꼭 지킬 필요는 없다.
- 도메인 언어 (p.85)
- 언어별 특징들은 모두 어떤 해결 방안을 제시하기도 하지만 가려 버리기도 하며, 도메인의 언어가 해결 방안을 제안하기도 한다.
- 전통적인 개발 방식이 제대로 동작하지 않는 이유 중 하나는 우리가 요구 사항을 알고 있다는 전제에 기반하기 때문, 직관적으로 그들의 의도를 이해해서 코드로 바꿔내는 것도 우리의 존재 가치 중 하나이다.
- 내부 도메인 언어
→ 도메인 언어가 원래 코드의 어휘를 확장시킴
- RSpec : 루비용 테스트 라이브러리
- 피닉스 라우터 : HTTP 요청을 코드의 핸들로 함수로 전달하는 라우팅 도구
- 외부 도메인 언어
→ 별도의 코드가 이 언어를 읽어 들여서 사용할 수 있는 형태로 변경
- 큐컴버 : 언어에 종속되지 않은 테스트 정의
- 앤서블 : 소프트웨어 설정 도구, YAML로 작성
- 도메인 언어를 만들려면 추가 비용이 발생하는데, 이를 상쇄할 만큼 비용 절감을 할 수 있다는 확신이 있어야 한다.
- 외부 언어 도입은 애플리케이션의 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천
- 추정 (p.94)
- 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다.
- 프로젝트 일정 추정
- PERT (프로그램 평가 검토 기법, 낙관적 추정치와 가장 가능성이 높은 추정치, 비관적 추정치에 따라 전체 프로젝트의 예상 최소 및 최대 소요시간 계산)
- 점증적 개발 주기를 기준으로 전체 일정 추정
🤔 소감 및 생각
- 실무진의 입장에서 읽으면서 공감되는 부분들이 많았다. 프로젝트 시작 전 경영진은 정확한 숫자를 원한다는 점 등등 굉장히 공감가는 내용이 많아서 읽는데에 그리 지루하지 않았던 것 같다.
- 그리고, 우리 파트의 내가 맡지 않은 업무도 코드 리뷰 시 기획서나 문서를 많이 참고하려고 노력했는데 막상 나의 업무를 처리할 시간이 부족해지는 것 같아 '내가 오지랖 부려서 일을 키우는걸까?' 라는 생각이 들 때가 있었다. 하지만 이번 챕터를 읽음으로써 내가 옳은 방식으로 하고 있었다는 것을 깨달았고, 앞으로도 팀원들에게 작은 인사이트라도 줄 수 있도록 노력해야겠다.
🔍 새롭게 또는 다시 알게 된 내용
- 하스켈 : 1985년에 개발된 순수 함수형 프로그래밍 언어로, 논리학자
해스켈 커리 에서 따온 명칭이다.
- 메타 프로그래밍 : 프로그램을 하나의 데이터로 보고 동적으로 수정하는 프로그래밍 기법, 넓은 의미에서 런타임에 수행해야 할 작업의 일부를 컴파일 타임 동안 수행하도록 하는 프로그램
- BNF 문법 : 배커스-나우르 표기법
- PEG(Parsing Expression Grammars) : 분석 형식 문법의 한 종류
- 엘릭서(Elixir) : 얼랭(Erlang) 가상 머신(BEAM) 위에서 동작하는 함수형, 동시성 프로그래밍 언어이다.
- 클로저(Clojure) : 리치 히키(Rich Hickey)가 만든 리스프 프로그래밍 언어의 방언으로서, 범용 함수형 언어이다.
- 크리스탈(Crystal) :
Ruby 와 비슷한 구문을 가지는 것 등과 같은 목표를 가진 언어이다.
