[소프트웨어] 리팩토링 글을 읽고

Overview

금주 9일에 Korean Article에서 리팩토링에 관한 좋은 번역 글을 발행했습니다.
글을 읽으면서 공감되는 부분들이 많이 있었고, 좋은 인사이트를 얻은 내용도 있었습니다.
지난 몇 달 동안 리팩토링에 대한 업무를 주로 진행하면서 개인적으로 리팩토링에 대해 느꼈던 생각을 남겨보도록 하겠습니다.

(번역) 좋은 리팩터링 vs 나쁜 리팩터링

 

리팩토링

소프트웨어 공학에서 리팩토링은 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 이라고 정의하고 있습니다.
리팩토링의 핵심은 본래의 기능은 유지하며 소스 코드를 여러 관점에 의해 변경하는 것인데, 여기서의 여러 관점은 협업, 유지 보수, 추가 기능에 의한 리팩토링 등 이 있습니다.

실제로 리팩토링을 하면서 가장 중요한 것은 리팩토링으로 인한 사이드 이펙트를 방지하는 것인데, 잘못된 리팩토링으로 인한 사이드 이펙트가 발생한다면 잘 돌아가는 프로덕트에 이슈를 야기하여 소프트웨어의 신뢰성이 저하될 가능성이 높아 상당히 주의해야 합니다.
잘 계획된 리팩토링과 테스트를 통과한 리펙토링은 유지 보수를 편리하게 하고 프로젝트의 수명을 늘려주기 때문에 장기적으로 유지중인 프로젝트라면 반드시 고려해보아야 합니다.

 

리팩토링에 있어서 느꼈던 주의점

계획은 철저하게

리팩토링을 진행하기에 앞서 계획을 철저하게 세워야합니다.
계획 없이 코드를 확인하고 수정한다면 기한 없이 계속 진행되는 리팩토링이 될 확률이 높을 뿐더러 결국엔 다시 원래의 코드로 롤백하는 경우가 발생할 수 있습니다.
계획을 철저하게 세우고, 세운 계획을 바탕으로 이슈 단위로 리팩토링을 진행한다면 훨씬 생산성 있는 리팩토링이 될 것 입니다.

 

사이드 이펙트 범위 예측하기

리팩토링을 진행하기에 앞서 변경할 코드의 단위를 계획하고 변경할 코드가 미치는 영향에 대해서 생각해봐야 합니다.
리팩토링은 기능은 유지한 채 코드를 변경하는 과정인데, 사이드 이펙트의 범위를 예측하지 못한채 리팩토링을 진행한다면 엉뚱한 곳에서 이슈가 생길 위험이 있습니다.
예측 커버리지가 100%가 되지 않는다면 진행중인 리팩토링을 멈추는 것이 좋습니다. 내가 진행한 리팩토링으로 인해 이슈가 생겨, 해당 이슈로 인해 고객의 신뢰도를 저하할 수 있기 때문입니다.
항상 리팩토링을 진행하기에 앞서 사이드 이펙트의 범주를 예측하고, 내가 예측하기 힘든 범주라면 기존의 팀원들과 상의하에 코드 변경이 미칠 영향도를 체크하시길 바랍니다!

 

테스트가 가능한 범위 내에 리팩토링 하기

리팩토링을 진행한 이후 반드시 기능 테스트를 진행해야 합니다. 만약 테스트가 불가능 하다면 리팩토링을 멈춰야 합니다. 프로덕션에 올린다면 어떤 이슈가 생길지 예측할 수 없어서 위험하기 때문입니다.
가령 테스트 데이터가 없어서 테스트가 불가하다면, 리팩토링을 진행한 코드를 main 브랜치에 병합하는 과정을 멈춰주세요. 

코드를 수정하고 기능이 동작하지 않는다면, 이는 이슈로 나올 확률이 농후합니다. 내가 생각했을 때 이 정도는 괜찮겠지? 라는 판단은 절대 금물입니다. 사양서(소프트웨어 기능 명세서)와 일치하지 않는 기능은 QA 후 이슈로 나올 확률이 높습니다.

 

반드시 테스트가 가능한 범위 내에서 리팩토링을 진행해주세요!! 이슈를 생산하는 개발자가 되지 말자는 경험에서 나왔습니다.

 

큰 단위의 리팩토링을 지양하기

공유 드린 아티클에도 나와있지만 리팩토링은 가급적 작은 단위로 리팩토링을 해야합니다.
리팩토링의 단위가 커져 작은 코드 집합, 프로젝트를 구성하는 작은 모듈 단위가 아닌 프로젝트 전역에 영향을 끼치는 리팩토링 이라면, 이는 코드의 리팩토링 보다는 새로운 기능 단위의 개발, 고도화 혹은 개선 작업이 아닐까 라는 생각이 듭니다.

 

레거시를 존중하기

레거시에는 이유가 있습니다. 그때 당시 그렇게 해야만 했던 이유가 있을수도 있으니 히스토리가 남겨져 있다면 반드시 히스토리를 추적해보도록 합시다.
레거시를 무시한 채 리팩토링을 진행한다면 그 리팩토링은 프로젝트에 어울리지 않는 리팩토링이 될 수 있습니다.
이는 리팩토링을 지양하라는 말이 아닌, 히스토리를 정확히 이해하고 리팩토링에 들어가야 한다는 의미입니다.

일례로 최근 프로젝트에서 jQuery를 걷어내려는 작업을 했었습니다.
프로젝트에 처음 투입되고 React 프로젝트에 jQuery, jQuery-ui 라이브러리의 번들 패키지가 소스 디렉토리 하위에 위치하고 해당 라이브러리를 직접 사용하는 것을 보고 기괴하다는 생각을 했습니다.
하여 해당 레거시를 걷어내는 작업을 진행했는데, 코드를 분석해보니 jQuery를 사용할 수 밖에 없는 이유가 존재했습니다.
해당 프로젝트에서는 vmware console 이라는 기능을 제공하고 있었는데, vsphere의 sdk가 jQuery, jQuery-ui를 사용하고 있었기 때문에 해당 라이브러리를 소스 디렉토리에서 사용하고 있었던 것 입니다.
결국 의존성이 강하게 얽매여 있었기 때문에 jQuery 자체를 걷어낼 수 없다고 판단이 들었고, 라이브러리 자체는 걷어내고 정적 assest 폴더 하위에 미니멈하게 패키징 된 파일 하나를 남겨두고 html 파일에서 script로 로딩 후 windows 객체의 프로퍼티로 jQuery를 바인딩해 사용하는 방식으로 변경했습니다.
소스 디렉토리 자체에서 무거웠던 jQuery, jQuery-ui 라이브러리를 걷어내 코드 베이스의 용량과 번들 사이즈를 줄였고, 모듈화를 통해 코드의 가독성을 높였습니다.

해당 리팩토링을 진행하며 들었던 생각은 레거시도 이유가 있다는 점 이였습니다. 그렇게 작성해야만 했던 이유를 정확히 캐치하고 리팩토링을 진행해야 프로젝트에 어울리는 리팩토링을 할 수 있구나라는 생각도 들었습니다.

 

컨벤션을 존중하기

팀의 컨벤션이 있다면 컨벤션을 존중하여 리팩토링을 진행해야 합니다. 이는 공유드린 아티클의 1번 항목으로 작성해주신 맥락과 일치합니다.
새로 시작하는 프로젝트가 아닌 팀 단위로 진행중인 프로젝트라면 팀의 컨벤션이 존재할 수 있습니다. 팀의 컨벤션과 팀에서 채택한 프로그래밍 방법론을 존중해야 좋은 리팩토링을 진행할 수 있습니다.

만약 리팩토링을 진행하기 전 특별한 팀의 컨벤션이 존재하지 않는다면, 컨벤션을 먼저 정립하는 것도 고민해보면 좋을 것 같습니다. 컨벤션이 없는 채로 리팩토링을 한다면 해당 코드는 추후 다시 리팩토링 할 확률이 높기 떄문입니다.

 

마치며

리팩토링 업무는 소프트웨어 엔지니어라면 항상 가슴속에 얹고가는 업무입니다.

 

새로운 기능을 개발하다보면 데드라인의 임박, 현재 기술의 한계 등 여러가지 이유로 기술부채가 쌓이기 마련이고,
기술부채를 언젠가는 청산해야 하고, 리팩토링도 기술부채의 일환이기 때문이죠.

그간 여러건의 리팩토링을 진행하며 이슈를 생산하는 개발자는 되지 말자 라는 생각을 마음속에 각인해놓고 업무에 임하고 있지만,  항상 사이드 이펙트의 범주를 정확히 예측하고 리팩토링을 진행하는 것은 정말 어려운 것 같습니다.

팀 동료들에게 많은 도움을 받고 있기도 하고, 좋은 팀 동료가 복지라는 것도 여기서 느껴지는 것 같습니다.

읽어봐주셔서 감사합니다.