리팩터링 2판 2장 - 리팩터링 원칙

리팩터링 2판 2장에서는 리팩터링 원칙에 대해서 다룬다.

 

리팩터링 
소프트웨어의 겉보기 동작은 유지한 채, 코드를 이해하고 수정하기 쉽게 내부 구조를 변경하는 기법

 

2장에서는 리팩터링을 왜, 언제 해야하는지에 대해 길게 설명한다. 항상 내가, 레거시 코드를 보면서 "지금은 할일이 있으니까 나중에 고쳐야지" 했던 것들이 사실은 잘못된거라는 걸 깨달았다. 가장 공감가고 핵심적인 내용을 세가지만 추려본다.

 

당장 피쳐 개발하느라 바쁜데 리팩터링 할 시간이 없어요

이에 대해 마틴파울러는 리팩터링은 항상 해야하는 것이라고 설명한다. 따로 리팩터링을 하기 위한 시간을 두는게 아니다. 예컨데 기존 코드에 깔끔하게 기능을 추가하려면 기존 구조를 변경해야되는 경우가 있다. 이런 경우 새로운 기능을 추가하기전, 시간을 할애해 새로운기능을 추가하기 위한 리팩터링을 진행한다. 나는 지금 할일이 우선이라는 핑계로 '일단은 작동되는 더러운 코드' 를 작성하는 경우도 자주 있었는데 책을 읽으면서 뜨끔했다.

비유하면 지금 위치에서 동쪽으로 100km를 이동하려는데 그 사이를 숲이 가로막고 있다면, 좀 둘러가더라도 20km 북쪽에 있는 고속도로를 타는 편이 세 배나 빠를 수 있다. 다들 "직진!" 을 외치더라도, 때로는 "잠깐, 지도를 보고 가장 빠른 경로를 찾아보자"고 말할 줄알아야 한다. 준비를 위한 리팩터링이 바로 이런 역할을 한다.
                                                                                                                                - 제시카 커

저자는 리팩토링을 함으로써, 새로운 기능을 추가하기가 쉬워지고, 후에 얻을 경제적인 이득이 발생한다고 설파한다. 리팩터링을 도덕적인 이유나, 코드의 미적인 이유때문에 하라는게 아니다. 개개인을 넘어 회사와 투자자에게까지 경제적인 이득이 발생하기 때문에 수시로 코드베이스를 리팩터링하라고 조언한다.

 

캠핑원칙

마틴 파울러는 캠핑원칙(boy-scout rule) 이라는 단어를 언급하는데, 개인적으로 이 단어가 모든걸 설명한다고 생각한다. 캠핑원칙은 머물렀던 자리를 왔을때보다 더 깨끗하게 치우고 떠나야한다는 규칙인데, 이 원칙을 소프트웨어 개발에도 동일하게 적용한다, 어떤 코드를 수정할때는 무조건 원래 있던 코드보다 깔끔하고, 정리되있는 형태로 수정을 해야한다. 기능을 추가하면서 기존 코드베이스의 구조를 망가트려서는 안된다는 의미이다. 계속 코드 베이스가 망가지다 보면, 나중에는 손쓰기 어렵게 되고, 기능을 추가하거나 수정하기 어렵게 되어 생산성에 치명적이다.

 

 

테스트는 필수

마틴 파울러도 테스트슈트가 없는 레거시를 수정하기는 정말 힘들다는걸 인정한다. 그래서, 새로운 시스템을 작성해야 한다면, 무조건 테스트 슈트(test suite) 를 작성하라고 얘기한다. 그 테스트 슈트는 미래에 이 코드를 보고, 리팩토링 해야할 수많은 개발자들의 나침반이 될것이다. 만약 당장 테스트 없는 레거시를 수정해야한다면 레거시 코드 활용 전략 이라는 책을 참고하면 좋다고 한다.