[Tidy First?] Part3 이론을 읽고 나서

[Tidy First?] Part3 이론을 읽고 나서

🔖 주제                                                            

Tidy First?는 켄트 벡의 소프트웨어의 설계 진행에서 생기는 고민을 어떻게 받아들였는지에 대한 노하우를 소개하는 책입니다.

사내 스터디에서 챕터 별로 읽으며 의견을 나누는 방식으로 진행하고 있으며, 이번 주제는 22챕터~28챕터입니다.

책의 전반적인 주제는 "리펙토링"에 대해 이야기합니다.

"리펙토링은 이렇게 저렇게 해야 한다."보다 리펙토링이라는 행동을 언제, 누구와 어떻게 하는 것이 좋은지 넓은 범위로 설명합니다.

📓 설명                                                            

구조와 동작-시스템 가치

1달러를 넣을 때, 10달러를 내놓는 기계보다 더 좋은 것이 무엇일까요?
10달러를 넣을 때마다 100달러를 내놓는 기계입니다. 아니면 1달러를 넣으면 20달러가 나오는 기계죠.
어떻게 하면 더 나은 기계에 도달할 수 있을까요?

 

"더 나은 기계"의 도달 조건은 "선택의 가능성"입니다.

특정 방식으로 동작하는 시스템이 이미 존재한다면, 그것 만으로 시스템이 "어떻게 동작"해야 하는지에 대한 욕구가 달라집니다.

가령 광고를 등록하는 시스템이 이미 존재한다면, 우리는 등록하는 시스템을 기반으로 프로모션 광고, 타겟팅 광고 등 새로운 "선택 가능성"을 개발할 수 있습니다.

어찌 되었든, 시스템을 더 가치 있게 만들기 위해서 굳이 시스템의 동작을 변경할 필요는 없다는 것입니다.

동작 다음에 무엇을 할 수 있는지에 대해 선택할 수 있는 기회가 만들어진다면 이미 돈을 벌은 것입니다.

 

이 챕터의 재미난 점은 제가 하는 업무가 왜 돈이 되고 있는지, 난 그 과정에 왜 구조와 추상화 등을 하는지 알려주기 때문입니다.

요구사항을 분석 후 구현한 것은 "동작"하는 시스템입니다.

이는 서비스에 배포까지 마치면 다시 되돌리기 힘든 영역입니다. (힘든 것이지 불가능하지는 않습니다.)

"동작"을 만드는 과정에 "구조"를 제대로 고심하여 개발했다면?

우리는 "광고 등록"이라는 변경하기 어려운 동작을 그대로 두고 "구조"에 따라 새로운 기능을 만들 수 있다는 것입니다.

구조는 동작과 다르게 변경이 어렵지 않다는 점이 있습니다.

 

다만 이 내용을 읽으며 생각이 들 점은, 구조를 잘 설계했는지?, 정말 구조에 더 많은 투자를 한다고 해서 코드 변경이 쉬워지는지?입니다.

이는 본질적으로 다르다는 점을 이해해야 합니다.

구조에 대한 변경과 동작에 대한 변경은 모두 가치를 만들어 냅니다.

• 우리가 변경에 대한 어떤 요구사항을 받았을 때 "앗 그건 좀 어려워요"라는 대답을 했다면 이는 구조에 대한 변경이 한계에 달했다는 것입니다.
• 시스템 전체의 컨벤션을 지키는 것은 팀 내에 중요한 일이 될 수 있습니다.
  다만, "그 컨벤션이 정상적으로 동작하는지", "향후 변경에 대한 구조에 대응하기 쉬운지" 등 을 잘 봐주세요.
  컨벤션을 따르는 것은 좋지만 대게 안티패턴을 컨벤션으로 두고 따라 하고 있을 수 있습니다.

---

오늘의 1달러가 내일의 1달러보다 크다

'오늘 천만 달러를 지불하고 10년 후에 2천만 달러를 받는다'와 '오늘 1천2백만 달러를 받고 10년 후에 천만 달러를 지불한다'의 차이를 느껴보세요.

 

저는 개발을 진행하며 종종 코드가 지저분하게 어질러져 있다고 느껴 "코드 정리"를 진행하고 싶다는 생각을 합니다.

이때 코드 정리를 진행하는 것은 어떨까요?

이 책은 "더 나은 소프트웨어의 설계"에 대한 방법을 제시하며, 그 방법의 일환으로 "코드 정리"를 이야기합니다.

하지만 "코드 정리"는 필요하면서도 상황을 잘 판단하라 책 전반에서 이야기하며 해당 챕터가 가장 이해하기 쉬운 설명을 합니다.

 

코드 정리를 "오늘 천만 달러를 지불" 한 것으로 이해해 볼까요?

코드 정리에 저렇게 큰 비용이 들지 않겠지만 어찌 되었든 비용을 지불했습니다.

일반적으로 저렇게 큰돈을 지불하면 10년이라는 기간 동안 불안에 떨 것입니다.

10년 뒤 2천만 달러를 줄 사람이 없어졌을 수 있고, 내가 속았을 수도 있고, 슬프게도 10년이 오지 않을 수 도 있기 때문입니다.

이는 "코드 정리"라는 방법이 꼭 내가 "2천만 달러"를 받는 것에 도움이 될 것인지에 대해 의문을 갖게 합니다.

어떠한 상품에 대해 비용을 지불하고자 할 때(동작 구현), 할인이 될 수 있다면(코드정리)?

이 상황에서는 코드 정리가 유효할 수 있습니다.

다만 이런 경우가 많지는 않을 것이라 생각합니다.

우리는 더 나은 코드를 개발하고자 합니다.

이해하기 쉬운 코드, 동작이 빠른 코드, 오류가 없는 코드 등 다양한 것을 목표하고 공부하여 도달하고자 합니다.

지금 상황도 똑같습니다. 동작을 구현하며 시스템 이해도가 높아질 수 있고 내가 당장 생각하고 있던 정리 방법보다 더 좋은 방법이 떠오를 수 있습니다.

즉각 해서 돈을 벌 수 있는 방법(동작 구현)을 뒤로 미루는 것이 정답이 되기 어려울 수 있습니다.

 

• 물론! 코드 정리를 진행하며 시스템 동작에 대한 이해도를 높일 수 있습니다.
  다만,  코드 정리를 하며 시스템 동작을 이해한다는 것은 "내가" 개발한 것이 아니었거나 "개발한 지 오래된" 것일 가능성이 큽니다.
  내가 개발한 것이 아니라면 코드 정리는 도움이 될 수 있다 생각합니다.
  '개발한 지 오래된 것'에 코드 정리가 필요하다면? 이는 재 때 코드정리를 안 한 것이라 생각합니다. (10년 뒤 비용지불을 안한 것)

---

 

📚 정리                                                            

미래를 염두해 미리 리펙토링을 진행하지 말자!

책 내용 중 인상 깊은 문장을 가져와 제가 어떻게 생각했는지 정리했습니다.

 

시스템의 동작을 바꿀 필요가 없습니다

시스템을 더 가치 있게 만들기 위해서 굳이 시스템의 동작을 바꿀 필요가 없습니다.
다음에 무엇을 할 수 있는지에 대해 선택할 수 있는 기회를 만들면, 저는 이미 돈을 번 것입니다. p.105

• 리펙토링을 공부하다 보며 매몰된 나머지, 어느 순간부터 개발의 우선 사항은 "코드 변경이 유연하도록"였습니다.
• 기존 동작에 새로운 동작(옵션)을 추가하기 위해 인터페이스와 구현체를 나누고 피쳐 토글을 통해 플래그로 동작을 제어하는 등 유연한 코드는 작성했다 생각합니다.
• 다만 "유연한" 설계를 해야 하는 이유를 고민하지 않았는데, 운이 좋게도 좋은 팀원들과 함께 개발하다 보니 자연스레 바른 방향으로 이끌린 것 같습니다.

먼저 돈을 벌고 나중에 돈을 써라

오늘 천만 달러를 지불하고 10년 후에 2천만 달러 받기 VS 오늘 1천2백만 달러를 받고 10년 후에 천만 달러 지불하기 p.112

• 천만 달러를 덜컥 지불하고 10년을 기다린다고 생각하면 눈앞이 캄캄해집니다.
  10년 안에 내게 무슨 일이 생기면 어떡하지? 달러의 가치는? 그 안에 돈이 급해지지 않을까?
• 당장 1천2백만 달러를 받는다면 못해도 2백만 달러는 편한 마음을 갖고 사용할 수 있을 것입니다.
  물론!! 10년이 다가오면 다가올수록 불안해질 것입니다.
• 이를 코드 정리로 비교해 보면 와닿는 게 생깁니다.
  지금 당장 코드 정리(천만 달러 지불하기)를 시작하면 지불한 비용만큼 지속적으로 내게 도움을 줄까?
  중간에 동작이 크게 변경하여 정리가 무쓸모 해질 수 있고, 정리 자체가 불필요하게 이루어져 작업에 방해가 될 수도 있습니다.
• 코드 정리를 무조건 미루자는 것이 아닌 신규 기능 동작 추가와 같은 변화하는 내용에 대해 먼저 정리를 시도하는 것은 불필요한
  지불이 될 수 있다는 것입니다.

일에 대한 대가

저는 지금까지 한 일에 대한 대가를 받고 있다고 생각했습니다.
하지만, 실제로는 그렇지 않았습니다. 대부분은 다음에 할 수 있는 일에 대한 대가를 받고 있었습니다. p.115

• 배움을 얻었다 생각한 문장입니다.
  전달받은 사항에 대해 논의하고 기능을 구현하는 것은 당연하다 생각했습니다.
  다만, 이후에 발생할 추가 기능(옵션)은 좀 가벼운 느낌으로 "네. 추가는 어렵지 않아요 또는 아 좀 어려운데.." 쉽게 이야기하며
  업무를 한다는 느낌보다 "자잘한 것을 털어내는 것"이라 생각했습니다.
• 생각해 보면 구현한 내용 중 반절은 기존의 기능에 새로운 동작을 추가하는 등의 업무였는데
  일은 해왔으면서인지를 못하는 것이 너무 "코드 자체에만 집중해 온 것 아닌가?"라는 생각을 하게 되었습니다.
• "잘하는 개발자"는  "내가 작성한 코드는 이해하기도 쉽고 다양한 기능도 오류 없이 구현해" 같은 개발자를 생각해 온 것 같습니다.
  "가치를 계산하고 높일 수 있는 사람"에 대한 좋은 배움을 얻었습니다.

즉흥적으로 시도하지 마세요

무엇이 무엇과 결합되어 있는지에 대한 불완전하고 변화하는 정보를 가지고 작업을 하는 것은 위험합니다.
즉흥적으로 여러 요소에 대한 변경을 시도하지 마세요. p.137

• 코드를 정리하는 것은 동작을 변경하는 것이 아닙니다. 정리로 인해 다양한 내용이 급격히 변화한다면 혼란이 늘어나게 될 것입니다.
• 다음에 코드를 볼 사람을 위해 더 깔끔하게 코드를 정리할 수 있어야 합니다.
• 이 규칙을 지킨다면 시간이 지날수록 더 좋은 코드를 발견할 수 있게 됩니다.

 

주저리

이 책을 읽으며 든 생각은 "코드 정리"라는 것을 하라는 것 같긴 한데.. 였습니다.

저자의 주변엔 코드 정리를 광적으로 집착하는 분들이 많은지 "코드 정리를 하긴 해야 하는데... 좀 고려하고 해야 해"라는 뉘앙스의 내용입니다.

다만, 저부터 코드 정리를 제 때 하지 않기 때문에 저에겐 "Tidy First" 책 제목과 같이 먼저 해야 하는 마음 가짐을 만들어야겠습니다.

 

📦 공유 자료                                                    

• 켄트 벡의 Tidy First?: 더 나은 소프트웨어 설계를 위한 32가지 코드 정리법 | 켄트 벡 - 교보문고 (kyobobook.co.kr)