진짜 개발은 리팩토링부터 시작된다

Code Refactoring_by Lynda.com

왜 리팩토링을 해야할까?

개발을 하다보면 리팩토링이란 말을 많이 접하게 된다.

그동안 나도 뜨문뜨문 리팩토링이란 말을 들었었는데 단순히 코드를 수정하는 것으로 알고 있었다.

최근에는 기능을 빠르게 구현하고 더 좋은 코드로 작성하기 위해 수정하는 식으로 개발을 하고 있다.

어쨌든, 리팩토링이 진짜로 왜 필요한지에 대해서는 의문이 많았었다. 그래서 이번 기회에 리팩토링에 대해 알아봤다.

 

리팩토링이란 소프트웨어를 잘 이해할 수 있도록 가독성을 향상시키고 유지보수의 용이성과 재사용성을 높이기 위해 행하는 코드 개선 활동이다. 단, 외부적인 동작에 영향을 주어선 안된다. 소프트웨어의 기능이나 성능에 영향을 주어서는 안된다는 것이다.

 

이런 리팩토링은 소프트웨어를 더 쉽게 이해하게 만든다. 소프트웨어라는 것이 수명이 짧은 것도 있지만, 어느정도 규모가 되는 소프트웨어는 후임개발자에게 물려주거나 다른 협업자들이 생기기 마련이다. 만약 나말고 다른 사람들이 이해하기 힘든 코드를 짠다면 어떻게 될까? 그 코드를 이해하는데만 해도 많은 시간이 걸릴 것이다. 그것도 회사의 입장에선 비용으로 간주될 것이고. 더군다나 수많은 코드를 다시 봤을 때 작성자인 내가 이해를 못한다면?

 

 

언제, 어떻게 리팩토링을 해야할까?

그래서 리팩토링은 언제 실행하는게 좋을까? 리팩토링을 언제 해야되는지는 불분명한 것 같다. 다만 특정한 기간, 특정 시간을 두고 리팩토링을 하는 것은 권장되지 않는 것 같다. '리팩토링'의 저자인 마틴 파울러에 의하면 기능을 추가할 때, 버그를 수정할 때, 코드 리뷰를 할 때 리팩토링을 권장하는 것 같다. 구현을 하면서, 코드 리뷰를 하면서 리팩토링을 하는 것이다.

다만, 나 같이 아직 초보자의 입장에서는 기능 구현을 하면서 바로바로 좋은 코드가 잘 떠오르지는 않는 것 같다. 나는 기능 구현을 다 마치고 구조 개선이나 더 효율적인 코드 수정을 위해 리팩토링 하는 것도 하나의 방법이라고 생각한다.

 

어떻게 리팩토링 하는 것이 좋은 리팩토링일까?

브런치의 불씨님의 '좋은 코드, 나쁜 코드, 이상한 코드' 글에 의하면

 

-죽은 코드를 없애야 한다
전혀 사용되지 않고 차후에도 사용되지 않을 만한 코드를 가차없이 삭제한다. 만에 하나 추후에 다시 필요해진다면 언제든지 다시 되살릴 수 있다.

 

-함수나 변수명을 잘 짓기

각 프로젝트마다 코드 컨벤션이라고 있다. 나 역시도 최근에 컨벤션이라는 말을 접했는데 프로젝트나 조직에서 코드를 작성할 때 일련이 규칙을 말한다. 이런 컨벤션이 있어야 새로운 개발자가 유입됐을 때 코드에 대한 이해가 빨리 될 수 있다. 함수나 변수명은 그 기능과 함수가 의도하는 바를 알 수 있도록 만들어야 한다.

 

-함수나 메소드는 한 가지 기능만 정의해야 한다

객체 지향의 단일 책임 원칙과도 통하는 내용 같은데 함수가 두 가지 이상의 기능을 수행하고 있다면, 그 기능을 분리해야한다.

 

-불필요한 주석은 없애자

소프트웨어를 계속 운영하다보면 주석 역시도 시간이 갈수록 변해야한다. 하지만 오래되어 의미없는 주석이 많아지고 실제 코드와 다른 의미를 가진 주석도 생겨난다. 가독성을 높이기 위한 주석이 가독성을 저해하는 모습을 보이는 것이다. 언제나 주석 대신 코드로 설명이 되도록 만들되 반드시 필요한 부분에서 주석을 쓰도록 한다. 자바 컨벤션 같은 코드 컨벤션에서는 주석을 어떻게 달고 어떤 내용을 가져야 하는지에 대해서도 언급이 되있다.

 

-코드 중복은 최대한 없애야 한다

코드 작성시에 가장 중요하게 생각하고 기본적인 부분인 것 같다. 코드 중복을 없애는 것은 좋은 코드 작성에서 가장 중요한 부분이다. 만약 소프트웨어의 특정 부분에서 버그가 발생해 수정했다고 하자. 이후에 비슷한 부분에서 똑같은 문제가 계속 발생된다면 이것은 코드 중복 때문이라고 볼 수 있다.

 

 

 

참고 : 불씨 - 좋은 코드, 나쁜 코드, 이상한 코드
         Code Review :: 리팩토링이란 무엇인가