‘Tidy First? A Personal Exercise in Empirical Software Design’ 책에 대한 인상
Source: Dev.to
소개
무엇보다도, 우리 분야에서 잘 알려진 인물이자 책 저자가 매일 모든 사람이 추구하는 것은 아닌 주제—코드 품질—에 대한 새 책을 쓰는 것을 보는 것은 기쁩니다. 이 책은 Refactoring(Fowler, 1판, 1999)과 Clean Code(Robert Martin, 2008)와 같은 다른 기념비적인 작품들 이후 수년 뒤에 등장합니다. 따라서 책이 완전히 새로운 영역을 여는 것은 아니지만, (CQSE에서) 우리가 하는 것처럼 작은 규모의 코드 품질을 확대경으로 들여다볼 동기를 실무자들에게 보여줍니다.
이 글은 책에서 발견한 두 가지 가장 흥미로운 차원을 기준으로 두 부분으로 나누었습니다.
- Part I – 우리가 (CQSE에서) 매일 칭찬하는 것과 직접적으로 관련된 핵심 포인트: 개발자들의 삶을 더 쉽게 만드는 작은 움직임.
- Part II – Kent가 제공하는 시간적·경제적 관점. 제목 *Tidy First?*의 “First?” 부분은 내용이 무엇을 의미하는지 힌트를 줍니다 – 코드를 정리하기에 적절한 시점은 언제일까? 먼저 정리할까? 행동 변화를 위한 수정 전에? 바로 직후에? 나중에? 아니면 전혀 안 할까?
Part I – The Foundation: Small Moves that Make Developers’ Lives Easier
“tidying”란 무엇인가?
“tidying”가 “refactoring”과 다른지 궁금하다면, 명확히 해두자. 이 책은 tidying를 작고 사소한 리팩토링이라고 정의한다. 리팩토링은 동작을 변경하지 않는 구조적 변화로 정의되지만, tidyings는 다음과 같다:
“아무도 싫어할 수 없는 귀엽고, 흐릿하고, 작은 리팩토링들.”
Kent는 또한 이렇게 관찰한다:
“‘Refactoring’은 사람들이 기능 개발의 긴 지연을 가리키는 데 사용하면서 치명적인 손상을 입었다. 그들은 ‘동작을 바꾸지 않는다’는 조항까지 없애 버려서, 리팩토링이 시스템을 쉽게 깨뜨릴 수 있게 되었다.”
실제로 나는 사람들이 리팩토링을 다양한 방식으로 부르는 것을 들어봤으며, 이는 Kent의 관찰과 일치한다. 그래서, 그것이 붙든 안 붙든, 우리는 또 다른 용어—Tidying—와 함께한다.
책에 제시된 Tidying들
Kent는 이를 깊게 탐구하지 않는다; 일부 항목은 반 페이지에 불과하지만, 새로운 내용이 아니기 때문에 괜찮다.
- Guard Clauses
- Dead Code
- Move Declaration and Initialization Together
- Explaining Variables
- Explaining Constants
- Explicit Parameters
- Chunk Statements
- Extract Helper
- One Pile
- Explaining Comments
- Delete Redundant Comments
새로운 내용은 아니지만, Kent가 이들에 별도를 두는 데는 좋은 이유가 있다:
- 책을 자체적으로 완결하게 만든다.
- 저자가 말하는 “귀엽고, 흐릿하고, 작은 리팩토링”이 무엇인지 구체적으로 보여준다, 단순히 Fowler나 Martin의 작업을 인용하는 것이 아니다.
듀오: Coupling‑and‑Cohesion
Coupling‑and‑Cohesion이 핵심이다
Kent는 Ed Yourdon과 Larry Constantine의 작업을 여러 차례 언급한다. Yourdon & Constantine은 1970년대에 소프트웨어 설계에서 결합도와 응집도의 개념을 정립했다.
Cohesion와 Coupling은 복잡한 시스템을 다룰 때 뇌가 실제로 작동하는 방식이다.
Cohesion Order (그리고 결합을 풀어야 할지)
- 코드 곳곳에 흩어져 있는 변경을 피하는 것이 목표다.
- 변경이 필요한 코드 요소들을 인접하게 재배열한다(같은 소스 파일 안뿐 아니라 서로 다른 파일·폴더 간에도).
왜 그 흩어진 변경을 일으키는 결합을 그냥 없애버리지 않을까?
방법을 알고 실행할 수 있다면, 바로 해라!
하지만 비용 관계를 주의하라:
cost(decoupling) + cost(change) // Constantine’s Equivalence
// cost(software) ≈ cost(change)*cost(change)*는 멱법칙 분포를 따른다: 몇몇 매우 높은 비용의 변경이 전체 비용을 지배한다. 다시 말해:
“가장 비용이 많이 드는 행동 변화들이 전체 비용의 대부분을 차지한다(가장 저렴한 변화들을 모두 합친 것보다 훨씬 많다).”
수식으로는:
cost(change) ≈ cost(big changes)그 큰 변화가 왜 그렇게 비싼가? 일반적으로 단일 응집 요소에 국한되지 않고, 여러 고결합 지점에 퍼지기 때문이다. 이것이 핵심 통찰로 돌아온다:
높은 결합도 → 높은 변경 비용.
cost(software) ≈ cost(change) ≈ cost(big changes) ≈ coupling또는 간단히:
cost(software) ≈ coupling하지만 결합을 풀어내는 데에도 자체 비용이 있다(그리고 물론 어떤 소프트웨어든 어느 정도 결합은 존재한다). 어떤 트레이드‑오프가 있을까? 이는 책의 두 번째 차원, 즉 tidying(또는 decoupling)의 적절한 시점에 관한 것이며, 아예 해야 하는지 여부와도 연결된다.
요약하면, 지금 결합 비용을 지불하고 곧 이익을 얻을 가능성이 있는지, 혹은 결합 해제 비용을 지금 지불하고 나중에 그 혜택을 얻을 가치가 있는지에 달려 있다(비록 그 혜택이 나중에 도착한다 하더라도).
그 모든 내용을 Part II에서 확장하자.