[책리뷰] Refactoring(리팩터링) 2판

[책리뷰] Refactoring(리팩터링) 2판

전문 프로그래머를 대상으로 쓴 리팩토링 지침서

 

 

서론부터 시작해서 굉장히 흥미롭게 본 책이다. 프로그래밍을 시작하면서 가장 많이 들었던 말 중 하나는 '프로그래밍은 책으로 공부하는게 아니다' 라는 것이다. 개인적으로 반은 맞고 반은 틀리다고 생각한다. 확실히 프로그래밍은 직접 코드를 작성하면서 의도대로 잘 작동하는지, 오류가 있으면 어떤 부분이 문제인지를 지속적으로 파악해가면서 공부하는 것이다. 그러나 이미 선대 프로그래머분들이 직접 겪어본 삽질을 내가 다시 수십년간 반복할 필요가 있을까?! 이런 부분은 책을 통해서 충분히 공부가 가능하다고 본다.

훌륭한 프로그래머분들이 작성한 이 리팩터링 책은 여러 프로젝트를 통해 발견된 오류와 삽질을 정리해서 알려준다. 나같은 초보 프로그래머들은 수백만줄이나 되는 프로젝트를 경험해볼 일이 없기 때문에 문제가 생기면 처음부터 다 살펴보면 해결된다. 그러나 수백명이 같이 진행하는 프로젝트에서는 이런 것이 불가능하다. 오죽하면 코드가 너무 복잡해서 처음부터 다시 만드는 것이 더 빠르다는 말이 나올 정도니... 예전에는 이 말이 이해가 되지 않았지만 일본인분이 트위치에 올려주셨던 짤을 보고 단번에 이해가 되었다.

 

처음부터 다시 만드는게 빠르다는 걸 이해시키는 가장 좋은 짤

 

위의 자전거 짤만 봐도 리팩토링의 중요성을 알 수가 있다. 좋아하는 만화 '미생'에서도 재밌는 말이 나온다. 

사업하면서 가장 위험한 게 뭔지 알아? 경주마가 되는 거야. 앞만 보고 달리는. 그러다 박살난다고. 넓게 보고 체크할 거 체크하고 가야지. - 미생1 44수 中 -

단순히 1회성 프로그램을 만드는거면 상관이 없지만, 그게 아니라면 문득문득 멈춰서서 정리를 해야한다. 미생에서 말하는 체크할 것들, 즉, 계약서 등에 적힌 용어들과 숫자들이 올바르게 적혀있는지 확인하는 것처럼 프로그래밍에서도 함수/변수명, 알고리즘 로직, 클래스 구조 등이 코딩 스탠다드에 맞게 제대로 짜여져 있는지 확인해야 한다고 본다.

 

책에서 저자는 TDD(Test-Driven Development)- 테스트 주도 개발을 추천한다고 한다. 그러나 김포프에 의하면 반은 맞고 반은 틀리다고 한다. 일단 테스트는 뭐든 간에 하면 좋다. 그러나 TDD를 하기 위한 테스트 코드를 작성하고 검사하는 시간이 필요 이상으로 많이 든다는 것이다. 게다가 TDD를 통해 나오는 버그들은 A급 버그가 아닌 경우가 많으며 이런 버그들은 차라리 정적 분석(Static Analysis)를 통해 빠르게 검출이 가능하다고 한다. 무엇보다 TDD 통해 나올 수 있는 버그들은 QA 과정에서 충분히 검출이 가능하며, 정적분석은 프로그램 전체에서 예상치 못한 오류나 빼먹은 코드도 검출이 가능하다는 것이다. 물론 책의 저자도 테스트를 너무 많이 만들다가 오히려 필요한 테스트를 놓치기 쉽기 때문에 가장 걱정되는 영역을 집중적으로 테스트하고 적은 수의 테스트만으로 큰 효과를 보는 것이 중요하다고 설명한다.

 

어떤 방법이 옳다 그르다를 논하기 보다는 어쨌든 좋은 프로그램을 만들기 위한 방법들이니 목적은 같다는 점이 중요하다. 혼자서 프로그램을 만드는 것에는 한계가 있다. 혼자서 연구를 하는 것이 아니라 여러 사람들과 협업을 통해 제품을 만드는 것이 목적이라면 모두가 효율적으로 일할 수 있게끔 코드를 작성해야 한다. 이 자리를 빌어 프로그래머들이 아무리 단순한 프로그램이라 할지라도 변수명을 a,b,c로 작성하고 넘겨주는 짓 좀 안했으면 좋겠다.(듣고 있나 홍**)

 

[이 리뷰는 한빛미디어 <나는 리뷰어다 2021> 서평단으로 무상으로 도서를 제공받아 작성되었습니다]