갈아먹는 Code Refactoring [1] 코드 리팩토링의 즐거움

들어가며

최근 코드 리팩토링과 관련된 세미나를 준비하면서 참고한 글을 번역해보았습니다.

코드 리팩토링이란 무엇인지, 왜 중요한지, 언제 하면 좋은 지에 대해서 참고할 만한 내용이 많습니다. :)

그럼 시작하겠습니다!

https://bids.berkeley.edu/news/joy-code-refactoring

The Joy of Code Refactoring

 

만약 당신이 리서치를 위해서 소프트웨어를 짠 적이 있다면, 아마도 당신은 높은 확률로 당신의 코드들이 꼬이고 지저분해 지는 걸 본 적이 있을겁니다. 아마도 이 시점에서는 작성자인 당신 조차도 어떻게 각각의 조각들이 결합되는지 잊어버렸을 수 있습니다. 하지만 좌절하지 마세요! 리서치 소프트웨어에서는 이는 매우 자연스러운 거니까요! 단지 이 시점이 리팩토링을 해야할 때입니다.

리팩토링이란 무엇이죠?

코드 리팩토링이란 현재 코드의 동작은 그대로 유지하면서 더 이해하기 쉽고, 생각하기 쉽고, 확장하기 쉽게끔 재구성하는 것입니다. 소프트웨어 엔지니어링이나 컴퓨터 사이언스에서는 참고할 만한 자료들이 많습니다. 용어 자체는 1990년대부터 사용되었지만 정식으로는 마틴 파울러가 2001년에 쓴 "Refactoring: Improving the design of existing code"[1]에서 출발했습니다. 파울러는 리팩토링이라 여겨질 만한 몇 가지 코드 변형 목록들을 제시했습니다.

리팩토링은 왜 연구자들에게 중요한가요?

표면적으로는 어차피 결과물이 원본 코드와 동일한 작업을 수행하기 때문에 리팩토링에 시간을 투자하는 것이 미련해 보일 수 있습니다. 만약 당신이 학생이고 교수님께 당신이 새로운 결과물을 내지 않고 하루 종일 자질구레한 코드 수정만 했다고 보고하는 상황을 상상해보세요. 그러나 이러한 코드 재구성은 미래의 개발을 더욱 쉽게 하도록 도와주는 투자입니다. 소프트웨어의 수명이 길어질 수록, 더 많은 사람들이 읽고 수정해야할 필요성이 커질 수록 코드 리팩토링은 더 중요해집니다. 사실 저는 컴퓨터과학 연구자들이 코드 리팩토링은 중요하게, 심지어는 리서치 개발의 일부분으로 여겨야 한다고 주장합니다. 여기에는 두 가지 이유가 있습니다.

 

1. 연구자들은 종종 그들의 코드가 어떻게 동작할 지 모른채로 작성하기도 합니다. 예를 들어 데이터를 정제하고 모델링 할 때, 분석 과정을 마쳤을 때에만 비로소 드러나는 데이터의 특성 같은 것들이 있을 수 있습니다. 모델 혹은 알고리즘은 그 데이터, 혹은 데이터의 특색을 더 잘 드러낼 수 있도록 개선되어야 합니다. 새로운 요구 조건들은 종종 기존에 코드가 짜여졌던 방식이 최선이 아님을 의미하며, 기존 코드로 새로운 기능을 억지로 대응하기 보다는 새롭게 디자인 해야함을 의미합니다.

 

2. 연구 소프트웨어는 종종 새로운 알고리즘을 구현하거나 현존하는 알고리즘을 새로운 문제에 적용합니다. 소프트웨어의 가독성은 언제나 중요하지만, 연구의 이러한 측면들이 가독성을 달성하기 어렵게 만듭니다. 알고리즘 구현의 세세한 디테일들은 매우 중요하지만, 매우 상세한 문서가 주어지지 않는다면 해당 코드를 이해할 수 있는 유일한 방법은 코드를 읽어보는 것 뿐입니다. 만약 당신이 협업을 하거나 당신의 코드를 공개한다면 가독성을 극대화하는 것은 미래의 당신에게 분명 보상을 해 줄 것입니다. 다른 연구자들은 당신의 코드를 이해할 수 없어서 집어치우고 새로 시작하지 않을 것이며, 당신의 코드를 재활용할 것입니다. 만약 당신이 앞으로도 혼자서 볼 코드 작업을 한다 하더라도 가독성을 높이는 데 시간을 투자하는 것은 좋습니다. 왜냐면 나중에 당신 역시 당신의 코드를 이해하길 포기하고 처음부터 새로 짜는 상황이 생겨선 안되기 때문입니다.

 

연구 협업에서는 리팩토링을 하지 않았을 때 발생하는 대가를 그 연구를 물려 받는 후임자들이 감당하는 경우가 종종 있습니다. 예를 들어 한 대학원생과 나는 어떤 소프트웨어에 대한 책음을 넘겨 받아 함께 개발을 진행한 적이 있었습니다. 그 코드는 20000줄이 넘어갔으며 사용되지 않는 부분들이 많았습니다. 이들은 코드를 이해하는 것을 방해했으며 적절한 개선이 필요해 보였습니다. 몇 달간 코드를 이해하고 리팩토링하는 노력이 뒤따른 결과 더 이해하기 쉽고, 견고하고, 확장 가능하도록 코드를 2200줄까지 줄였습니다. 만약 개발 시점에서 주기적으로 리팩토링을 진행했더라면 여기에 들어간 시간을 훨씬 줄일 수 있었을 것입니다.

언제 리팩토링을 하나요?

언제 리팩토링이 필요한지 어떻게 알 수 있나요? 보편적으로는 코드 스멜을 느낄 때입니다. 코드 스멜이란 코드에 더 깊은 디자인 측면의 문제가 있음을 표면적으로 나타내주는 일종의 신호입니다. 아마도 당신은 하나의 함수가 수백줄에 달하거나 열개가 넘는 파라미터들을 전달받을 수 있습니다. 나는 주어진 함수 혹은 클래스를 빠르게 이해하지 못할 경우 코드 리팩토링이 필요하다고 느낍니다. 이 글에서는 어떻게 리팩토링을 하면 좋은지에 대한 디테일을 다루지는 않습니다. 다만 테스트 코드를 작성해 놓는다면 리팩토링을 수행한 이후에도 코드가 잘 작동함을 확신할 수 있어 매우 유용합니다.

 

실제로 나는 연구 코드를 작성할 때, 초기 설계를 가능한 단순하게 잡습니다. 그리고 문제를 더 잘 이해하게 되고 새로운 요구사항들이 명백해졌을 때 리팩토링을 진행합니다. 이는 너무 과도하게 디자인 된 코드들 (미래에 올 요구사항들을 미리 걱정하거나 필요 이상으로 동작하는 코드들)은 오히려 가독성을 악화시켰던 경험에 기반합니다. 나의 대부분의 연구 코드들은 파이썬입니다. 나는 먼저 함수들을 작성합니다. 나중에 특정 데이터 구조나 기능들이 묶여질 필요성이 생깁니다. 혹은 다형성이 코드 전반적으로 퍼져있는 조건문들을 제거해 줄 수 있을 것으로 예상됩니다. 그럴때 나는 코드들을 클래스로 묶어줍니다. 리팩토링과 관련된 다른 다양한 측면들이 있지만, 함수와 클래스 구조가 대부분을 차지합니다. 이러한 접근 방식은 내가 성급하게 잘못된 추상화를 선택하지 않도록 도와줍니다. 새로운 소프트웨어를 개발할 때에 나는 종종 코드의 전반적인 부분을 건드리는 큰 리팩토링들을 수행합니다.

마치며

리팩토링을 개발 프로세스의 자연스러운 일부분으로 받아들이면 당신은 당신의 코드에 더 많은 통제권을 가지고 있다고 느낄 수 있으며, 이는 앞으로의 개발을 더 즐겁게 만들어줍니다.  당신이 리팩토링 자체를 즐기게 될 지 누가 알겠습니까? 리팩토링의 핵심 아이디어는 정리하는 인용구로 글을 마치겠습니다.

 

"당신은 당신의 코드를 함부로 바꿀 수 없는 얼어붙어있는 것으로 보아선 안됩니다.

대신에 당신은 스스로 코드를 최적의 상태로 유지할 수 있고,

새로운 과제들에 유연하게 대처하며 두려움 없이 코드는 고칠 수 있어야합니다." [4]

Reference

[1] “Refactoring: improving the design of existing code” by Martin Fowler, www.refactoring.com

[2] “Refactoring to Patterns” by Joshua Kerievsky

[3] “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert Cecil Martin

[4] http://www.infoq.com/articles/RefactoringMyths