하나의 더미로 만든다는 것은 재개념화를 할 수 있는 기회이다

서비스를 만들며 성장하는 과정에서 코드를 읽고 이해하는데 드는 비용이 크다는 것은 공감이 됩니다. 결국 인간의 기억력의 한계를 보정하기 위한 활동이 필요하다고 받아들여 지기도 합니다.

코드를 만났는데, 가장 큰 비용이 들어가는 일은 코드 작성이 아니라 읽고 이해하는데 드는 비용입니다. - p.63

그리고 이번 장의 내용은 이미 TDD 에서 리팩토링이라는 주제로 메서드 인라인 이라는 것을 언급한 적이 있어 낯설지 않습니다. 이후 실무에서 적용해봤을 때 새로운 단위의 의미로 재구성할 수 있어 효용성이 있는 방법이라고 생각합니다.

길고 반복되는 인자argument 목록도 TDD 에서 언급된 내용이가 공감되는 부분이 있습니다.

동일한 인자들이 반복될 때는 함수단위로 나눌만한 것인지 의심을 해봐야 합니다.

Monolithic 와 MSA

‘여러 개의 작은 코드 조각’ 을 보고 ‘여러 개의 작은 서버’ 가 떠올랐습니다. ‘유지보수’ 관점에서 생각해 봤을 때, ‘유지’ 는 대체로 수월하지만, ‘보수’ 는 가끔 복잡할 때가 있었습니다. 특정 도메인의 트래픽 증가로 서버를 갑자기 증설해야 하는 경우 유연하게 대처할 수 있지만(=유지), 여러 도메인이 관여하는 기능 개선 및 확장 시(=보수)에는 제공하고자 하는 가치에 비해 작업 범위와 양이 많을 수 있습니다.

그렇다고 해서 MSA 가 부적절하다는 것은 아니지만, 서비스 규모에 따라 서버를 어떻게 설계할지(=위치시킴, 배치) 고민이 필요하며, MSA 를 맹신하지(=작은 코드 조각으로 분리하는 일) 않도록 조심 해야겠습니다. 과도가 예리하다고 해서 소를 잡는데 사용하지 않는 것 처럼, 어떤 특정한 기술이나 개념이 모든 경우에 해답이 될 수 없다고 다시 한 번 생각 했습니다.

리팩토링을 위한 안전장치

메서드를 추출하는 것도 그렇지만, 작은 코드 조각들을 한데 모을 때도 수정 전과 후에 같은 결과를 반환하는지 검증하는 과정이 필요하다고 생각 합니다. 그리고 코드 조각을 한데 모아 얻은 통찰을 바탕으로 재구성한 코드에 대한 확신은 테스트 코드로부터 얻을 수 있겠습니다. 설령 재구성한 결과 일부 예외 케이스에서 부작용이 발생 하더라도, 좋은 테스트 코드가 안전을 보장해 준다면 (=해당 케이스로의 진입이 없다) 서비스를 여전히 안정적으로 운영할 수 있습니다.

다시 말해, 이 길을 따라가면 고랑에 빠질 것이 뻔하지만, 그 길을 걷는 사람이 없다면 빠지는 사람도 없겠다는 심보 입니다.

조금은 공감 안되는 부분이 있는 챕터

코드가 잘게 나누어 있다면 이해가 어렵다는 것도 공감 가는 부분이 있지만
이것이 코드가 잘게 나누어져 있어서라기보단, 적절치 못하게 나누어진 게 문제가 아닌가 합니다.
이런 현상은 코드의 변화에 맞춰 분할된 내용들이 적절하게 변경되거나 재분할되지 못할 때 자주 보이는듯합니다.

이해를 하는 방법에 따라 추상화 레벨에 따라 분할된 문맥의 메서드들이 이해하기에 쉬울 수 있고, 코드 자체를 해석하는 게 쉬울 수도 있다고 생각이 듭니다.
그럼 후자의 사람은 이해도를 높이기 위해 메서드를 합치는 정리를 해야 할까요?
(너무 답이 없는 질문이긴 하네요. 모든 맥락에서 답을 못내는 질문이겠죠!)

저라면 이해도를 높이기 위한 정리의 일환으로 코드를 다시 모으겠다는 선택은 공감하기 어려울 것 같습니다. (모은 것을 커밋 하여 반영한다는 의미)
다만 코드를 모아서 이해를 하여 어떻게 재분할되어야 할지 이해한 뒤, 재분할을 완료한 변경은 공감할 수 있을 것 같습니다.

정리해보자면, 이런 종류의 Tidying은 중간을 과정에서 제품에 반영 되기 어렵다고 생각 되고, 이런면에서 아기 발걸으로 적용하기 어려운 정리 방법이 아닌가 싶습니다.

설계에 관심을 갖고 코드를 구조화해서 만들려고 노력하다보니, 어느순간부터 습관처럼 코드를 나누어 만들기 시작했습니다. 저만의 어떤 규칙이 생겼는지 거침없이 나눕니다.
근데 최근에 문득 이런 생각이 들었습니다. 지금 불필요하게 분리하고 있는 건 아닐까? 이 스텝에 어울리는 분리가 맞나? 그리고 이렇게 분리하는게 맞긴 한가?
최근에는 근거를 찾으려고 합니다. 근거를 찾기 전까지는 하나의 더미로 두려고 합니다. (물론 진흙잡탕을 만든다는 것은 아니고, 굳이 여러개의 책임으로 분할하지 않는다는 뜻!!)

모아서 문제 이해하기

때로는 코드가 여러 개의 작은 조작으로 나뉘어져 있기도 합니다. 이렇게 흩어져 있으면 코드를 전체적으로 이해하기 어렵습니다. 필요한 만큼의 코드를 하나의 더미처럼 느껴질 때까지 흩어진 코드를 모으세요. 그러고 나서 깔끔하게 정리하세요.

TDD를 학습할 때 테스트 코드르 먼저 작성하는 충격과 비슷한 느낌입니다. 나누라는 말은 자주 들었어도 모으라는 말은 생경하기만 합니다.

작은 코드 조각을 지향하는 목적은 코드를 한 번에 조금씩 이해할 수 있도록 하는 것입니다. 하지만 때때로 이 과정이 잘못될 수 있습니다. 작은 코드 조각들이 서로 교류하는 방식은 코드를 더 알기 어렵게 합니다. 명확성을 되찾으려면, 먼저 코드를 한데 모아서 이해하기 어려운 부분을 추출해서 새롭게 정리해야 합니다.

일전에 복잡한 업무 코드를 빠르게 분석하기 글의 경험이 떠오릅니다.
크고 복잡한 코드를 이해하기 위해 모아서 문제를 이해했던 장면이었습니다.

최근 이벤트 소싱을 적용하면서 이벤트 소싱 코드 인프라가 흩어져 있어 불편함을 느끼던 와중이었는데 켄트 벡의 말처럼 일단 한데 모아서 정리를 해보아야겠습니다.