얽혀있는 실타래를 풀어가며 실뜨기를 하자

코드 정리를 하며 동작 변경을 수행할 때, 동작 변경을 하고 나니 더 좋은 코드 정리 방법이 떠올랐습니다.

이번 장에서는 이럴 때 어떻게 해야 하는지 말해 줍니다.

켄트 벡은 다시 처음부터 코드 정리를 하고 동작 변경을 하라고 조언을 합니다.

그 이유로는 개발자가 해야 하는 것이 컴퓨터에 지시만 하는 빠른 수행이 최종 목표가 아니고 개발자 의도를 다른 사람에게 설명 하는 것이 포함되어 있기 때문이라고 말합니다.

이는 켄트 벡이 XP 에서 말한 설계 시점을 우리가 가장 잘 선택 할 수 있는 시점까지 최대한 미루라고 말하는 것과 연결됩니다. 왜냐하면 그때가 가장 잘 설계 할 수 있어 설계 비용을 줄일 수 있기 때문입니다.

그리고 TDD 에서 했던 다시 구현하기를 말한다고도 느껴졌습니다. 다시 구현하기가 가지는 가치는 처음 구현을 해 보면서 깨달은 지식으로 두 번째 구현을 하게 되면 보다 나은 설계와 구현을 할 가능성이 높아지기 때문입니다.

그리고 문득 작고 반복적인 리팩토링이 가지는 힘을 느끼게 된 것 같은 생각이 듭니다. 그것은 바로 실타래를 풀어야 할 타이밍을 놓치지 않게 된다는 것입니다.

가령 실무에서 동작 변경에만 중점을 두다 보면 앞서 켄트 벡이 말한 컴퓨터에 지시만 하는 빠른 수행이 최종 목표가 되고 리팩토링은 기술 부채로 전이되게 됩니다.

하지만 코드 정리를 수행하게 되면 변경 요구가 많은 도메인이 지속적으로 리팩토링 되면서 개발자와 의사결정권자간 난감한 상황이 빚어질 확률이 낮아질 것이 라고 생각합니다.

지금까지의 내용을 제목인 얽힘 풀기와 연결해서 정리해보면 실타래가 얽혀 있다는 것을 인지했고 더 좋은 방식으로 풀 수 있다는 확신이 들었다면 그것을 행동하는 것이 가장 실타래를 잘 그리고 빠르게 풀어 나가는 방법입니다.

어깨 넓이로 나란히 걷기

혼자 했다면 하지 않았을 고민이라는 생각을 했습니다. 물론 코드 정리와 동작 변경이 섞여 있는 PR 에 대해 무례함을 느끼는 부분에 대해서 입니다.

개인적으로 잡화점을 여러바퀴 돌며 구경하는 것을 좋아 합니다. 분명 방금 보고 지나갔는데, 다시 보니 처음 보는 것들이 생기는 것이 꽤나 재미있기 때문입니다. 애플리케이션을 개발할 때도 잘 알고 있다고 생각한 코드임에도 변경 과정 (또는 디버깅 과정)에서 보다 깊이 있는 이해를 할 수 있고, 본문에서 말하는 새로운 발견을 하게 되는 경우가 많이 있었습니다. 문제는 ‘세 번째 선택지를 자유롭게 선택할 수 있는 여유가 주어지느냐’ 라고 생각 했습니다.

고민 끝에 확실하다고 생각하는 큰 걸음을 내딛을 것인지, 당장 눈에 보이는 확신의 종종 걸음으로 얻은 피드백을 통해 나아갈 것인지 선택해야 한다면, 깊이 고민하지 말고 어깨 넓이 만큼 내딛는 게 좋겠다는 생각을 했습니다.

마지막으로 다른 누군가와 함께 한다는 것은 쉽지 않은 일이라는 것을 다시 한 번 생각 했습니다.

코드는 의도를 사람들에게 설명해야 한다

우리가 작성하는 코드는 컴퓨터에 지시할 뿐 아니라, 컴퓨터에 지시하려는 여려분의 의도를 사람들에게도 설명해야 하기 때문이죠. 컴퓨터에 지시만 하는 빠른 수행이 흥미로운 최종 목표가 되는 것은 아닙니다.

얼마 전에 인지 했던 JSON5 존재가 떠오르네요. 그들에 내세우는 비전은 아래와 같습니다.

JSON5 – JSON for Humans

버리고 다시 구현하며 새로운 것을 발견하기

이쯤 되면 세 번째 선택지를 실험해 보라고 권하는 것이 그리 놀랍지 않을 것입니다. 다시 구현하면서 새로운 것을 발견할 가능성이 높아집니다. 그리고 동일한 동작 변경을 하면서도 더 많은 가치를 끌어낼 수도 있습니다.

역시 XP를 만든 사람이구나라고 느낍니다. 켄트 벡은 XP에서 '실패' 원칙에서 아래와 같이 말했습니다.

어떤 스토리를 구현하는 세 가지 방법 중 어떤 것을 선택해야 할지 모르겠는가? 셋 다 해보라. 세 모두 실패하더라도, 분명 귀중한 교훈을 얻을 수 있다.
실패는 자원의 허비가 아닌가? 실패가 지식을 늘려주는 한, 그것은 허비가 아니다. - XP

저는 19장 댓글에서도 다시 만드는 것의 가치를 언급했습니다.
일전에 디스코드에 공유했던 글에는 그러한 가치를 인식하는 CTO의 글에 내용에 잘 나와 있습니다.
https://news.hada.io/topic?id=16383

하루를 시작할 때 기능 작업을 시작. 하루가 끝날 때까지 완료하지 못하면 모두 삭제하고 다음 날 다시 시작. 작성한 단위 테스트는 유지 가능.
"모든 것을 두 번 작성" "매일 다시 시작" 방법은 이보다 더 극단적. 재작성할 때마다 더 매끄러운 해결책을 찾게 됨.

변화의 시작은 인식입니다. 그래서 자주 멈춰서 질문해야 합니다.

실타래를 풀려면 실이 엉켜 있다는 사실을 알아차려야 시작할 수 있습니다. 따라서 실타래를 풀어야 할 필요성을 더 일찍 깨달을수록 작업량은 적어질 것입니다.

실타래를 풀려며 실이 엉켜있다는 사실을 알아야 한다

이번장에서 가장 마음에 와닿는 문장인 것 같습니다. 엉켜있다는 사실을 빨리 알 수록 효율적인 선택을 할 수 있지만, 과연 변경이 일어나기 전에 엉켜있다는 사실을 알아차리기 위해 우리가 얼마나 대상을 잘 이해하고 있어야 할지 걱정입니다.

어쩌면 위에서 언급한 효율을 찾기 위해, 개발전에 모든 변경 대상들을 시뮬레이션 하며 리소스를 더 많이 쓰는 우를 범할 수도 있을 것 같습니다. 차라리 어떤 경우엔 빠르게 시도하고, 알아차리고 다시 만드는 것이 더 큰 가치일 수도 있겠습니다. 다시 만듦이 주는 가치가 존재하기 때문입니다.

요즘 부쩍 일에 지치는 것 같습니다. 자기수련과 좋은 코드 개발을 위해, 이런 저런 개발 방법들을 배우지만, 가끔은 이런 가치를 알아주지 않는 일 이라는 것에 이런 노력을 해야 할지 많은 의구심이 듭니다. 많이 지친것 같습니다.