개인 스터디로 리팩터링 2편에 대한 정리를 하려고 한다.
사실 매번 읽어야지 했던 책이였는데 1년차 개발자로써 생존을 우선시 하다보니 여유가 있지 않았던 것 같다. 무지성 업무 이슈처리하는데도 쉽지 않았다ㅋㅎ..
이제 최대한 개인시간을 활용해서 스터디 내용을 정리해보려고 한다.
과하지 않고 차분하게 내가 읽고 느낀 점을 정리하는 글이 됐으면 좋겠다. 매번 기억하기만 하려고 했던 습관을 버리고 기록하는 습관을 들여보자.

첫 번째 예시를 읽으며

첫 리팩터링의 예시로 비디오 대여점에서 영수증을 출력하는 프로그램을 소개한다.
연극 정보에 대한 JSON 객체를 받아 청구 내역과 총액 및 적립 포인트 등을 반환하는 함수를 리팩터링하는 과정을 보여준다.

무엇을 수정할지 찾기 어렵다면 실수를 저질러서 버그가 생길 가능성도 높아진다.
프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링하고 나서 원하는 기능을 추가한다.

사실 1년간 현재 프로젝트의 레거시 코드(MVC dotnet Razor Pages + Angularjs)를 보면서 어려웠던 부분이 이 말이였던 것 같다. 무엇을 수정할지 찾기 어려운 코드가 많았고, 그에 따른 버그의 잠재성 또한 높았던 것 같다.
현재 해당 프로젝트를 리액트와 nx를 활용한 모노레포(RN앱과 정적페이지들을 먼저 리액트로 옮겼던 v2프로젝트까지 한 레포에서 관리하고 공용으로 사용할 로직이 많다고 판단했다)로 마이그레이션을 진행하고 있기 때문에 좀 더 프로젝트가 아토믹하고 SOLID해진 부분이 생겨서 해당 리팩터링 개념을 적용하기 용이할 것 같다는 생각이 들었다.

꼼꼼하게 검사해줄 테스트 코드들부터 마련해야 한다. 리팩터링하기 전에 제대로 된 테스트부터 마련한다. 테스트는 반드시 자가진단하도록 만든다.

Jest나 cypress와 같은 테스트코드를 얘기하는 것보단 해당 글에서의 얘기로는 그냥 static하게 함수 자체를 테스트할 수 있는 여러가지 테스트 케이스를 마련하여 함수를 테스트해보라는 의미인 것 같다.

아무리 간단한 수정이라도 리팩터링 후에는 항상 테스트하는 습관을 들이는 것이 바람직하다.
리팩터링은 프로그램 수정을 작은 단계로 나눠 진행한다. 실수하더라도 버그를 쉽게 찾을 수 있다.
하나의 리팩터링을 문제없이 끝낼 때마다 커밋한다.

책의 특정 코드를 설명한 부분부분마다 테스트에 대한 강조를 한다. (컴파일 - 테스트 - 커밋) 이라는 글을 거의 매 단락마다 확인할 수 있다.

컴퓨터가 이해하는 코드는 바보도 작성할 수 있다. 사람이 이해해도록 작성하는 프로그래머가 진정한 실력자다.

나도 이렇게 코드를 작성한 적이 많지 않나에 대한 회고를 하게 했던 문구였다. 우리는 개인 프로젝트가 아닌 협업을 하고 있기에 아주 중요하게 생각해야하는 부분이지 않나 생각한다.

변수 인라인 등의 처리도 생각보다 중요시하게 생각하고 있어 내가 평소에 생각했던 리팩터링의 단계보다 훨씬 더 꼼꼼하고 세세하게 쪼갠다는 느낌을 받았다.

긴 함수를 작게 쪼개는 리팩터링은 이름을 잘 지어야만 효과가 있다. 이름이 좋으면 함수 본문을 읽지 않고도 무슨 일을 하는지 알 수 있다.

사실 이건 현재 현업에서 일하면서 우리 팀 내에서도 가장 강조하는 부분이기도 하다. 변수명에서 함수명으로 최대한 파악이 가능하도록 축약어를 사용하고 있지 않고, 주석을 꼭 포함시키기로 했다. v1에서 주석이 너무 없어서 초기 입사했던 당시 개발자 모두가 힘들어했다. 난 정말 그때 사수도 없어서 너무 힘들었다. 내가 여태 개발을 잘못배웠다라고 생각했을 정도로...

때로는 리팩터링이 성능에 상단한 영향을 주기도 한다. 그런 경우라도 나는 개의치 않고 리팩터링한다. 잘 다듬어진 코드라야 성능 개선 작업도 훨씬 수월하기 때문이다.

개인적으로 좀 신기했던 부분이기도 하고 한편으로 의심도 있었지만 오히려 이렇게 좋은 책에서 깔끔명료하게 정리해주니 오히려 더 개운했다. 사실 생각해보면 당연한 것 같기도 하다. 결론은 리팩터링이 먼저다. 성능을 나중에 잡으면 된다.

캠핑자들에게는 "도착했을 때보다 깕끔하게 정돈하고 떠난다"는 규칙이 있다. 프로그래밍도 마찬가지다. 항시 코드베이스를 작업 시작 전보다 건강하게(healty) 만들어놓고 떠나야 한다.

코드를 건강하게 만들어놓고 떠나야 한다라는 표현을 했다. 위와 같은 고민이 없는 코드들은 프로젝트의 암같은 존재이지 않을까라는 생각으로 건강한 코드를 짜야한다는 책임감과 압박감을 책 초반부터 보여주는 것 같다.

마치며

• 리팩터링은 대부분 코드가 하는 일을 파악하는 데서 시작한다.
• 코드를 수정해야 할 상활이 되면 고쳐야 할 곳을 쉽게 찾을 수 있고 오류 없이 빠르게 수정할 수 있어야 한다.
• 프로그래밍 팀의 현재와 이상의 차이에 항상 신경 쓰면서, 이상에 가까워지도록 리팩터링한다.

코드의 모든 부분들을 기재하고 정리하는 목적의 글이 아니기 때문에 책을 모두 정리하진 않지만 중요하다고 생각되는 부분들과 느낀점들을 기록하기 위한 글이기에 마치며 내 생각도 정리해두는 것이 좋겠다.

우선 해당 챕터의 대한 느낀 점 부분만 생각한다면

• 다형성? 이라는 개념이 아직 명료하지 않아 더 공부가 필요하다.
• 함수 하나에 굳이 class까지 정의해서 리팩터링을 한다는 것이 대단하다고 생각했다.

1년간 개발을 하면서 느낀 점은 개발자는 기획자나 대표나 디자이너가 만든 프로덕트를 만들어주는 것에 가장 큰 목표를 갖는다고 생각한다.
나 포함 많은 개발자들이 개발의 이상을 꿈꾸며 회사가 원하는 프로덕트를 만들어내지 못할 때가 있다고 생각하고 결국 개발자의 가장 큰 목표이자 추구해야하는 부분은 완성도 있는 프로덕트를 잘 개발해주는 것에 있다고 생각한다.
이 챕터에서 얘기한 것처럼 최대한 이상에 가깝게 노력하되 정해진 시간 안에 완성도 있는 프로덕트를 만들기 위해 리팩터링이 중요한 것이 아닐까라는 생각이 들었다.