[실용주의 프로그래머]를 읽고 #4. 2장. 실용주의 접근법. Topic 8, 9

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

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

---

2장. 실용주의 접근법
🔴 소프트웨어 개발의 모든 차원에 적용 가능한 요령이 있고, 보편적으로 적용된다고까지 할 수 있는 프로세스나 그 자체로 거의 당연하게 여겨지는 아이디어도 있다.
🤔 쉽게 말하자면, 경험적으로 체득하게 될 수 밖에 없는 소프트웨어 개발자만의 노하우가 있기 마련이다. 모두가 공감할만한 내용이 분명 존재하지만, 웹사이트, 블로그나 책 등에 파편화 되어있는 편이라 아쉬운데, 이번 장에서 속 시원하게 정리해보겠다! 라는 의미이다. 아직 10년도 안된 조무래기 개발자라서 그런지 몰라도, 이 장에서 읽게 된 내용들을 공감은 하지만 실천은 하고 있지는 않다. 매번 아 이런게 불편하네, 아 저런 게 필요하겠네, 아 그렇게 할껄…이런 후회가 많은 편이다. 
 
Topic 8. 좋은 설계의 핵심
🔴 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
🤔 일반적으로 ‘좋은 설계’라는 개념은 더 이상 바꾸지 않는, 바꿀 수 없는 완성된 설계이기 마련인데, 소프트웨어 개발 쪽에선 다르다. 바꾸기 어려운 설계야말로 나쁘고, 바꾸기 편한 설계여야 말로 좋다. 아니 그래야만 한다. 요구사항과 제한조건에 맞춰서 최선의 설계가 나오도록 노력하지만, 설계가 완성되고 난 이후에도 그 요구사항과 제한조건은 바뀔 가능성이 농후하기 때문이다. 그래서 항상 깨어있어야한다. 언제 뭐가 바뀔지 모르니까…
 
ETC(Easier to Change)는 규칙이 아니라 가치
🔵 스스로 자꾸 물어보라. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’
🤔 아키텍쳐를 결정할 때는 종종 이런 말을 되뇌이긴 하고, 레거시 코드를 건들 때도 생각해보는 질문이다. 그런데 정작 새로운 기능을 추가하거나 버그를 수정할 땐 이 부분을 깊게 생각 안하는 듯 하다. 아직 미완성이라고 생각하거나, 대고객 릴리즈 되지 않은 코드들이라 그런걸까…이런게 쌓이고 쌓여서 나쁜 설계, 기술부채로 이어지는 걸텐데 말이다.
 
⚫ 첫 번째로, 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 ‘바꾸기 쉽게’라는 길을 선택한다. 사실 여러분은 모든 코드를 교체할 수 있게 작성해야한다.
🤔 ‘바꾸기 쉽게’ 코드를 짜는 건, ‘확장성이 좋게’ 코드를 짜는 걸로 이어지는 경우가 많다. 하지만 마냥 확장성이 좋게 짜면, 지금 당장 쓸모없는 코드들이 쌓여서 오히려 가독성이 안 좋아지게 되기도 한다. 어느 정도의 타협이 필요한 셈.
 
⚫ 두 번째는 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라는 것이다. 엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스 코드에 이에 대한 표시를 남겨 둬라.
🤔 위에서 언급한 ‘타협’을 보완할 수 있는 부분인 듯 하다. 심사숙고해서 확장성은 좀 떨어지지만 좋은 퍼포먼스를 내는 방향으로 설계한다면, 지금 당장은 모두에게 좋을 테지만, 다음에 다른 사람이 와서 코드를 만질 때는 현타가 오거나 깨진 유리창을 만들게 될 수도 있다. 이런 상황에 대비해 흔적을 남겨두는 것이 좋겠다.
 
도전해 볼 것
⚫ 여러분이 일상적으로 사용하는 설계 원칙을 떠올려 보라. 그 원칙이 무언가를 바꾸기 쉽게 만들려는 것인가?
🤔 아쉽게도 그렇진 않다. ‘무언가를 바꾸기 쉽게’라기 보단, ‘누구라도 바꿀 수 있게’에 주안점을 두는 편이다. 비슷해 보이지만 다르다. 무언가를 바꾸기 쉽다는건 기반 지식이 탄탄하다는 전제조건이 필요할수도 있고, 누구라도 바꿀 수 있다는 건 비효율적인 방법일 수도 있다는 말이니까. 물론 두 마리 토끼를 다 잡을 수야 있겠지만, 보통은 그만큼 리소스가 더 필요하다. 그럼에도 불구하고, 리소스를 들여서 완벽한 설계를 만들어야 한다고 할 수도 있겠으나, Topic 5. 적당히 괜찮은 소프트웨어를 떠올리자. 깨어진 유리창을 만들지 않은 선에서 적당한 타협은 항상 필요하다.
이번 토픽에서 언급된 가장 중요한 문장을 기억하자 ETC(Easier to Change)는 규칙이 아니라 가치다.
 
Topic 9. DRY(Don’t Repeat Yourself): 중복의 해악
🔵 이유가 무엇이건, 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.
🤔 흔히 유지 보수가 필요한 이유는 새로운 요구사항이나 운영에서 발생한 예상치 못했던 버그라고 생각하기 쉽지만, 날마다 새로워지는 우리의 이해도에 따라 유지보수가 필요한 부분은 항상 생긴다는 다소 철학적인 문장.

🔵 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. 경우에 따라서는 중복 표현이 두 가지 완전히 다른 방식으로 이루어질 수도 있다.
🤔 코드 밖에서도 중복은 지양하자는 의미. 똑같은 내용을 프로젝트 README에도 적어두고, 따로 위키에도 적어두고, 피그마에도 표시하고…하면 서로 다른 버전의 개념이 중구난방 생길 수도 있다.

모든 코드 중복이 지식의 중복은 아니다
🔵 코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 우연히 규칙이 같을 뿐, 이것은 우연이지 중복이 아니다.
🤔 그렇다면, 코드가 동일하지만 두 함수가 표현하는 지식 조차 같을 때! 중복을 없애기 위해 반드시 조치를 취해야 하는가? 난 적어도 두 번까지는 괜찮다고 본다. 세번째 사례가 발생했을 때 조치를 취해도 늦지 않다. 두번째까지는 냄새일 뿐, 섣불리 고쳤다가 더 큰 유지보수가 필요해질 수도 있다고 생각한다. 두 번째 중복을 발견했다고 치더라도, 그것이 정말로 표현하는 지식이 같을 지는 의심해봐야한다.

데이터의 DRY 위반
⚫ 개발을 진행하다 보면 나중에는 성능상의 이유로 DRY 원칙을 위배할 수도 있을 것이다. 비용이 많이 드는 연산을 여러 번 수행하지 않기 위해 데이터를 캐싱할 때 종종 이런일이 생긴다. 요령은 중복의 영향을 국소화 하는 것이다. 바깥세상에는 DRY 원칙 위배를 노출하지 않는다.
🤔 절대 중복 불가! 를 내세우며 코드를 성배처럼 여기지 말자. 필요할 땐 중복이 생기더라도 너그럽게 이해해야 한다. 필요하면 주석이라도 추가해두던가.

🔵 모듈을 통해 제공되는 모든 서비스는 일관된 표기법으로 사용할 수 있어야 한다. 저장한 값으로 구현되었건, 계산을 통해 구현되었건 상관없이.
🤔 어떤 객체가 가지고 있는 값을 조회해야 한다고 치자. 객체의 노출된 필드를 그대로 접근해서 보여줘도 되고, getter를 써도 되지만, 이왕이면 하나의 방식으로 통일하자는 것. 아무래도 getter가 낫겠지? 다른 객체에서 노출되지 않은 필드가 있더라도 getter를 사용해서 동일한 형태로 제공할 수 있으니까.

표현상의 중복
⚫ 연결될 때마다 일종의 DRY 위반을 하게 된다. 여기서는 연결을 표현하는 지식을 여러분의 코드와 외부의 존재 양쪽이 모두 알아야 하기 때문에 중복이 생긴다.
🤔 어쩔 수 없이 중복이 생기는 경우. 내가 혼자서 북치고 장구치는 시스템이라면 중복을 최소화하기가 어렵진 않겠지만, 내외부와 통신해야하는 경우가 많다면 중복을 피하기 어렵다.
 
내부 API에서 생기는 중복
⚫ 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라.
🤔 명세를 잘하라는 의미…인데 이게 어떻게 중복을 최소화하는 방법일까

외부 API에서 생기는 중복
⚫ 공개 API를 OpenAPI 같은 형식으로 엄밀하게 문서화하는 경우가 점점 많아지고 있다.
🤔 이것도 역시 명세를 잘 활용하라는 의미…인데 이게 어떻게 중복을 최소화하는 방법인진 모르겠다.

 
데이터 저장소와의 중복
⚫ 많은 데이터 저장소가 데이터 스키마 분석 기능을 제공한다. 이런 기능을 이용하면 데이터 저장소와 코드 간의 중복을 많이 제거할 수 있다.
🤔 JPA같은 영속성 프레임워크를 사용하라는 건데, 확실히 쓰면 편하긴 하다. 하지만 잘 알고 써야하고, 경우에 따라 배보다 배꼽이 더 큰 경우가 있다. 차라리 중복 코드를 짜는게 더 유지 보수에 용이할 수도 있다.
  
개발자간의 중복
🔵 개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.
🤔 같은 레포지토리에서 같은 프로젝트를 진행하더라도 서로 자기 할 일만 하고 남의 작업을 신경쓰지 않으면 무수한 중복 코드가 발생한다. 코드가 문자열로 동일하지 않더라도, 동일한 기능과 개념을 가진 코드가 난무해서 나중엔 손 댈 엄두도 나지 않는다. 평소에 관심을 갖고 소통 좀 하자.
 
🔵 팀원 한 사람을 프로젝트 사서로 임명하라. 프로젝트 사서의 역할은 지식 교환을 돕는 것이다.
🤔 구글 엔지니어는 이렇게 일한다, 라는 책에서 뭔가 비슷한 역할이 있었던 것 같다. PL이 이런 역할을 하면 너무 업무 부하가 커지려나?

🔵 그리고 일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라.
🤔 같은 프로젝트가 아니더라도 옆 동료의 코드 리뷰를 해주는 게 많은 도움이 된다. 라고 생각해서 올해부턴 좀 해볼 요량..
 

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