-
-
리팩터링 2판 (리팩토링 개정판) - 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기
마틴 파울러 지음, 개앞맵시 외 옮김 / 한빛미디어 / 2020년 4월
평점 :
블라인드 앱의 IT 엔지니어 게시판에는 코드의 품질을 탓하는 글들이 자주 올라온다. 전임자가 남긴 코드를 유지보수 해야하는 상황에서 어디서부터 손대야할지 모르겠다거나, 협업을 해야하는 개발자의 코드가 마음에 안든다거나 하는 글들이다. 나 역시 비슷한 경험이 있다. 지난 프로젝트에서 경험이 많은 개발자와 협업을 해야하는 상황이었는데 그 분에게 많은걸 배웠지만 코드 작성 방법에 있어서 서로 다른 방법을 추구했다.
// 변수 선언과 할당의 분리는 어떤 상황에선 개발자의 의도와 다른 동작을 초래한다.
String foo;
foo = "mypath";
정답이 있는 건 아니지만 최선은 추구해야 할 것이다. 내가 신경 쓰이는 부분은 위와 같이 변수의 선언과 할당을 분리하는 것이다. 과거 학교에서 C 언어를 처음 배울 땐 함수에서 쓸 변수를 최상단에 선언하고 나중에 할당을 했지만 최근에는 변수의 이력을 선언까지 왔다 갔다 하며 이력을 살펴봐야 하고, 중간에 변수의 값이 어떻게 변경될지 알 수 없기 때문에 변수를 할당할 때 초기화(할당)를 하고 최소 선언과 할당을 나누더라도 최대한 가까운 곳에 코드를 배치하게 권장하고 있다. 하지만 이는 스택오버플로에서도 질문이 올라올 만큼 현재도 여러 스타일이 혼재해있는 게 현실이다.
남의 코드를 수정하는 건 민감한 문제이다. 어떤 개발자들은 코드에 자신을 투사해서 다른 사람이 자신이 작성한 코드를 수정하면 자존심이 상하는 것은 물론 고성이 오가기도 한다. (SI 프로젝트에서 자주 봤다..) 그렇다고 수정할 수 있을 때 수정하지 않으면 나중에 소스코드를 인계받을 때 아래와 같은 마음이 된다. 위의 선언과 할당 분리는 최초 작성한 코드에선 문제가 없어도 기능이 추가되고 유지 보수하면서 코드를 수정할수록 코드가 오동작할 가능성이 커지게 된다. 코드를 읽기 힘든 건 덤이다.
이런 상황에서 코드를 넘겨받으면 어떻게 해야 할까? 설계 문서가 있으니 괜찮다고 생각하면 안 된다. 설계 문서와 이를 구현한 코드가 다를 땐 더 큰 혼란이 온다. 넘겨받은 코드가 깔끔하면 좋겠지만 대부분은 그렇지 않다. 특히나 SI 프로젝트에선 기한에 쫓겨 개발하기 때문에 경험상 코드의 품질을 기대할 수 없는 경우가 대부분이었다. 운영팀으로 4년 정도 일하면서 비슷한 고민을 많이 했다. 코드를 넘겨준 개발자를 원망할 때도 있었고, 차마 건들 수 없어서 새로 만든 코드도 있었다. 그렇게 소스코드는 거대한 스파게티가 된다.
그러던 중 리팩터링과 TDD에 관한 세미나를 참여할 기회가 있었다. 기존에 존재하는 복잡도 높은 코드를 어떻게 유지 보수하기 쉬운 코드로 수정할 수 있을까. 몇 시간 동안에 리팩터링에 대한 간단한 기법을 배우고 어떻게 해나가야 할지 배웠다. 유용했지만 ‘과연 실무에서 리팩터링을 해나갈 수 있을까?’라는 질문은 여전히 떨칠 수 없었다. 그러던 중 마틴 파울러가 쓴 리팩터링의 2판이 나왔다는 소식을 접했다. 2판을 쓰면서 예제 언어를 자바스크립트로 바꿨지만, 이 책에서 말하는 기법들과 리팩터링의 원칙은 모든 언어에서 적용할 수 있는 지식이다. 예제를 따라가며 리팩터링을 학습할 수도 있고, 필요할 때마다 리팩터링 기법을 여기저기 찾아다니며 적용할 수도 있다.
동일한 코드가 주어졌더라도 개발자마다 생각하는 리팩터링 방향은 다를 수 있다. 그럴 수밖에 없는 게 코드에 정답이란 건 없으니까, 우린 우리가 옳다고 생각하는 방향으로 최선을 다할 뿐이다. 하지만 절대 원칙은 있다. ‘코드가 전과 같이 동작해야 한다’는 것. 마틴 파울러는 테스트를 통해 동작의 일관성을 유지해야 한다고 말한다. 테스트 코드 작성을 통해 어떤 단위 기능의 동작에 대한 명세(specification)를 대신할 수도 있다. 어떤 사람들은 테스트 코드를 작성하면 개발 생산성이 떨어진다고 주장한다. 당연히 코드 작성량이 배가 되지만, 이를 통해 우리는 안정감을 얻을 수 있다. 세상에 변하지 않는 건 없다. 코드도 그렇다. 실시간으로 변하는 요구사항에 맞춰 코드를 작성하다 보면 망망대해에 방향 잃은 배에 탄 것처럼 혼란스럽고 외로울 때가 있다. 이때 테스트 코드는 목적지를 가리키는 나침반이 돼줄 것이다.
복잡한 코드, 알 수 없는 코드를 작성한 사람을 원망하는 건 그만하자. 이제 앞으로 나아가야 할 때이다. 조금씩 리팩터링을 해보자. 내가 수정하는 파일만이라도 보이스카웃 규 칙을 생각하며 리팩터링 해보자. 물론 쉬운 일이 아닐 것이다. 하지만 누군가는 해야 하는 일이니까 지금부터라도 해보는 건 어떨까?
이 글의 제목과 내용은 나에게 하는 말이다.
