2장 - 실용주의 접근법 (A Pragmatic Approach)

개발 중 아래 설명하는 기본적인 원리들을 유념하면

더 좋은, 더 빠른, 더 강력한 코드를 작성할 수 있을것이라 이야기한다.

📌 Topic8 - 좋은 설계의 핵심

좋은 설계는 나쁜 설계보다 바꾸기 쉽다

🚀 ETC 원칙은 규칙이 아니라 가치

아무 실마리가 없을 경우!

1. 코드를 교체하기 쉽게 만들도록 노력하기
2. 직관을 발전시키는 기회!

📌 Topic9 - DRY(Don’t Repeat Yourself) 중복의 해악

지식은 고정적이지 않다.

유지보수

유지 보수란 버그를 고치고 기능을 개선하는 것이 아니다. 늘 유지보수 모드이다.

DRY 원칙
모든 지식은 시스템 내에서 단 한번만, 애매하지 않고, 권위 있게 표현되어야 한다.

DRY를 따르지 않으면

중복된 코드를 기억하느냐 마느냐의 문제가 아니라,

언제 잊어버릴가 하는 문제다.

DRY는 코드 밖에서도

재사용하기 쉽게 만들어라.

• 기본적으로는 코드에서의 중복
  • 모든 코드 중복이 지식의 중복은 아니다!
• 문서화 중복
  • 코드 + 주석
• 데이터의 DRY 위반
• 표현상의 중복
  • 중복을 피할 수는 없지만 완화할 수 있다.
  • 내부 API에서 생기는 중복
    • API 명세가 가능한 도구를 이용
  • 외부 API에서 생기는 중복
    • OenAPI 형식으로 공개
  • 데이터 저장소와의 중복
    • 스키마 분석 기능
    • 외부 데이터를 고정된 구조 대신 키—값 데이터 구조에 밀어 넣는 것
  • 개발자 간의 중복
    • 의사소통 및 유대가 돈독한 팀을 만들 것
    • 일일 스크럼 스텐드업 미팅
    • 공통 소통 공간 만들기
    • 프로젝트 사서로 임명
    • 일상적인 코드 리뷰

📌 Topic10 - 직교성(Orthogonality)

설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는데 매우 중요한 개념

직교성 이란

결합도 줄이기를 의미한다.

하나를 바꾸더라도 나머지에 어떠한 영향도 주지 않으면 서로 직교한다고 표현한다.

비-직교적인 시스템

모든 변경 하나하나가 나머지 모든 입력에 영향을 주는 시스템.

관련 없는 것들 간에 서로 영향이 없도록 하라.

직교성의 장점

독립된 컴포넌트는 외부 인터페이스를 바꾸지 않는 한 전체 시스템으로 퍼져가는 문제를 일으키지 않는다.

• 생산성 향상
  • 테스트 시간의 축소
  • 재사용 촉진
  • 각기 다른 컴포넌트의 장점을 결합하여 더 많은 기능을 얻을 수 있음.
• 리스크 감소
  • 잘못 작성된 코드를 도려내고 새로 작성하기 편함
  • 수정한 코드의 문제가 생기더라도 문제점이 생긴 부분은 수정한 부분 한곳으로 한정될 것.
  • 테스트 설계 및 실행이 쉬워 테스트 작성에 용이하다.
  • 특정 비지니스 로직에 덜 종속 될 수 있다.

설계

계층 구조

추상화

유연성

• 설계가 직교적인지 확인하는 방법
  Q: 특정 기능에 대한 요구 사항을 대폭 변경해야 하는 경우 몇 개의 모듈이 영향을 받는가

자신의 힘으로 제어할 수 없는 속성에 의존하지 말라

툴킷과 라이브러리

외부 라이브러리나 툴킷을 도입할 때 직교성을 해치지 않는지 고민하고 현명하게 선택하라.

코딩

• 코드의 결합도를 줄여라
  • 불필요한 것은 다른 모듈에 보여주지 않는 부끄럼쟁이 코드를 작성하라.
• 전역 데이터를 피하라
  • 전역 데이터를 공유하는 다른 컴포넌트와 묶이면 불필요한 결합을 만들 수 있다
• 유사한 함수를 피하라

비판적으로 보는 습관을 길러 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라.

테스트

직교적으로 설계한 시스템은 테스트하기 쉽다.

문서화

정말 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있다.

내용의 이동이나 수정 없이 꾸밀수 있다는 이야기.

직교적으로 살아가기

📌 Topic11 - 가역성(Reversibility)

알고 있는 해결책은 언젠가는 변할 것이다.

가역성

결정은 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨다.

최종 결정이란 없다.

유연한 아키텍쳐

아키텍쳐가 자주 바뀌는 변덕스러운 환경에서는 계획을 세울 수 없다.

할 수 있는 방법은 바꾸기 쉽게 만드는 것이다.

유형을 좇지 말라.

📌 Topic12 - 예광탄

일반 탄환들 사이에 일정한 간격으로 끼워있는 예광탄처럼

우리 프로젝트에서도 실제 조건하에서 즉각적인 피드백을 받아야 한다.

어둠 속에서 빛을 내는 코드

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

최종 시스템까지의 일부분까지 빨리, 눈에 보이게, 반복적으로 도달할 무언가(예광탄)를 찾아야한다.

• 시스템을 정의하는 중요한 요구 사항을 찾아라.
• 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라.
• 위험 부분이 가장 커 보이는 코드를 가장 먼저 작성하도록 우선순위를 정하라.

예광탄 코드의 장점

• 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
• 개발자가 들어가서 일할 수 있는 구조를 얻는다
• 통합 작업을 수행할 기반이 생긴다
• 보여줄 것이 생긴다
• 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

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

예광탄이 맞히고 있는게 ‘무엇인지’ 보여주는 것이지 ‘목표물’이라는 보장은 없다.

핵심은 목표물에 맞을 때까지 조준을 옮기는 것 이다.

예광탄 코드 대 프로토타이핑

• 프로토 타입
  • 목표: 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것
  • 어떤 경우든 결정을 내리고 나면 다시 처음부터 최종 목표 환경에서 코드를 작성한다.
• 예광탄 코드
  • 목표: 애플리케이션 전체적으로 구현체를 구현하며, 사용자에게 상호 작용을 보여주는 것, 개발자에게는 전체적인 아키텍쳐 골격을 제시하는 것
• 차이점
  • 프로토타입: 나중에 버리는 코드를 만드는 것
  • 예광탄 코드: 기능은 별로 없지만 완결된 코드이며 최종 시스템 골격 중 일부가 되는 것.

📌 Topic13 - 프로토타입과 포스트잇

프로토 타입의 목적은 위험 요소를 분석하고 노출시킨 후, 이를 아주 저렴한 비용으로 바로잡을 기회를 마련하는 것

세부 사항을 포기할 수 없는 환경이라면 프로토 타입보다는 예광탄 방식의 개발이 더 적절할 것.

프로토 타이핑 대상

• 위험을 수반하는 모든 것
  • 이전에 해 본 적이 없는 것
  • 최종 시스템에 매우 중요한 것
  • 증명이 되지 않은 것
  • 실험적인 것
  • 의심이 가는 것
  • 마음이 편하지 않은 것

프로토 타이핑은 학습 경험이며 해당 가치는 코드에 있는게 아니라 프로토 타이핑을 통해 배우는 교훈에 있다.

프로토 타이핑으로 학습하라

프로토 타입을 어떻게 사용할 것인가

• 무시해도 좋은 세부 사항
  • 정확성
  • 완전성
  • 안정성
  • 스타일

아키텍쳐 프로토 타이핑

프로토 타이핑의 목적은 전체 시스템이 어떻게 동작할 지 감을 잡는 것

코드 이외에 간단하게 포스트잇이나 화이트보드로 설계해도 좋다.

프로토타입 코드를 사용하지 않도록 하려면

코드가 폐기될 것이고, 불완전하며, 완성될 수 없다는 사실을 분명히 사람들에게 알려야 한다.

작업환경이나 문화에서 프로토타입 코드의 목적이 잘못 해석될 가능성이 크다면 예광탄 접근 방식이 나을것

📌 Topic14 - 도메인 언어

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

내부 언어

실행시키는 코드 내부로 들어가는 코드

도메인 언어(내부 언어)가 원래 코드의 어휘를 진짜로 확장시키는 것

외부 언어

별도의 코드가 외부 언어를 읽어 들여서 사용할 수 있는 형태로 바꾸는 것.

내부 - 외부 언어의 장단점

• 내부 언어
  • 장점
    • 호스트 언어의 기능을 쓸 수 있음
    • 도메인 언어를 추가 리소스 없이 강력하게 만들 수 있는 점
  • 단점
    • 호스트 언어의 문법과 의미론을 따라야만 한다.
    • 원하는 언어와 구현할 수 있는 언어 사이에서 어느 정도 타엽해야 함
    • 궁극적으로 어떤 형태로 만들더라도 호스트 언어의 문법을 벗어날 수 없음
• 외부 언어
  • 장점
    • 내부 언어의 단점이 없다

결론

• 절약하는 것보다 더 많은 시간을 쏟지 말라.
• 기본적으로 가능하다면 YAML, JSON, CSV와 같은 널리 통용되는 언어를 사용하라.
• 그게 아니라면 내부 언어를 고려하라
• 외부 언어는 애플리케이션의 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.

📌 Topic15 - 추정

추정으로 놀람을 피하라

얼마나 정확해야 충분히 정확한가

답변이 사용될 상황이 무엇인지 생각해보라

• 매우 높은 정확도의 답을 요구하는가.
• 단순히 큰 그림만을 요구하는가.

전달하려는 정확도를 고려하여 답변의 단위를 선택하라.

추정치는 어디에서 나오는가

경험자에게 조언을 구하라

모델 작성에 너무 시간을 많이 쏟기 전에 비슷한 상황에 처했던 경험자에게 조언을 구한다면

그 경험을 바탕으로 성공적인 추정치를 낼 수 있을것

• 무엇을 묻고 있는지 이해하라
  • 정확도뿐 아니라 도메인에 존재하는 조건에 대해서도 알아야한다.
  • 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러라.
• 시스템의 모델을 만들어라
  • 기본적인 것만 갖춘 개략적인 모델을 만들어보라.
    • 전체 시스템에 사용할 발판이 되고, 어떻게 구현해야 할지에 대한 배경이 될것이다.
• 모델을 컴포넌트로 나눠라
  • 각 컴포넌트가 어떻게 전체 모델에 기여하는지 나타내는 매개 변수를 찾아라.
• 각 매개 변수에 값을 할당하라
  • 약간의 오차가 발생할 수 있다.
    • 결과에 가장 큰 영향을 미치는 매개 변수를 찾아 해당 매개 변수의 값을 최대한 정확하게 산출하라
  • 매개 변수를 계산할 때는 근거가 있어야 한다.
• 답을 계산하라
  • 주요 매개 변수들의 값을 변경시켜 가면서 여러 번 계산해 모델에 가장 잘 들어맞는지 찾아라.
• 여러분의 추정 실력을 기록하라
  • 이전의 추정치를 기록하고 실제 결과와 비교하여 얼마나 정확했는지 평가하라.
  • 추정치가 틀렸더라면 원인을 찾아 회고하라

프로젝트 일정 추적하기

• 미사일에 페인트 칠하기
  • 낙관적 추정치, 가장 가능성이 높은 추정치, 비관적 추정치를 계산하여 전체 프로젝트 예상 최소 ~ 최대 소요 시간을 계산하는 방법
• 코끼리 먹기

  코드와 함께 일정도 반복하며 조정하라

  • 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복주기로 삼아라
  • 이 후 무엇을 할지에 대한 추측을 다듬어라
  • 각 반복 주기가 끝날 때마다 추측을 다듬다보면 일정에 대한 확신이 들것이다.

• 더 정확한 일정을 추정하는 것을 각 반복 주기의 일부로 삼았을 때, 구성원이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있을 것.