읽기에 앞서…

실용주의 프로그래머를 읽고 느낀점을 써보려고 합니다. 제가 느낀바로는 이러한 내용이다 하는 방향으로 기술할 것 같습니다.

제 2장. 실용주의 접근법

이 장에서는 소프트웨어 개발에 있어 반드시 적용되는 아이디어나 보편화된 프로세스에 대해 소개한다.

중복의 해악과 직교성(Orthogonality):

• 전자? 시스템을 통틀어 어떤 지식을 중복하지 마라.
• 후자? 하나의 지식을 여러 개의 컴포넌트에 걸쳐 쪼개어놓지 마라.

가역성(Reversibility):

• 변화하는 환경에서 프로젝트를 분리하는 방법

예광탄(Tracer bullets):

• 요구사항을 모음, 설계를 테스트, 코드를 구현함… 이런류의 개발 스타일을 소개함.

프로토타입과 포스트잇:

• 아키텍처, 알고리즘, 인터페이스, 아이디어를 구현하기 위해 프로토타입을 어떻게 쓰는가에 대한 이야기를 함.

도메인 언어(Domain Language):

• ???

추정(Estimating):

• 이정도 개발이면 이정도 쯤 걸리겠는데? 하고 감잡는 방법을 소개

7. 중복의 해악

지식은 변화한다. 요구사항이 바뀔 수도 있고 알고리즘이 안돌아가서 변경될 수 있고 그에 맞게 기능도 바뀐다. 한마디로 하자면 유지보수는 개발과 이어지는 부분이다 라고할 수 있다. 유지보수를 하려면 사물의 표현방식을 바꿔야함. 객체화한 것들, 캡슐화한 부분들 등… 그렇지만 개발할 때 명세와 프로세스에 지식을 중복해서 넣기 쉽다는 점이다. 이것을 방지하기 위한 원칙은 DRY 원칙이다. 정의는 다음과 같다.

모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 믿을만한 표현양식을 가져야 한다.

Tip 11. DRY - Don’t Repeat Yourself

DRY를 따르지 않는다: 똑같은 것이 여러곳에 반복된다는 것이다. -> 지옥의 유지보수

중복이 어떻게 생기는가?

• 강요된(impose) 중복: 환경이 중복을 요구한다
• 부주의한 중복: 개발자들이 중복하고 있다는 것을 인지하지 못함
• 참을성 없는 중복: 중복이 쉬워보이기 때문에 개발자들이 게을러져서
• 개발자 간의 중복: 한팀에 있는(다른팀에 있는) 여러 사람이 동일한 정보를 중복

강요된 중복: 필요한 지식을 한곳에 두도록 하는 기법들

• 정보의 다양한 표현방식: 코딩할 때 동일한 정보가 다른 형태로 표현될 때가 있다.
  • 공통된 구조를 다른 요소에서 서로 표현해야할 때
• 코드 생성기를 통해 두 요소의 표현을 자동화한다.
  • 코드 내의 문서화