리팩터링의 교본 Refactoring — Martin Fowler
이 글은 Martin Fowler의 Refactoring Second Edition을 읽고 나서 느낀 부분과 동의하는 부분 그리고 개인적인 필자의 의견을 남기는 글이다.
이 책을 읽게된 이유
- 전세계 개발자들의 리팩터링 교본이라고 불리는 책이기 때문에 읽어보지 않을수 없었다.
- 기존에 First Edition은 Java 기반 예제 코드였지만 20년이 지나고 출간된 개정판에서는 JavaScript 기반으로 바뀌었다.
(20년간 많은 호평을 받은 책이 또다시 개정판으로 나왔다는 것은 이 책이 훌륭하다는 것이고, JavaScript 개발자로서 개정판이 반갑고 보고싶었다.) - 평소 Clean Code, Refactoring에 관심이 많은데 이런 추상적인 개념에 대해 저자가 어떻게 서술하였을지 궁금했다.
Refactoring이란 무엇일까?
저자가 말하는 리팩터링의 정의는 아래와 같다.
겉보기 동작은 그대로 유지한채 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
여기서 중요한 부분은 겉보기 동작을 그대로 유지한다라는 것이다.
코드를 작성하는 프로그래머라면 누구나 리팩터링을 하게 되는데, 리팩터링 과정에서 코드가 깨져 사이드 이펙트가 발생한 경험이 있을 것이다. 하지만 저자는 리팩터링 과정 중에서 코드가 동작하지 않는 상황이 생긴다면 그것은 리팩터링이 아니라고 말한다.
“어떻게 코드를 망가뜨리지 않고 리팩터링을 할 수 있을까”에 대한 부분을 다루는 것이 이 책의 중요한 부분중 하나라고 할 수 있을것 같다.
Refactoring 언제 해야하는가?
리팩터링을 하는데 가장 큰 방해가 되는 부분은 부족한 시간일 것 같다. 리팩터링이란 마음만 먹는다고 짧은 시간안에 뚝딱 할 수 있는 간단한 작업은 아니다.
When?
- 기능추가 직전에
- 코드를 이해하려고 할때
- 나쁜 코드를 발견했을 때
- 코드리뷰를 할 때
저자가 말하는 리팩터링을 해야하는 때이다. 한 번만 해도 힘든 리팩터링을 이렇게 여러 상황에서 자주 하라고 한다.
나도 저자의 말에 동감한다. 리팩터링은 날을 잡고 하는 것이 아닌 틈틈히 자주 해야한다. 왜냐하면 리팩터링을 하기위한 시간이 주어지는 프로젝트는 거의 없을 것이다.
그렇다고 그 시간을 벌기 위해서 매니저를 설득할 수 있겠는가? 그냥 말하지 말고 알아서 하는 것이 속편하다.
그러니 리팩터링은 틈틈히 자주 해서 나중에 긴 시간이 걸리게 되는 일을 미리 줄이자.
추측하지 말고 현재 요구사항만 충족해라
YAGNI(You Aren’t Going to Need It)
YAGNI란 저자가 말하는 소프트웨어 설계 방식이다.
- 리팩터링을 활용해서 추측하지 말고 현재 요구 사항만 충족해라
- 하지만 그것을 완벽하게 해결할 수 있도록 설계하라
- 소프트웨어 복잡성에 영향을 주지 않는 메커니즘은 마음껏 추가해라
- 복잡도를 높일 수 있는 유연성 메커니즘은 반드시 검증을 거친뒤 추가하라
미래에 추가될지도 모르는 기능을 위해서 미리 추가적인 메커니즘이나 인터페이스를 만들어 두지 말자는 말이라고 보면 될 것 같다. 실제로 미래에 추가될 스펙에 대해서 미리 개발하는 것이 도움이 될 수도 있지만 그것이 오버엔지니어링이 되어버릴 가능성이 높다는 것이다.
간결한 설계 혹은 점진적 설계라고도 할 수 있는데, 아키텍쳐를 설계하는데 처음부터 완벽하게 하는 것보다 점진적으로 더 나은 아키텍쳐를 만들어나가는 설계 방식이다.
필자도 생각해보니 점진적 설계를 통해서 개발을 하고 있고 이를 지향하고 있다.
리팩토링 기법들
이 책에서는 여러가지 리팩토링 기법들을 소개한다. 리팩터링을 체계화 하려는 저자의 의도가 느껴지는데, 복잡하고 추상적인 리팩터링을 작은 단계들로 나누어서 설명해주기 때문에 리팩터링에 대한 감이 잡히질 않는다면 이 책을 한 번 읽어 보는 것을 추천한다.
이 글에서 모든 기법들을 소개할 수는 없기 때문에 어떤 기법들이 있는지만 적는다.
- 함수, 변수 추출하기
- 함수, 변수 인라인하기
- 함수 선언 변경하기
- 매개변수 객체 만들기
- 변수 캡슐화 하기
- 변수명 바꾸기
- 여러 함수를 변환 함수로 묶기
위에서 나열한 기본적인 리팩터링 기법 이외에도 정말 여러가지의 기법들이 존재하는데 자세한 내용은 책을 참고하는 것이 좋을 것 같다.
훌륭한 개발자가 되고 싶은가?
이 책에 대한 기대를 많이 하고 봐서 그런지 생각보다는 아쉬운 부분도 있었고 어떤 부분에서는 동의하지 않는 부분도 있었지만 누군가가 이 책을 추천하겠냐고 묻는다면 추천한다.
마틴파울러(Martin Fowler)는 이렇게 말한다.
“컴퓨터가 이해할 수 있는 코드는 어느 바보라도 다 짤 수 있다. 하지만 훌륭한 개발자는 사람이 이해할 수 있는 코드를 짠다.”
내가 작성한 코드가 항상 완벽할 수는 없다. 완벽하지 않은 코드를 더 나은 코드를 만들어 주는 것이 Refactoring이다.
Refactoring을 통해서 훌륭한 개발자가 되자.
