실용주의 프로그래머 - 2장. 실용주의 접근법 1

실용주의 접근법

Topic 8 좋은 설계의 핵심

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

• ETC 원칙 : 바꾸기 더 쉽게 (Easier to Change)
  • 결합도를 줄인다 : 관심사를 분리함으로써 각각이 더 바꾸기 쉬워진다
  • 단일 책임 원칙(SRP) : 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있다
  • 이름 짓기 : 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 한다

ETC는 규칙이 아니라 가치

• 가치(value)는 결정을 내리게 도움을 주는 것
• ETC는 선택의 갈림길에서 도움을 주는 안내자
• ETC에는 암묵적인 전제가 있다
  • 여러 길 중 어떤 길이 미래의 변경을 쉽게 만드는지 알 수 있다는 것
• 실마리가 없는 경우
  • ‘바꾸기 쉽게’ : 작성하는 코드를 교체하기 쉽게 만들도록 노력하기
  • 직관을 발전시킬 기회 : 엔지니어링 일지에 연재 상황과 선택, 변경 사항에 대한 추측을 정리하고 소스 코드에 이에 대한 표시 남기기

도전해 볼 것

• 일상적으로 사용하는 설계 원칙을 떠올리고, 이 원칙이 무언가를 바꾸기 쉽게 만드려는 것인가?
• 언어나 프로그래밍 패러다임에서 ETC를 따르는 코드를 작성할 때 큰 도움을 주거나 큰 걸림돌이 되는 부분이 있는가?
• 코드 작성 시 장애물은 없애고 도움을 주는 부분만 잘 살릴 방법이 있을까?
• 파일을 저장할 때마다 “ETC?”라는 팝업을 띄우도록 설정하고, 팝업창이 뜰 때마다 방금 작성한 코드에 대해 생각해 보라.

Topic 9 DRY: 중복의 해악

Tip 15 DRY: 반복하지 말라 (Don’t Repeat Yourself)

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

DRY는 코드 밖에서도

• 코드 뿐만 아니라 지식의 중복, 의도의 중복에도 해당된다
• 똑같은 개념을 다른 곳 두군데에서 표현하면 안 된다
• DRY 여부 판별
  • 코드의 어떤 측면 하나를 바꿔야 할 때 여러 곳을 바꾸고 있는가?
  • 코드를 바꾸고 문서도 바꾸는가?
  • 데이터베이스 스키마를 담고 있는 구도 등도 바꾸는가?

코드의 중복

모든 코드 중복이 지식의 중복은 아니다

• 코드는 동일하지만 두 함수가 표현하는 지식이 다른 경우

문서화 중복

• 주석과 코드로 함수의 의도를 두 번 표현하기보다, 함수 이름이 함수가 하는 일을 알려줄 수 있도록 한다

데이터의 DRY 위반

• 자료 구조는 지식을 표현하고, DRY 원칙을 위배할 수 있다

표현상의 중복

• 다른 라이브러리, 다른 서비스와 연결될 때마다 일종의 DRY 위반을 하게 된다
  • 연결을 표현하는 지식을 코드와 외부 양쪽이 모두 알아야 하기 때문
• 내부 API에서 생기는 중복
  • 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라
  • 이상적으로 이 도구를 이용하여 모든 API 정의를 중앙에 두고 여러 팀이 공유할 수 있게 하면 좋다
• 외부 API에서 생기는 중복
  • 문서화된 API 명세를 API 도구로 불러와서 사용한다
• 데이터 저장소와의 중복
  • 데이터 스키마 분석 기능을 이용해 데이터 저장소와 코드 간의 중복을 많이 제거할 수 있다
  • 코드에서 외부 데이터를 고정된 구조로 표현하는 대신 키-값 데이터 구조에 밀어 넣는다
    • 필요한 만큼만 데이터에 접근함으로써 생기는 안전장치가 많이 사라지기 때문에 데이터를 한 겹 더 감싸는 것을 권장

개발자 간의 중복

• 개발자 간의 중복을 대처하려면 의사소종을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다
• 개발자 간에 적극적이로 빈번한 소통을 장려하라
  • 일일 스크럼 스탠드업 미팅 운영해보기
  • 팀원 한 사람을 프로젝트 사서로 임명하기
    • 프로젝트 사서의 역할 : 지식 교환을 돕는다

Tip 16 재사용하기 쉽게 만들어라

• 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다

Topic 10 직교성

직교성이란

• 기하학 : 그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 한다
• 일종의 독립성이나, 결함도 줄이기(decoupling)를 의미한다
• 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다
  • 잘 설계된 시스템에서는 데이터베이스 코드가 사용자 인터페이스와 서로 직교할 것이다

직교성의 장점

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

• 생산성 향상
  • 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다
  • 재사용 촉진
  • 직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다
• 리스크 감소
  • 감염된 코드가 격리되어 있다
  • 시스템이 잘 깨지지 않는다

설계

• 모듈의 집합
  • 서로 협력하는 모듈의 집합, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다
• 계층 단위의 추상화
  • 각 계층은 자기 바로 밑에 있는 계층이 제공하는 추상화만을 사용하기 때문에, 다른 코드에 영향을 끼치지 않으면서 기반 구현을 변경할 수 있어 유연성이 높아진다
• 설계가 직교적인지 확인할 때 컴포넌트들을 나누었을 때 스스로 물어보기
  • 특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?
  • 직교적인 시스템에서는 답이 ‘하나’여야 함

툴킷과 라이브러리

• 기술을 현명하게 선택해 외부의 툴킷, 라이브러리 도입시 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보자

코딩

• 직교성을 유지하기 위해 사용할 수 있는 기법
• 코드의 결합도를 줄여라
  • 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라
• 전역 데이터를 피하라
• 유사한 함수를 피하라

테스트

• 직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다
• 단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회다
• 버그 수정은 시스템의 직교성을 총체적으로 점검해 볼 수 있는 값진 시간이다

문서화

• 문서에서 내용과 표현이라는 두 개의 축에서, 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있다

직교적으로 살아가기

• 직교성은 시스템 컴포넌트 간의 상호 의존도를 줄인다 (DRY 원칙은 시스템 내부의 중복을 최소화함)

Topic 11 가역성

가역성

• DRY 원칙, 결합도 줄이기, 외부 설정 사용하기 등을 따른다면 중요하면서도 되돌릴 수 없는 결정의 수를 가능한 한 줄일 수 있을 것이다
• 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다

Tip 18 최종 결정이란 없다.

유연한 아키텍처

• 아키텍처가 변덕스러운 환경에서 계획을 세우기보단 바꾸기 쉽게 만드는 것이 우리가 할 수 있는 일이다
  • 외부 API를 우리가 만든 추상화 계층 뒤로 숨기자
  • 우리의 코드를 여러 컴포넌트로 쪼개라

Tip 19 유행을 좇지 말라.

도전해 볼 것

• 미래에 대비하는 코드를 작성하는 것이 어려울 만 하지만, 각각의 결정은 다른 버전의 미래를 야기한다