코드 정리는 연쇄적으로 일어난다

1부 코드 정리법의 작은 실천법들을 켄트 백의 경험으로 느낀 관계를 알려줌으로써 자연스러운 다음 단계를 알려주려는 것 같습니다.

이를 외워서 의도적인 지식으로 활용할 수 있겠지만 가장 좋은 방법은 직접 코드 정리를 해봄으로써 나의 경험으로 만들어가는 것이라고 생각합니다.

일단 정리할 코드가 없으니 의도적으로 지식화를 합니다.

그리고 막바지에 개발자가 가져야할 태도를 말해주는 것 같은 느낌을 가집니다.

소프트웨어 개발에서 변경은 가장 많은 비용이 들어갑니다. 변경 중에서도 코드를 이해하는 일에 가장 비용이 많이 들어갑니다. 따라서, 작동하는 코드의 구조와 의도에 대해 잘 소통하는 것이야말로 여러분이 익혀야 할 가장 가치 있는 기술입니다.

의도를 소통해야한다는 것입니다. 조금 더 쉽게 풀어보면 코드를 읽다가 ‘왜 이렇게 구현했을까?‘ 를 알아가야 한다는 것입니다.

그리고 의도를 알아야 확신을 가지고 보다 빠르게 변경할 수 있습니다.

코드 정리는 인간적으로

챕터 16 ‘코드 정리 구분’ 에서 ‘변경은 변경을 낳는다.’ 라고 언급한 부분이 있었습니다. 여기서는 변경의 결과로 새롭게 변경 할 부분이 도출 된 상황이었다면, 이번에는 개인의 욕망에 의한 연쇄적인 변경을 얘기 하며 충동을 억제할 수 있어야 한다고 얘기 합니다.

이번 챕터에서는 앞서 다룬 구체적인 코드 정리 실천 방법들에 대해 다시 한 번 언급하고 있습니다. 각각의 구체적인 방법에 대해서도 되뇌는 시간을 가질 수 있었는데, ‘그래서 이런 것들을 왜 해야하는가?’ 의문을 가지게 되었습니다.

코드를 정리하는 이유 중에는 ‘미래의 변화에 유연하게 대응하기 위함’ 이라는 것을 부정할 수 없을 것입니다. 변화에 유연하게 대응할 수 있다는 것은, 작성 된 코드를 어렵지 않게 이해할 수 있음이 전제 되어야 합니다. 무엇을 하는 코드인지 이해하지 못한 상태에서 리팩토링은 수많은 부작용을 가져올 수 있기 때문입니다.

코드를 어렵지 않게 이해할 수 있다는 것은, 코드가 드러내는 의도가 명확하게 보인다는 것을 뜻합니다. 코드의 의도를 명확하게 드러내기 위해서는 코드를 작성하는 사람의 배려가 필요 합니다. 같은 일을 하는 코드라 할지라도 잘 쓰여진 소설 한 편을 읽듯 술술 읽히게 코드를 작성하는 사람이 있는 반면, ‘동작만 하면 되지’ 라는 생각으로 ‘당시 작성자의 기반 지식을 모두가 알고 있다고 가정하고’ 코드를 작성 하는 사람도 있기 때문입니다.

미래의 변화에 유연하게 대응하기 위함의 연장선에서, 변화의 중심에 놓인 미래의 동료를 생각하고 사려 깊게 작성한 코드는 인간성을 담았다고 생각 합니다. 그런 관점에서 tidy first 에서 안내하는 코드 정리 기법들은 소프트웨어를 아프지 않게 유지하기 위한 최소한의 인간적인 행동 양식들을 정리 했다고 느꼈습니다. 다시 말해, 각자 살아온 시간이 달라 생각하는 인간성의 기준이 다르지만, 켄트 벡이 이 책을 통해 전달하는 구체적인 실천 방법들을 하나의 지침으로 참고하여 실천 한다면, 최소한의 인간성을 담은 소프트웨어 설계를 할 수 있다고 말하는 듯 했습니다.

하지만 가장 중요한 것은, 이 모든 실천 방법들을 강제하는 것은 아니며 모든 경우에 대한 정답이 아니라는 것을 염두에 둬야 합니다. 대부분의 경우 책에서 말하는 가이드가 올바른 방향을 제시 하지만, 상황에 맞춰 합의가 이뤄져야 겠습니다.

저는 17장에 나온 지침이 매우 기본적인 내용이라고 생각합니다. tidy first뿐만 아니라 다른 책에서도 많이 소개된 내용입니다. 매우 잘 알려져있고 기본적이지만 이것만 따라해도 꽤나 좋은 코드가 나온다고 생각합니다.

그러기에 이것과 어긋나는 방식을 굳이 프로젝트에서 채택할 필요가 없다고 생각합니다. 누가 봐도 좋다는 방식이 이미 나와있고, 웬만한 사람들은 체득되어 있을 테니까요.

근데 굳이 이와 벗어나는 규칙을 만들거나, 아니면 이런 지침을 들이는데도 '시간을 들여서 하는 합의의 영역'으로 들어가야 한다면 좀 피곤해지는 것 같습니다.

좋은 소프트웨어 개발 습관

단계의 크기는 본인이 알아서 하겠지만, 제가 권하는 것은 아주 작은 단계로 나누어 코드를 정리하는 방식을 고수하면서 실험해 보는 것입니다.

좋은 소프트웨어 개발 습관 이라는 글이 떠오르네요.

코드 정리는 반나절도 크다

저는 일을 반나절 정도로 나누어 하는 습관을 가지고 있습니다.

얼마 전에 코드 정리가 필요할 듯 하여 브랜치를 만들었습니다.
반나절 정도 시간을 소진할 생각이었습니다.

우선 코드 정리를 검증할 테스트 코드를 만들었습니다.
테스트 코드를 만들다 보니 테스트가 되지 않는 코드들이 보였습니다.
테스트 되지 않는 코드에 대한 테스트 코드를 만들었습니다.
코드를 돌리다보니 테스트 코드 인프라가 마음에 들지 않더군요.
코드 정리를 합니다.
....
반나절의 시간이 지나고 나서 결과물을 보니 머지하기에 너무 큰 코드라는 사실 깨달았습니다.

Live Kent Beck's holy words of wisdom: "for each desired change, make the change easy (warning: this may be hard), then make the easy change". Aim for at least half of all commits to be refactorings. Continuous refactoring is thinking of changes I can make in under 10 minutes that improve something. Doing this pays off whenever a bigger requirement comes in and you find yourself making a small change to satisfy it only because of those smaller improvements. Big refactorings are a bad idea. - https://zarar.dev/good-software-development-habits/

앞으로 코드 정리는 10분 단위로 끊어서 해봐야겠습니다.

너무 많지 않게, 너무 빠르지 않게

연쇄적인 정리라는 이름이 너무 와닿습니다.
무언가 하나를 고침으로서 더 많은 선택지를 얻게 되고 그것을 고침으로서 또 다른 선택지들이 생깁니다.

이런 방식으로 정리를 하다 보면 크기는 커지고 되돌아가기 어려운 곳까지 가버리는 경우도 많습니다.
켄트백은 이런 것을 지양하고 작은 단계로 실험해 보며 각 단계를 최적화해보라고 합니다.
크게 실패하는 것을 겪지 않을 수 있도록 가이드 해줍니다.
다만 아직은 다음 수를 내다본다는 것이 와닿지는 않습니다.

코드 정리 기법들 중 '명시적인 매개변수'의 내용 중 공감 되는 것이 있습니다.
바로 '강력한 추상화는 대체로 실행 중인 코드에서 발견하게 되기 때문이죠'라는 말입니다.

코드 정리를 하다보면 코드간에 연관관계의 패턴이 나오는 경우들이 있습니다.
이런 것들은 추상화 하기에 적합한 단위가 되었던 경험들이 많습니다.

꼭 '명시적인 매개변수'를 정리하는 과정에서만 나오는건 아닌 것 같습니다.
가독성을 높이도록 코드 정리들을 수행하다 보면 이런 경험들을 많이 하게 됩니다.

코드 정리에는 강도도 있는 것 같습니다.
코드의 호출 순서를 바꾸는 것, 클래스 내에서 위치를 바꿔 모으고 도우미 함수로 추출하는 것은 강도가 약합니다.
반면 새로운 클래스로 분리해내고, 새로운 패턴으로 관계를 구성하는 것은 강도가 강합니다.

강도가 강하면 되돌리기 어렵습니다.
켄트백이 주장한 것과 다르고 섣불리 수행하기 어렵습니다.

강도가 약해도 문제입니다.
정리의 연쇄가 멈추질 않습니다.
조금만 더, 조금만 더 하면서 켄트백의 주장과 다른길을 걷게 됩니다.

코드 정리의 연쇄성은 참 어려운 개념입니다.