아래의 글은 마틴 파울러 지음 김지원 옮김, 『리팩토링 코드 품질을 개선하는 객체지향 사고법』,한빛미디어(2012)의 내용을 기반으로 작성하였습니다.
몇 일 전에도 10년차 이상된 중급 개발자 리드 S님이 오시더니 자기 코드를 리뷰를 해달란다. 리뷰는 팀 내에서 해야지 내가 지금 코드 놓은지도 3개월이고 나의 신념상 같이 코드 개발을 하지 않으면서 코드에 감놔라 배놔라 하는 꼴은 나도 싫어서 뭘 할 수 있겠나 하고 일단은 들어보기나 하자고 해서 시작이 되었다.
메소드를 Dto가지고 넣어다 뺐다 한다. 그러니 넣을 때 마다 값이 있는지 없는지를 체크해야하고, if 문으로 값이 있음 없음을 분기하여 아래에서 다시 if 문, 그곳에서 다른 서비스의 메소드를 호출하면 그 안에서 다시 if 문 ...
Dto에서 필요 없는 값을 지우는데 참조하는 곳에 많고, 지우다 보니 또 애매하게 판단을 해서 반쯤 사용하는 곳도 있고, 그래서 하나 지우는 데 벌써 몇개의 메소드를 왔다 갔다 하며, 수정하고, 심지어 메소드의 파라메터에 default 값을 주도록 변경하니 참조하는 곳 변경해야하고, 유사한 메소드를 여러 개가 있더라.
이미 하나 둘 알려주기에는 너무 멀어진 상황이라, 생각나는게 마틴 파울러의 리팩토링 책이여서, 이걸 팀에게 다시 알리는 게 나을 것 같아 이렇게 시작해 본다.
리팩토링은 겉으로 드러나는 코드의 기능은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정이다.
waterfall 방식이라고 하는 SI에서의 개발방식은 요구사항을 fix하고, 이에 맞게 설계를 하고, 명세서 (spec 일수도 있고, BRD, FRD로도 표현하고, wireframe등을 이용한 UI 설계서 등)가 나오면 그때 backend는 DB설계 API설계를하고, frontend 는 zeplin으로 된 UI를 가지고 UI를 구현한 뒤, API를 붙이는 작업의 흐름으로 간다.
하지만, 어디 요구사항이 바뀌지 않는 프로젝트가 있던가.. 수정과 개발자의 의견과 빠진 요구사항과 edge case가 융합이 되면서 요구사항을 위한 요구사항이 추가 되고, 빠듯한 일정이라는 달콤한 압박이 밀려오면 일단 구현우선주의 메타포가 형성이 되면서 간단하게 수정하는 유혹의 과정을 거치면서 코드는 이해 할 수 없는 형태와 파편화를 가속화하게 된다.
어쩌면 이제 나에게는 당연한 과정이 이를 경험해보지 못한 개발자에게는 잔소리와 알지도 못하면서 하는 충고로 변경이 되면서, 일단 돌아가면 된다는 무논리로 프로젝트는 오픈하게 된다.
나 또한 리팩토링을 알지 못했다면 이 과정이 당연하다 여겼겠지만, 20년전에 마틴 파울러는 이를 알고 책으로 만들었다. 처음에는 그냥 조금 더 나은 방법론이라 생각했지만, 보면 볼수록 곱씹어 볼 내용이 가득한지라, 한때는 이런 책을 쓸 수 있는 그 들의 세계와 저력이 부러울 따름었다. 하지만, 그 나라의 코드도 봤더니, 그 나라에 있는 사람도 모두 리팩토링을 잘 하는 것은 아니더라. 그러니 또 너무 기가 죽지는 말자. 그들에게도 우리와 같은 시절이 70년대 80년 대를 거치면서, 고난의 시간을 가졌고, 그 들 또한 답답함에 agile manifesto를 만들어서 우리도 바꾸지라고 했으니 그건 시간이 필요한 영역인 듯 하다.
리팩토링은 심미적인 요소가 반드시 존재하니, 개발자 스스로 아름다움을 추구하지 않는다면 리팩토링은 다들 시간 낭비 혹은 과한 요소라고 생각하시는 분들도 있다. 좀 더 현실적으로 말하자면, 다들 리팩토링이 중요하다고 하는데 리팩토링 관련된 책은 뭐가 있는지도 모른다. 그러니 말로만 리팩토링이요, 코드를 더 간결하고 직관적이고 아름답게 만드는 노력의 과정은 정말 필요하다는 당위성을 깨닫지 못한다. 리팩토링은 오랜 동안 실전에서 깨닫고 변경해가면서 느끼는 과정이 되면, 그 이후는 당연이 그 끝에 나와야 하는 코드의 모양이 어떻게 되는 코드의 구조를 잘 잡게 된다. 즉 디자인 패턴과도 연관이 되어 있다. 그리고 리팩토링은 하나의 팁이나 짧은 식견으로도 가르쳐 줄 수 없는 거라, 단순한 부분 교육으로도 쉽게 바뀌어 지지 않는다. 그리고 아직 나 또한 부족한 부분이 많은 터라, 알듯하면서도 어렵기도 한게 사실이다.
즉, 리팩토링은 오랜기간에 거친 훈련이며, 코드 뿐만 아니라 내부에도 돌아가는 매커니즘에 적합하게 코드를 변경하는 부분이라, 부단히 노력하고, 본인 스스로 적용해보면서 하나 하나 깨닫는 수련의 과정이다.
그러니 어렵고도 끝이 없는 과정이며, 정답도 없는 과정이다. 그리고 미적요소와 철학적 요소는 개인차가 반드시 존재하는 영역이라, 개인의 사상이 반영되는 영역이다. 하지만, 피겨선수 김연아의 플레이가 그랬고 피아니스트 조성진의 연주가 그랬든이, 어느 경지에 오른 작품은 아무리 모르는 사람이 보더라도 그 탁월함은 쉽게 판명이 난다.
그러니, 부단히 노력하여, 마틴 파울러처럼 이런 책은 못 만들더라고, 그 사람이 가르치는 내용은 따라가서 흉내라도 내보도록 하자.
그리고 가르치면서 나도 또 다시 배운다.
'독서관련 > 리팩토링 - 2012 - 마틴 파울러' 카테고리의 다른 글
CH02 리팩토링 예제 실행 코드 (0) | 2020.12.12 |
---|---|
CH04. 테스트 작성 (0) | 2020.12.12 |
CH03. 코드의 냄새 (0) | 2020.12.12 |
CH02. 리팩토링 개론 (0) | 2020.12.12 |
CH01. 예제를 통한 리팩토링 개념 잡기 (0) | 2020.12.07 |