리팩터링(3) - 하다보니 보이는 것들

지난 글에 이어 리팩터링을 하다보니 보이는 것들에 대해 작성해보겠습니다.

리팩터링은 단순히 코드의 개선을 의미하지 않습니다. 코드가 개선되는 만큼 리팩터링한 개발자의 성장, 팀원의 성장으로 이어집니다. 제가 리팩터링하면서 볼 수 있었던 모든 성장, 개선에 대해 설명해보겠습니다.

리팩터링한 개발자의 성장

앞선 글들을 보았다면 리팩터링을 하기 위해 많은 과정을 거치는 것을 알 수 있을텐데요.

그 과정을 거치다보면 자연스럽게 타인이 작성한 코드를 이해하는 능력이 길러집니다. 물론 매 PR마다 코드리뷰를 진행하지만 코드 리뷰를 하는 것과 직접 팀원이 개발한 코드를 사용하는 것은 정말 다른 일입니다.

리팩터링 이전 코드의 최초 PR

위 PR의 64개의 comment 중 절반 이상을 제가 달았음에도 막상 직접 사용하려 할 때는 이 코드를 작성한 팀원에게 많이 물어보며 코드를 작성했습니다. 하지만 리팩터링을 계획하는 과정에서 팀원이 코드를 작성한 정확한 의도를 이해하고 조금 더 개선할 수 있겠다는 발전적인 사고를 할 수 있었습니다.

 

하지만 이 때 중요한 부분이 있는데요. 바로 레거시라는 단어를 꺼내지 않는 것입니다. 제 기준 레거시라는 말은 부정적인 의미가 많이 담겨있는 듯 합니다. 만약 제 팀원이 제가 작성한 코드를 "이건 레거시야 당장 개선해야해"라고 말한다면 뭔가 마음이 불편해질 것 같다는 생각이 듭니다. 리팩터링을 하는 개발자는 리팩터링 이전의 코드를 작성한 개발자를 존중하면서 미래를 위해 조금 더 나은 방안을 고민해본다는 생각을 꼭 가져야합니다. 언젠가는 내가 리팩터링한 코드도 리팩터링의 대상이 됩니다. 그런 날이 올 때, 서로를 존중하며 더 나은 선택을 할 수 있도록 하는 마음가짐을 가져봅시다.

정리하자면, 리팩터링한 개발자는 코드 리뷰 이상의 수준으로 리팩터링 이전의 코드를 이해할 수 있게됩니다. 테스트 코드도 개선하고 전반적인 코드를 개선하는 과정에서 이전 코드에 대한 명확한 이해가 선행되어야 하기 때문이죠. 또, 리팩터링한 개발자는 팀원을 존중하게 됩니다. 이전 코드가 "나쁘다", "레거시다" 라는 표현보다 정확한 근거를 바탕으로 리팩터링을 하면 더 개선될 수 있는 점을 강조함과 동시에 코드를 작성한 팀원을 존중한다면 감정적으로도 더욱 성숙해질 수 있다고 생각합니다.

팀원의 성장

팀원들 또한 리팩터링한 코드를 이해하며 성장할 수 있습니다. 리팩터링한 내용을 설명하고 코드를 작성하여 리뷰를 요청하면 "이렇게 개발할 수도 있었구나", "과연 이게 더 개선된 방안일까?" 같은 고민들을 하며 한층 성장할 수 있습니다.

또, 리팩터링한 코드에 내가 모르는 새로운 기술이나 개발 방식이 도입된다면 그 부분에 대한 학습도 가능합니다.

리팩터링 PR에 대한 답글

위 사진처럼 팀원들도 코드에 대해 고민하는 과정을 통해 새로운 학습 콘텐츠도 얻어갈 수 있고, 인상적이라고 생각하는 부분은 이후 본인이 개발하는 부분에서 충분히 도입할 수 있습니다.

프로덕션의 성장

리팩터링을 계획하고 실행하면서 오히려 리팩터링을 계획할 때는 보지 못했던 점들이 추가적으로 보이기 시작했습니다.

 

중요한 로직임에도 테스트 코드를 작성하지 않고 넘어갔던 부분도 보여 테스트 코드를 작성했는데, NullPointerException이 발생하는 것을 찾았을 때, 꼼꼼한 테스트 코드의 작성과 테스트 코드에 대한 상세한 리뷰가 필요하겠다는 생각을 할 수 있었습니다. 테스트 코드가 작성되지 않았던 부분의 테스트 코드를 작성함으로써 코드의 안정성을 개선함과 동시에 리팩터링을 더 쉽게 할 수 있겠다는 용기를 가질 수 있었습니다.

 

또, 알람 메시지가 local, dev, prod 환경에 관계 없이 모두 동일한 운영 링크로 이어진다는 것을 확인했습니다. 실제 배포되어 있지 않은 서비스에는 이런 작은 오류가 있어도 된다고 생각할 수도 있지만, 저는 안정적으로 운영을 하기 위해서라면 local, dev에서도 실제 운영환경과 동일하게 동작해야한다고 생각했습니다. 그래서 환경별로 알람에 전송하는 링크를 따로 관리하여 운영의 안정성을 높였습니다.

 

마지막으로, 알람 실패에 대한 대처가 미흡했다는 것을 보았습니다. 비동기 요청으로 외부 SNS를 이용한 알람서비스가 실패할 때 아무런 대처를 하지 않고 있었습니다. 하지만 저희 서비스 특성상 사용자가 많이 접속하는 서비스가 아니기에 알람이 정말 중요했습니다. 따라서 현재 팀의 일정과 기술 수준을 고려하여 실패한 알람 대상 및 내용을 로깅하고 저희에게 실패된 알람 로깅을 전송하도록 만들었습니다. 덕분에 실패한 알람들에 대해서는 개발자들이 실시간으로 인지하고 따로 알림을 줄 수 있게 됐습니다. 이 과정에서 외부 요청을 보내는 RestTemplate에 대한 개선도 이뤄졌습니다.

정리

리팩터링을 하다보니 많은 것을 보고 느낄 수있었습니다. 리팩터링을 하는 제 자신 또한 기술적, 감정적으로 많이 성장할 수 있었고. 팀원들도 기술적으로 성장할 수 있었습니다.(맞징?) 또, 최초에 계획한 리팩터링 내용이외의 부분들도 많이 개선하면서 프로덕션의 수준이 전반적으로 성장한 것을 느꼈습니다.

 

스프린트 요구사항 및 기능 구현이 급하기 때문에 리팩터링에 시간을 할애하는 것은 정말 어려운 일인데요. 이번 리팩터링 시리즈가 그럼에도 불구하고 리팩터링을 해야하는 이유에 대해 잘 설명할 수 있었다면 좋을 것 같습니다. 지금 자신만의 서비스를 운영하고 있다면 기능 구현과 동시에 달리는 기차의 바퀴를 갈아끼우는 경험을 해보는 건 어떨까요?

 

긴 글 읽어주셔서 감사합니다.