[고전 읽기] Refactoring 2판
이번에 읽은 책은 1999년도를 뜨겁게(?) 달구었던 책 중의 하나로서 Java로 작성된 예제를 JavaScript 기반으로 재 집필한 마틴 파울러 아저씨의 역작 "Refactoring 2판"이다.
소프트웨어 업계의 거장 중 한 명인 "마틴 파울러" 아저씨의 경험과 노하우가 듬뿍 담긴 이 책을 다시 읽어봤다.
1판을 읽었을 때에는 Java 개발자를 꿈꾸며 읽었던 기억이 있다. 열정은 많았지만 지식과 노력이 부족했던 탓에 책의 앞부분을 집중적(?)으로 읽고 이후 기법에 대한 내용은 지지부진해져서 못 읽었던 기억이 있다.
이번 2판은 JavaScript로 되어 있어서 더 흥미로웠고, 혼자가 아닌 동료들과 함께 스터디를 하면서 읽어봐서 다행히 끝까지 읽을 수 있었다.
이 책을 읽을 미래의 독자들에게 충고(?) 하 건데... 가급적이면 혼자 읽지 마라.
이 책의 초반은 무척이나 흥미로우나 뒷부분의 백과사전 형태의 전개는 읽는 이를 좀 지치게 만든다.
저자의 통찰력과 분석력. 그리고 이렇게까지 정리를 하다니...에 대한 감동과 경외로움은 생길지 언정 재미를 유지하기는 쉽지 않다.
앞에서 소개한 "Test-Driven Development : By Example" 책과 함께 읽으면 배움의 깊이와 즐거움은 더하리라 생각된다.
자~ 그럼 이 책은 무엇을 담고 있는가?
당연히 리팩토링의 기법을 담고 있다. 자세한 것은 직접 책을 읽어보시고, 나는 이 책을 통해 고민해야 할 주제에 대한 의견들을 적어보도록 하겠다.
왜 리팩토링 인가?
코드 간결해져서 좋고, 유지 보수하기 좋잖아요. 누구도 이견이 없을 것이다. 하지만 이것 또한 비용이기에 우리는 현실적이고 경제적인 결정을 해야 한다.
리팩토링이 현실적으로, 경제적으로 이득이 되는가?
장인 정신과 같은 도덕적인 접근을 하는 것은 아닌지 살펴봐야 한다.
말도 안 되는 이야기인지 모르겠지만 우리는 두 마리의 토끼를 항상 잡으려고 한다.
서비스를 만들면서 범용적이고 공통적인 플랫폼을 지향하기도 하고,
성능이 좋은 코드를 만들면서 가독성도 좋은 코드를 만들려고 한다.
양립되는 문제를 우리는 어떤 기준으로 해결해야 할까?
이 책에서는 리팩토링이 이러한 문제의 답이라고 이야기하고 있다.
예를 들어보자. 우리는 플랫폼을 만들고 싶은 이상적인 접근을 한다. 하지만 현실은 이도 저도 아닌 상황에 내몰리기가 쉽다.
요구 사항도 확실치 않은 상황에서 유연성 메커니즘을 넣어 미래를 대비하기에는 너무 많은 비용을 쏟아내야 한다. 사실 실무에서는 이런 내용들로 상당량의 논의를 계속할 때가 있다. 개인적인 성장에는 도움이 되는 일이지만 전체적인 상황 면에서는 불필요한 논의이기도 하다.
반면, 기능에 치중하여 개발만 하다 보면 요구 사항 수용능력은 떨어지고 내가 만든 코드들은 지속적으로 레거시로 전략하고 만다.
이 책에서는 리팩토링은 추측하지 않고 현재까지 파악한 요구 사항만을 정말 멋지게 만드는 방법이라고 이야기하고 있다.
© ikukevk, 출처 Unsplash
사실 리팩토링이 답인지는 잘 모르겠다.
하지만 내가 중요하게 생각한 것은 추측과 예측같이 미련한 의사결정은 없는 것 같다.
© Jean-Didier, 출처 Pixabay
"이렇게 하면 범용적으로 쓸 수 있을 것 같아요". 개발자로서 굉장히 좋은 접근이다. 하지만 사례가 모아진 다음에 해도 된다. 그때 리팩토링을 하고 유연성을 갖추어도 충분하기 때문이다.
사실 리팩토링이 연습되어 있다면 이마저도 개발하는 과정에서 코드에 잘 녹아들어 간다. (오히려 이런 리팩토링을 잘 할 수 있도록 테스트 코드를 준비해두는 것이 향후 확장을 위한 시초가 될 수 있다고 생각한다.)
물론 예외는 있다. 완결성과 같은 부분이다.
예를 들어 addEvent라는 메서드를 개발했다면 removeEvent 또한 존재해야 한다. 사용 여부와 상관없이 이런 인터페이스는 테스트 과정에서도 꼭 필요하고, 더 나아가 사용자의 인터페이스 이해면에서도 꼭 필요한 부분이기 때문이다.
JavaScript 개발자 입장에서 다시 보는 리팩토링 기법
처음 개발은 C와 C++로 배우고, 직장 생활 시작하면서 배우고 사용했던 언어는 Java이다. 하지만 지금 가장 익숙하고 이해도가 높은 언어는 JavaScript이다.
저자의 통찰력과 깊은 이해력을 내가 따라갈 수는 없겠지만. 이 책에서 다루는 리팩토링 패턴들은 JavaScript 개발자 입장에서는 조금은 아쉬운 면이 있다.
물론, TypeScript가 도입되면서 사실 언어 표현의 차이는 크게 나지 않는다. 하지만 아쉬웠던 포인트 몇 가지만 살펴보도록 하자.
최소 단위 클래스
이 책의 저자는 최소 단위를 클래스로 보고 있다. 물론 상태와 행위의 최소단위는 클래스이다. 하지만 나는 이 의견에는 다소 다른 입장이다.
태초의 JavaScript는 클래스도 없었고, 모듈도 없었다. 하지만. 현재는 클래스도 있고 모듈도 있다. CommonJS, AMD, UMD와 같은 다소 혼란스러운 스펙들 속에 ES Module이 점차 자리 잡게 되어 이제는 node.js든 브라우저의 JavaScript든 모두 ES Modules로 대동단결해 나가고 있다.
더군다나 JavaScript는 태생부터 "일급 함수"와 "클로저"라는 강력한 무기를 가진 언어이기 때문에 클래스보다는 함수를 다루는 게 더 유용한 접근법도 있다.
이 책에서 말하는 여러 리팩토링 기법이 유용하지만 어떤 리팩토링 기법은 굳이 클래스로 만들고 해야 할까 하는 생각은 여전히 내 머릿속에 남는다.
클로저와 함수, 그리고 모듈(파일) 단위로 접근하는 게 오히려 문제를 더 쉽게 풀 수 있다.
이 책에서 이러한 부분에 대한 노력과 접근법이 있었다면 더 좋았을 것 같다.
TypeScript
이 책의 예제를 만들어 보면서 평소 익숙한 TypeScript로 작성을 해 보았다. 처음 이 책에서 다루는 내용이 JavaScript스러운 리팩토링 책이었길 기대했었다. 하지만 내용은 1판에서 다룬 Java와 크게 다르지 않다는 것을 느꼈다.
당연한 소리지만 S/W 본질은 언어와 상관없이 차이가 없다.
하지만 내가 저자라면 JavaScript스러운 리팩토링 책이 아니라면 차라리 TypeScript를 주언어로 해서 설명을 했었다면 더욱더 공감이 가고 더 많은 것을 알아갈 수 있었으리라 생각되었다.
결론
몇 가지 아쉬운 점은 이 책 전체적인 내용에 비한다면 흠도 아니다.
이 책은 신입 개발자, 경력 있는 개발자, 잘 한다고 생각하는 개발자, 못 한다고 생각하는 개발자 모두가 곁에 두고 자주자주 찾아서 보면 좋을 꼭! 추천하는 고전이다
