Martin Fowler's Refactoring
개발일기
 |
|---|
| 절판돼서 구하기 너무 어려웠던 책… |
읽다 보니 너무 교훈적인 내용이 있어서 기록해두고자 한다.
내가 개발자로서의 삶을 살아가는데 있어 가장 밑바탕이 되어야 할 자세라고 생각했다.
또한, 여러 커뮤니티에서 개발자의 필독서로 강력 추천하는 이유를 알 것 같은 책이다.
여러 차례에 걸쳐 책의 내용을 많이 인용할 것 같다.
누가 나한테 “리팩토링은 그냥 코드 정리 작업을 뜻하는 건가요”하고 물어본 적이 있다.
어떻게 보면 그것도 맞지만
(피식했다), 리팩토링으로 인해 코드 효율성이 높아지고 구조도 체계화된다는 점을 생각해볼 때 리팩토링은 단순한 코드 정리보다는 더 포괄적인 개념이라고 할 수 있다.
Refactoring - Martin Fowler p.76 中
서문에서 마틴 파울러는 리팩토링이 좁게 보면
단순히 개개인의 심미적 태도에 의한 코드 정리 작업으로 볼 수도 있지만,
예를 들면 깔끔한 사람이 지저분한 사람의 집에 가면 불편함? 언짢음? 과 같은 감정을 느끼는 것과 비슷한 뉘앙스다.
이보다 더 넓은 포괄적인 시선으로 바라봐야 한다고 여러차례에 걸쳐 강조하고 있다.
여기서 또 한 번 느낀 게 있는데, 개발 업계에서 선구자라고 불리는 사람들의 공통적인 특징에 대해서다.
이 사람들은 항상 인과율을 생각한다.
그러니까 현재 자신이 맡은 임무의 완수에만 매달리는 게 아닌,
자신이 한 행동으로 인해 일어날 결과에 대해서 많은 고민을 하는 게 보인다.
많은 일반적인 개발자들은 오늘 완성해야 할 기능만을 쳐다보지만,
이 사람들은 오늘 완성해야 할 기능을 생각하면서 동시에 미래까지 생각한다.
이는 로이 필딩이 REST를 도출해낸 과정과 매우 유사하다.
관련 포스팅 - 📜 REST API 에 대한 고찰
리팩토링의 정의에 대해 강조할 내용은 두가지다.
첫째, 리팩토링의 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다. 리팩토링을 수행하면 겉으로 드러나는 기능에 거의 또는 아예 영향을 주지 않은 채 소프트웨어의 각종 기능을 변경할 수 있다. 소프트웨어를 더 이해하기 쉽게 고치는 방법은 오직 리팩토링밖에 없다.
둘째, 리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다. 따라서 리팩토링하기 전의 소프트웨어 기능은 리팩토링을 수행하고 나서도 그대로이며, 최종 사용자나 다른 프로그래머는 그 소프트웨어에 변화가 있음을 눈치채지 못한다.
Refactoring - Martin Fowler p.76 中
🤔 리팩토링을 해야하는 이유 ?
마틴 파울러는 리팩토링을 해야 하는 이유에 대해 다음과 같이 설명하고 있다.
💡 소프트웨어 설계가 개선된다
흔히 스파게티 코드라고 말하는 코드가 되지 않게끔 계속해서 가꾸고 다듬는다.
아무리 꼬인 코드라도 컴퓨터는 쉽게 이해할 수 있지만 사람이 이해할 수 있는 코드는 실력있는 프로그래머만 작성할 수 있다.
💡 소프트웨어를 이해하기가 더 쉬워진다
많은 개발자가 실수하는 부분이라고 꼬집고 있는 점이 하나 있는데,
어떤 기능 구현에만 집착한 나머지 나중에 그 코드를 유지 보수하게 될 동료에 대한 배려를 생각하지 않는다는 것이다.
이런 말을 하면서도 또 그렇다고 항상 타인만을 위해 코드를 작성하지는 말라고 한다.
대부분의 경우 자신의 코드를 자신이 수정하게 되는 경우가 훨씬 많기 때문이라고 한다.
(여기서 나는 “그럼 애초에 타인을 배려하며 코드를 짜면 결과적으로 내가 나 자신을 배려하는 게 아닐까?” 라는 생각을 잠깐 해봤다.)
아무튼 리팩토링을 계속해서 실시하면 코드에 대해 이해하기가 쉬워진다고 하며,
최초 단계의 리팩토링에 대해 랄프 존슨의 비유를 들려주고있다.
“우선 창 밖이 보이게 뿌연 유리창부터 닦는 일” - 랄프 존슨
💡 버그를 찾기가 쉬워진다
계속해서 리팩토링을 해 나가다 보면 코드가 전체적으로 알아보기 쉬운 구조가 되어 버그를 찾기도 수월하다는 것이다.
이 말을 하며 켄트 백의 말을 인용하고 있다.
“난 뛰어난 프로그래머는 아니고, 단지 습관을 잘 들인 착실한 프로그래머다.” - 켄트 백
저 말은 정말 금과옥조처럼 받아들여야 할 프로그래머로서의 삶의 태도가 아닐까 싶다.
💡 개발 속도가 빨라진다
나무만을 보지 말고 숲을 보라는 얘기다.
완성된 소프트웨어는 요구사항의 변화, 기능의 추가 등으로 계속해서 덩치를 부풀리며 발전해 나간다.
완성했다고 끝나는 게 아니라는 말이다.
그러니까 당장의 완성에만 급급하지 말고 미래를 보고 변화에 유연한 구조를 생각하라는 뜻이다.
그런 습관과 태도를 들인다면 나중에 스파게티 코드를 끌어안고 유지보수에 끙끙대는 시간을
획기적으로 줄일 수 있다. 당장에는 더 느리다고 느낄 수 있지만,
결과론적으로 놓고 봤을 때 결국에는 전체적인 개발 속도가 더 단축된다는 것이다.
이 포스팅의 마지막으로 마틴 파울러의 리팩토링에서 가장 핵심적인 글귀라고 생각되는 부분을 기록한다.
나는 리팩토링을 일부러 시간 내서 하지 말라고 한다.
리팩토링은 따로 시간을 정해서 하는 게 아니라 일상적으로 틈틈히 해야 한다.
리팩토링은 작정하고 몰아서 하는게 아니라,
뭔가 다른 걸 해야겠는데 리팩토링을 실시하면 그 작업이 쉬워지기 때문에 하는 것이다.
Refactoring - Martin Fowler p.80 中
😎 결론
이번 포스팅에는 마틴 파울러가 추구하는 핵심적인 가치가 들어있다.
코드를 작성 할 때 중요한 것은 코드가 목표로하는 하는 기능이 명확해야 한다.
리팩토링을 할 때에도 이 부분을 명심하고 진행해야 한다.
그리고, 좋은 습관을 들여라
