[실용주의 프로그래머]를 읽고 #5. 2장. 실용주의 접근법. Topic 10, 11

실용주의 프로그래머라는 책을 읽으며, 삼색볼펜 독서법을 적용. 줄 친 내용에 대한 단상을 정리합니다.
삼색볼펜 스터디란? 책에서 중요하다고 생각되는 문장을 빨강 > 파랑 > 검정 순으로 줄을 치며 공부하는 방식.

🔴 가장 중요한 문장
🔵 그래도 꽤 중요한 문장
⚫ 그럭저럭 내 마음에 와닿은 문장
🤔 짧은 생각 (단상은 단상일뿐!!)
볼드체 중요한 문장은 아니지만 단락 구분 표시

---

Topic 10. 직교성
🔵 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
🤔 흔히 말하는 ‘낮은 결합도’. 소프트웨어 개발에서 완전한 직교는 존재하지 않고, 당장 눈에 보이지 않는 무언가가 영향을 끼칠 수 있다는건 유의하자.

생산성 향상
🔵 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다.
🤔 테스트 시간이 줄어들긴 한다. 예를 들어 한 클래스에 10개 정도의 의존성이 들어가 있다면…? 테스트하기가 아주 골치 아파진다. 이때 작은 단위로 쪼개놓고 각각을 개발하면 그만큼 테스트하기도 편해진다. 즉, 이 말은 테스트코드를 짜야 높은 결합도를 발견해서 결국 낮은 결합도의 코드를 만들기 용이해진다는 의미이기도 하다.

🔵 직교적인 접근법은 재사용도 촉진한다. 시스템이 더 느슨하게 결합되어 있을수록 재조합하고 개량하기 쉽다.
🤔 뭐 공통적인 요소를 잘 뽑아 냈다면 그렇겠지만, 재사용과 재조합을 실제로 많이 할 수 있을진 의문이다.

리스크 감소
🔵 감염된 코드가 격리되어 있다.
🤔 정작 직교적으로 코드를 짜두고, 감염이 전파되게 만들 때가 있다. 그게 말이 되냐 싶겠지만, 흐린 눈으로 코드를 봤을 땐 서로 독립적으로 보이는 코드들이 손에 손잡고 예외를 넘기기도 하니 주의하자.

설계
🔵 특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가? 답은 ‘하나’ 다.
⚫ 하지만 현실에서 이는 순진한 생각이다. 엄청나게 운이 좋지 않은 이상 현실 세계에서 요구 사항 변경은 대부분 시스템의 여러 기능에 영향을 끼친다.
🤔 위에서 언급했던 슬픈 현실. 요구사항이 변경이 있을 때 필요한 모듈만 딱딱 고치면 되지 않느냐? 라는 건 현실적으로 이루어지기 힘들다. 물론 제일 앞단의 프론트엔드 레이어의 변경사항이 제일 뒷단의 데이터베이스 레이어까지 영향 받으면 안되겠지만, 적어도 동일한 레이어 내부에선 영향이 와르르 전파될 수도 있으니, 그렇게 설계하지 못했다고 자책하진 말자.

⚫ 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.
🤔 정책 등의 변경으로 인해서, 당연하다고 생각했던 스펙이 변경되는 때가 아주 가끔 발생한다. 이를테면 우편번호가 과거엔 6자리였는데, 갑자기 5자리로 바뀐다거나…? 6자리 숫자에 강하게 의존했던 시스템이라면 5자리로 바뀐 우편번호를 적용할 때 애를 먹었을 지도 모른다. 그러므로 항상 당연하다고 하는 것들에 대해 다시 한번 생각해보자. 가령, 데이터베이스 테이블부터 설계한다면 대체키의 사용을 고려해보는 습관을 들이자.

테스트
⚫ 직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다.
🤔 위에서 언급했으니 고개 끄덕이고 넘어간다.

⚫ 테스트를 마친 뒤 코드를 병합할 때 버그 수정에 대한 태그를 붙여라. 이렇게 하면 버그 수정마다 수정한 소스 파일 개수를 수집하여 그 경향을 분석한 월 단위 리포트를 만들 수 있을 것이다.
🤔 이런 건 해볼 생각을 못했는데, 개발이 완료된 후에 테스트 형상으로 올려두고 나서 리포트를 작성해도 괜찮을 거 같긴하다. 얼마나 자주 요구사항이 변경되었는지, 어느 부분에서 버그가 발생했는 지 등등…
 
Topic 11. 가역성
⚫ 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. - 에밀 오귀스트 샤르티에
🤔 끝없이 의심해야 하는 이유… 요구사항과 스펙은 항상 바뀐다. 그런데 일정은 안 바뀐다.
 
⚫ 문제는 중요한 결정은 쉽게 되돌릴 수 없다는 데 있다.
🤔 개발언어나 근본적인 설계 방향 같은 건 신중하게 결정해야 한다. 한번 정하면 중간에 뒤엎는게 쉽지 않다.

가역성
🔵 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다.
🤔 결정은 바뀌지 않는 다는 확신을 가지고 개발을 하는 것도, 결정은 무조건 바뀐다는 회의적인 시각을 가지고 개발을 하는 것도 둘 다 문제다. 언제라도 달라질 수 있다는 각오 정도만 하고 행동하자!

유연한 아키텍쳐
⚫ 이렇게 아키텍쳐가 변덕스러운 환경에서 어떻게 계획을 세울 수 있겠는가? 못한다.
🤔 얼마 전까진 ‘무조건 MSA! 타도 모놀리틱!’ 이라는 추세였다면, 최근에 내가 느끼기엔, ‘…그래도 이정도 모놀리틱은 괜찮지 않을까? MSA는 관리 포인트가 너무 많아’라는 목소리가 들리는 듯하다.

🔴 유행을 좇지 마라.
🤔 이런 방법도 있고, 저런 방법도 있으니 쓸 수 있는 카드(=지식)을 항상 품 안에 넣어두고 상황에 맞춰서 사용할 수 있어야 한다. 그러니까 공부하자…
 

실용주의 프로그래머(20주년 기념판)