2장. 실용주의 접근법

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :)

중복의 해악

- 인공지능을 무력화 하는 방법은 두 개의 모순적인 지식을 제공하는 것이다. == 동일한 원리가 우리의 코드를 무너뜨리는데 효과적이다.

- 우리는 지식을 수집하고 조직하고 유지하며 통제한다. 또한 명세서에 지식을 문서화하고 실행 코드에서 지식이 생명력을 갖게한다. 불행히도 지식은 고정적이지 않다. 이 때문에 유지보수는 애플리케이션이 출시 되었을 때 시작되는 것이 아니라 프로그래머들은 늘 유지보수 모드에 있다.

- DRY(Don't Repeat Yourself)를 따르지 않는다면 유지보수의 악몽에 시달릴 것이다.

- DRY를 따르지 않는다면, 남은 방법은 똑같은 것이 두 군데 이상에 표현하는 것이고 이것은 단지 언제 잊어버릴 것인가 하는 문제이다.

어떻게 중복이 생기는가?

- 강요된 중복

 : 환경이 중복을 요구한다.

 : 창의력을 가지고 정보의 다양한 표현양식을 이용하여 극복하라.

- 부주의한 중복

 : 개발자 자신이 정보를 중복하고 있다는 것을 깨닫지 못한다.

 : 설계 실수로 결과가 나타날 수도 있다.

 : 복수의 상호의존적 데이터 요소들이 있을 경우, 수정시 자동으로 의존적인 요소들이 변하도록 설계하라 (p71 Line class 예제 참조)

- 참을성 없는 중복

 : 게으르고, 중복이 쉬워보이기에 중복을 한다.

 : 발견하기 쉽고, 다루기도 쉬운 형태지만, 시간을 투자할 의지를 키우는 훈련이 필요하다.

- 개발자간의 중복

 : 여러 사람이 정보를 중복한다.

 : 빈번한 소통을 장려해라.

 : 공통의 문제를 다루기 위한 토론장을 만들어라.

 : 서로간의 코드 리뷰를 자주 가져라

재사용하기 쉽게 만들어라

- 개발자가 조성해야 할 환경이란, 뭔가 직접 만드는 것보다 기존의 것을 찾아내고 또 재사용하기 쉬운 환경이다.

- 그게 쉽지 않다면 사람들은 하지 않을 것이다.

- 재사용에 실패한다면 지식 중복의 위험을 각오해야한다.

나쁜 주석이란

- 나쁜 코드는 많은 주석을 필요로 한다.

- DRY 원칙을 지키지 않을 경우, 변경시마다 매번 코드와 주석 모두를 바꾸어야한다.

- 위와같이 되면 주석은 필연적으로 낡게 되고, 믿을 수 없는 주석은 없는 것보다 심각한 문제를 만들어낸다.

직교성(Orthogonality)

- 직교성은 기하학에서 빌려온 용어다. 서로 90도를 이루는 x축과 y축은 서로 독립적이다.

- 컴퓨팅에서 이 용어는 일종의 독립성(independence)나 결합도를 줄이기(decoupling)을 의미한다.

- 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.

- 직교성을 이루는 방법은, 관련 없는 것들 간에 서로 영향이 없도록 하는 것이다.

직교성의 장점

- 시스템의 컴포넌트들이 상호 의존적일 경우 특정 국지적 부분만 수정하는 방법이란 없다.

- 생산성 향상

 : 변화가 국소화(localize)되어 개발 및 테스트 시간이 줄어든다.

 : 빨리 잊어버려도 된다.

 : 새로운 코드를 추가할 때마다 기존의 코드를 바꿀 필요가 없다.

 : 재사용을 촉진한다.

- 리스크 감소

 : 감염된 코드가 격리화된다.

 : 수정을 하여도 시스템이 잘 깨어지지 않는다.

 : 설계하고 실행하고 테스트하기 쉽다.

프로젝트 팀에 직교성 적용방법

- 팀 내에 업무가 겹치는 영역이 많다면 구성원들은 책임 영역에 대해 혼동하게 된다. 무엇 하나를 바꾸더라도 전체 팀원이 모여야 한다.

- 프로젝트 팀에 직교성을 적용하는 명확한 해답은 없다. 대신 잠재적인 변화 영역과 프로젝트에 대한 여러분의 분석에 달려 있다.

- 저자는 애플리케이션에서 인프라를 분리하는 방식을 선호한다. 주된 인프라 컴포넌트(데이터베이스, 미들웨어, 커뮤니케이션 인터페이스 등) 마다 서브팀을 할당한다.

- 프로젝트 팀 구조의 직교성 측정방법 : 요청된 개별 변화에 대한 토론에 참여할 필요가 있는 사람이 몇 명인지 세어보라. 숫자가 클 수록 그룹의 직교성은 낮다.

설계의 영역에 직교성 적용방법

- 모듈라(modular), 컴포넌트 기반, 레이어 등과 같은 용어로 이미 개발자들은 직교적인 시스템을 설계할 필요를 잘 안다.

- 레이어식 접근 직교적 시스템을 설계하는 강력한 방법이다.

 : 각 레이어는 하나의 추상화 층을 이룬다.

 : 레이어는 협력하는 독립적인 모듈들의 집합으로 구성되어있다.

직교적인 설계를 테스트하는 방법

- "특정 기능에 대한 요구사항을 극적으로 변경했을 경우, 몇 개의 모듈이 영향을 받는가?"를 물어보아라. 직교적인 시스템에서는 답이 '하나' 여야 한다.

툴킷과 라이브러리 선택시 직교성 고려

- 써드파티 툴킷이나 라이브러리 도입 시 시스템의 직교성을 보존할 수 있는지 고려 필요

코드 영역 직교성 유지방법

- 코드의 결합도를 줄여라

 : 부끄럼타는 코드(shy code) 즉, 불필요한 어떤 것도 다른 모듈에 보여주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.

 : 객체의 상태를 바꿀 필요가 있다면, 객체 스스로가 여러분을 위해 그러한 일을 수행하게 만들라.

- 전역(global) 데이터를 피하라

 : 코드가 전역 데이터를 참조할 때마다, 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다.

 : 읽기 전용 목적으로 전역 데이터를 사용한다 하더라도 문제가 발생할 수 있다.

 : 그래서 객체지향 애플리케이션에서는 컨텍스트를 객체 생성자의 매개 변수로 넘기기도 한다.

 : 싱글톤 패턴은 불필요한 링크를 유도하므로 주의를 기울여라.

- 유사한 함수를 피하라.

 : 시작과 끝에서는 공통 코드를 공유하지만 중간에 알고리즘이 다른 유사해 보이는 함수의 집합을 구현할 때가 있다.

 : 중복 코드는 구조적 문제이므로, 스트래티지 패턴(strategy pattern)을 사용하여 더 나은 구현을 해라.

 : 바뀌는 부분은 따로 뽑아서 캡슐화해라.

- 코드를 비판적으로 검토하고, 리팩터링을 해라.

테스트와 직교성

- 단위 테스트를 만든다는 것 자체가 직교성을 테스트해 볼 수 있는 흥미로운 작업이다.

- 버그 수정은 시스템의 직교성을 총체적으로 점검해 볼 수 있는 값진 시간이다.

 : 버그를 수정하고 테스트를 마친 뒤 소스코드에서 버그 수정에 대한 태그를 붙여라.

 : 그러면 각 버그 수정에 의해 영향 받은 소스 파일의 개수에 대해 경향을 분석한 월 단위 리포트를 받아볼 수 있다.

문서화와 직교성

- 직교적인 문서라면 내용 변화 없이 표현을 극적으로 바꿀 수 있다.

직교적으로 살아가라

- DRY 원리는 시스템 내부의 중복을 최소화시킨다.

- 직교성은 시스템 컴포넌트 간의 상호 의존도를 줄인다.

- DRY와 직교성의 원리를 충실히 사용한다면 시스템은 더 유연하고, 이해하기 쉽고, 디버그, 테스트, 유지도 쉬워질 것이다.

가역성 : 최종 결정이란 없다.

- 결정이란 돌에 새겨지는 것이 아니라 해변가의 모래 위에 쓰인 글씨이다.

- 가역성을 위한 방법

 : DRY(Don't Repeat Yourself) 원리

 : 결합도 줄이기(뒤쪽에서 설명 예정 p227)

 : 메타데이터 사용하기(뒤쪽에서 설명 예정 p235)

유연한 아키텍처

- CORBA(Common Object Requests Broker Architecture)와 같은 기술은 개발 언어와 플랫폼의 변경으로 부터 우릴 지켜준다.

- CORBA를 이용하면 다른 컴포넌트는 영향을 받지 않기 떄문에 변경이 필요한 컴포넌트에만 집중할 수 있다.

- 특정 벤더 제품에 대한 의존도 등은 추상화한 인터페이스를 통해 감춰라

- 요구사항을 메타데이터에 넣어라

- 필요 수행문을 코드에 넣을 때 Perl 등을 이용하여 메커니즘을 자동화하라.

목표물을 찾기 위해 예광탄을 써라

- 예광탄이 효과가 있는 까닭은, 일반 탄환과 동일 환경과 제약 조건에서 날아가고, 사수는 즉각적인 반응을 얻을 수 있기 때문이다.

- 요구사항으로 부터 최종 시스템의 일부 측면에까지 빨리, 눈에 보이게, 반복적으로 도달하게 해줄 무언가를 찾아라.

- 일단 목표를 맞춘다면 기능을 추가하는 일은 쉽다.

예광탄

- 예광탄 코드는 나중에 버리려고 만드는 것이 아니다. 단지, 아직 완전한 기능이 들어 있지 않을 뿐이다.

- 예광탄 개발 방법은 프로젝트는 결코 끝나지 않는다는 관념과 일맥상통하는 점진적인 접근 방법이다.

- 다음과 같은 상황에 사용하면 좋다

 : 어플리케이션이 전체적으로 어떻게 연결되는지 알고 싶다.

 : 사용자에게 실제로 애플리케이션의 요소들이 어떻게 상호작용하는지 보이고 싶다.

 : 개발자들에게 코드를 붙일 아키텍처적 골격을 제시하고 싶다.

예광탄 코드 접근 방법의 장점

- 사용자들은 뭔가 작동되는 것을 일찍부터 보게 된다.

- 개발자들은 들어가서 일할 수 있는 구조를 얻는다.

- 통합 작업을 수행할 기반이 생긴다.

- 진전 상황에 대해 더 정확하게 감을 잡을 수 있다.

예광탄이 언제나 목표물을 맞추는 것은 아니다

- 예광탄은 지금 맞추고 있는 것이 무엇인지를 보여주고, 이 것은 꼭 목표물을 맞추리라는 보장은 없다. 이 경우 목표물이 맞을 때까지 조준을 옮기는게 핵심이다.

- 예광탄 코드 기법은 100% 확신할 수 없는 상황에서 사용된다.

- 문제가 발생하였을 때, 가벼운 개발 방법론을 선택했다는 사실에 감사해라.

프로토타입

- 제한된 몇 가지 질문에 답할 목적으로 설계되어 실제 제품보다 훨씬 적은 비용으로 개발할 수 있다.

- 위험 요소를 분석하고 노출시키며 이를 매우 저렴한 비용으로 바로잡을 기회를 얻기 위해 사용하는 방법론

- 포스트잇은 작업흐름과 애플리케이션 로직과 같은 동적인 것들을 프로토타이핑해 볼 수 있는 휼륭한 도구이다

- 프로토타입은 학습 경험이며, 그 가치는 코드가 아닌 교훈에 있다.

- 프로토타입을 코드로 만들 때는 시작 전 항상 모든 사람에게 여러분이 폐기처분할 코드를 작성하고 있다는 사실을 이해시켜야 한다.

- 만약 프로토타입 코드의 목적이 잘못 해석될 가능성이 크다고 느낀다면, 예광탄 접근 방식을 취하는 게 나을 것이다.

프로토타입을 만들 때 무시해도 좋은 세부사항은 무엇인가?

- 정확성 : 적절히 가짜 데이터를 사용할 수 있다.

- 완전성 : 제한된 기능만을 제공해도 괜찮다.

- 안정성 : 미리 정의된 방법대로 실행시키지 않는다면 터져도 괜찮다.

- 스타일 : 프로토타입은 주석이나 문서를 만들지 않아도 된다.

예광탄 코드 대 프로토타입

- 프로토타입

 : 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것을 목표로한다.

 : 나중에 버릴 수 있는 코드를 만든다.

- 예광탄

 : 정찰과 정보 수집을 목표로한다.

 : 완결된 코드이며, 최종 시스템 골격의 일부를 이룬다.

도메인이란

- 소프트웨어에서 실제 해결해야하는 문제점을 의미한다.

- 도메인을 가장 잘 알고 있는 사람은, 사용자이다.

문제 도메인에 가깝게 프로그래밍하라

- 사용자를 고려하라

 : 최종 사용자, 운영 스태프, 환경 설정 및 테스트 관리자, 유지보수 프로그래머 등 이차적인 사용자들도 있다.

 : 이들 모두에게 각자의 문제 도메인이 있기 때문에 각각의 소형 환경과 소형 언어를 만들어 줄 수 있다.

- 사용자의 진술을 구현하려는 어플리케이션에 맞추어진 소형 언어로 만들어라.

소형 언어를 구현하기

- 소형 언어는 꼭 실행가능할 필요는 없다. 하지만, 진짜 언어를 파싱하여 코드로 작성하는 방법도 있는데, 현재의 고통을 참고 더 복잡하지만 가독성 좋은 언어를 채택하여 미래의 유지보수 비용 절감을 통해 몇 배로 보상받을 수 있다.

- 방법 1 : 파싱하기 쉬운 라인중심 형식의 언어로 만드는 것이다.

- 방법 2 : 주 언어의 부분집합과 추상화 기능을 이용하는 것

추정을 통해 놀람을 피하라

- 추정에 대한 지식을 배운 후 경험을 통해 추정 능력을 계발하고, 어디에 크기에 대한 직관적 느낌을 적용해야 할지 알게 된다면, 무언가의 가능성을 가늠할 수 있는 마술과 같은 능력을 발휘할 수 있게 될 것이다.

모든 답은 추정치다.

- 누군가 추정치를 물었을 때, 자신에게 물어보아야할 첫 번째 질문은 답변이 사용될 상황이다.

- 사용하는 단위가 결과의 해석에 차이를 가져오므로, 전달하려는 정확도를 고려한 답변의 단위를 선택해라.

 : "130일 정도 걸리겠네요" -> "음, 상당히 가까운 시일 내에 끝나겠군"

 : "대략 6달 정도 걸리겠군요" -> "5~7달 사이 언젠간 끝나겠군"

좋은 답을 알려주는 기본적인 추정 기술

- 이미 그 일을 해본 사람에게 물어보라

- 무엇을 묻고 있는지 이해하자. 정확도 뿐아니라 도메인의 범위에 대해서도 고려하자.

- 시스템의 모델을 만들어보라

 : 클라이언트의 요청을 이해한다.

 : 꾸밈없는 모델을 만든다. (응답시간을 추정하고 있다면, 모델은 서버와 서버 사이에 도달하는 몇 종류의 트래픽을 포함하는 것이다.)

 : 모델을 만드는 과정에서 이면의 패턴과 프로세스를 발견하게 된다.

 : 모델을 만드는 것은 추정 프로세스의 부정확성을 야기하지만, 이것은 간결함과 정확성을 맞교환하고 있는 것이다. 따라서 언제 모델의 정교화를 그만두어야 할지는 경험이 이야기해 줄 것이다.

- 모델을 컴포넌트로 나누어라

 : 컴포넌트들이 어떻게 상호작용하는지에 대해 기술해주는 수식을 찾을 필요가 있다.

 : 이 단계에서 각 매개 변수를 규명하면 된다.

- 각 매개 변수에 값을 주어라

 : 나름의 근거에 의해 결과에 큰 영향을 미치는 매개 변수를 규명하라.

- 답을 계산하라

- 추정치를 기록해라

 : 실제 결과와 얼마나 가까운지 평가해봐라

 : 추정치가 잘못되었더라도 도망가지 마라. 왜 달라졌는지 시간을 들여 규명하면 다음엔 나아질 것이다.

프로젝트 일정 추정하기

- 프로젝트의 일정을 정할 수 있는 유일한 방법은 진행하는 해당 프로젝트를 점증적 개발를 통해 경험하는 것 뿐이다.

- 점증적 개발(incremental development)

 : 요구사항 체크하기

 : 위험 분석하기

 : 설계, 구현, 통합

 : 사용자와 함께 검증하기

- 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복의 끝으로 삼아라. 이 경험에 기반해 반복의 횟수와 각 반복에서 무엇을 할지에 대한 초기 추측을 다듬을 수 있다.

- 위의 정제는 각 반복이 끝날 때마다 나아질 것이고, 일정에 대한 확신도 이와 함께 증가할 것이다.

- 경영자들은 정확한 숫자를 원하기에 인기가 없을지도 모르지만, 경영자에게 팀의 생산성 그리고 환경이 일정을 결정한다는 사실을 이해하도록 도와야한다.

- 자판기 앞에서 말한 추정치는 커피와 마찬가지로 해를 끼칠 것이다. 누군가 추정에 대해 물으면 나중에 전화드린다고 말하고 위의 과정을 거쳐라.