[실용주의 프로그래머] 실용주의 접근법

Topic 8 좋은 설계의 핵심

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

잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. 

그래서 우리는 ETC 원칙을 따른다. 바꾸기 더 쉽게 (Easier to Change)

 

1. 결합도 줄이기

• 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문

2. 단일 책임 원칙 (Single Responsibility Principle)

• 요구사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문

3. 좋은 이름 짓기

• 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문

 

ETC는 규칙이 아니라 가치

가치는 결정을 내리게 도움을 주는 것이다. 소프트웨어라는 틀에서 생각해 보면 ETC는 선택의 갈림길에서 도움을 주는 안내자다.

어떻게 가치를 내면화할 수 있을까?
초기에는 의식적으로 노력하라. '내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?'

판단하기 어렵다면 다음 두 가지를 해 보라.

1. 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 '바꾸기 쉽게'라는 길을 선택한다. 
내가 작성하는 코드를 교체하기 쉽게 만들도록 노력하는 것. 코드의 결합도를 낮추고 응집도를 높이라는 이야기이다.

2. 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라는 것이다.
엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스코드에 이에 대한 표시를 남겨 둬라. 나중에 이 코드를 바꿔야 하는 시점이 왔을 때, 자신에게 피드백을 줄 수 있을 것이다. 그러면 비슷한 갈림길에 다시 섰을 때 도움이 될 것이다. 

 

 

도전해보기

• 여러분이 일상적으로 사용하는 설계 원칙을 떠올려 보라. 그 원칙이 무언가를 바꾸기 쉽게 만들려는 것인가?
• 언어나 프로그래밍 패러다임(객체 지향, 함수형, 반응형 reactive 등)을 떠올려 보라. ETC를 따르는 코드를 작성할 때 큰 도움을 주거나 큰 걸림돌이 되는 부분이 있는가? 둘 다를 가진 경우는 없는가? 코드를 작성할 때 장애물은 없애고 도움을 주는 부분만 잘 살릴 방법이 있을까?