리팩토링&코드정리 방향성에 대한 고찰

 

각종 아키텍처 관련 책을 읽고 tidy first란 책을 읽는 와중에,

어떤 분께서 리팩토링의 방향성에 대해 고민하고 있다는 이야기를 들었습니다. 

 

그래서 한번 고민해봤습니다. 

 

리팩토링과 코드정리의 정의를 엄격하게 구분한다면 따로 다뤄야 할 것 같은데,

저는 리팩토링과 코드정리를 `동작 변경이 없는, 코드를 정리하는 행위`라는 공통점으로 함께 다루었습니다.

 

리팩토링을 왜 했는가?

 

저는 습관적으로 리팩토링을 해왔던 것 같습니다.

보이 스카우트 규칙(떠날 때는 찾을 때 보다 캠프장을 더욱 깨끗이 하라)을 열심히 지키고자, 개발을 할 때 무언가 눈에 거슬리는 게 있으면 함께 고쳐왔습니다.

 

일단 제가 한 리팩토링은,

눈에 거슬리는 지저분한 코드를 보자마자 고치는, 무지성 리팩토링(코드 정리)였습니다. 

 

그래서 얻은 게 무엇이냐?

물론 일부 코드가 깔끔해지긴 했습니다.

 

하지만, 

- 하나의 PR에 변경과 정리가 섞여 꽤 거대해졌습니다. (저도 이런 PR을 종종 만나는데 리뷰할 엄두가 나지 않습니다.)

- 커밋 제목과 메세지가 모호해졌습니다.

- 마구잡이로 정리를 하다보니 걷잡을 수 없는 상태가 되었고 야근을 한 적이 있습니다. 

- 테스트 범위가 넓어져서 배포가 밀렸던 적이 있습니다. 

- 비즈니스를 잘 모르고 눈에 보이는 거슬리는 것을 변경하였기 때문에 앞으로도 변경될 여지가 없는 코드를 고쳤습니다. (기분은 좋았다만, 결과적으로 리소스 낭비를 했습니다.)

- 한꺼번에 너무 많은 코드를 정리해서 타 구성원의 변경사항과 머지할 때 conflict가 발생했습니다.

... 등등 부족했던 점을 나열하자면 끝이 없을 것 같습니다. 

 

그럼 이제 어떻게 할 것이냐? 어떻게 해야한다고 생각하느냐? 

 

tidy first, Part2요약에 코드 정리 시점에 대한 가이드가 있고 공감되는 것들을 가져왔습니다. 

다음 상황에서는 코드를 정리하지 마세요.
* 앞으로 다시는 코드를 변경하지 않을 때
* 설계를 개선하더라도 배울 것이 없을 때

다음 상황에서는 나중으로 정리를 미루세요.
* 정리할 코드 분량이 많은데, 보상이 바로 보이지 않을 때
* 코드 정리에 대한 보상이 잠재적일 때

다음 상황에서는 코드 정리 후에 동작 변경을 하세요.
* 코드를 정리했을 때 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있을 때
* 어떤 코드를 어떻게 정리해야 하는지 알고 있을 때

다음과 같을 때 코드 정리를 하는 것이 이상적이라고 할 수 있습니다.
코드 정리 비용 + 동작 변경 비용 < 동작 변경 비용

 

위 내용을 참고하여 저의 생각을 정리해보았습니다. 

 

`코드 정리는 아무 코드나 눈에 거슬린다고 정리하는 것이 아니라

지금 내가 하고 있는 일 범위의 코드 내에서, 리팩토링(코드정리)이 당장의 일에 도움이 되는가, 혹은 다음에 할 일에 대한 긍정적인 옵션을 늘려주는가? 를 묻고 시작해야 한다.`

`위의 질문에 '그렇다'고 답변할 수 있다면, 코드정리 또는 리팩토링을 해도 되는 상태이다.`

 

다만 할 때는 다음과 같은 방식으로 접근하는 것이 좋을 것 같습니다. 

* 정리할 범위를 인지하고 시작

* 구성원(리뷰어)이 보았을 때 압도당하지 않고 바로 리뷰할 수 있을 만큼의 작은 단위로

    * tips. 이모지 혹은 구성원간 규칙으로 구조와 변경 분리해서 PR 제목 작성

* 비슷한 맥락의 정리를 함께 수행 (ex. 패키지 변경, 네이밍 변경 등 모아서 각각 다른 PR로)

* 정리한 코드는 최대한 빨리 prod에 반영

 

지극히 주관적인 코드 정리 플로우차트를 만들어보았습니다🤣