리팩터링 책이 20년 만에 2판이 나왔다.
만화에서 하고자 하는 이야기랑은 좀 다르긴 하지만, 저기서 나오는 전 개발자가 실제로는 대부분 나다.
짜놓은지 며칠만 지나도 기능 추가 등을 위해서 열어보면 어떻게 이렇게 엉망진창으로 해놓았지라고 생각할 경우가 많다. 생각해 보면, 여러가지 이유로 일단 돌아가기만 하게 하자 라고 하고 작성한 코드들을 나중에 쳐다 볼 때 더욱 그랬다.
심지어 이건 과거의 이야기가 아니고 현재 진행형이다....
알아보기 쉽고, 좋은 코드를 작성하는 것에 대한 책이 여러가지 있지만, 그중 가장 유명한 책이 리팩터링이다.
리팩터링 책이 (원서 기준으로) 20년 만에 2판이 나왔다. 원서 기준으로 20년 만의 개정판이라니 대단하다. 개작을 할 수 있는것도 대단하고, 이 책이 아직도 읽히고 팔린다는 것이 대단하다.
리팩터링이란 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법이다. 그리고 한다고 표시가 나는 것도 아니고, 기능이 달라지는 것도 아니고 (달라지면 안되지), 성능이 좋아지는 것도 사실 아니다.
책에서도 이야기 하지만, 리팩터링을 해야하기 때문에 일정을 빼야 한다고 실제로 윗사람에게 이야기를 하면 잘돌아가는 프로그램을 괜히 건드려서 오류가 나면 어떻게 할거냐, 공연한 시간낭비를 하지 마라 라는 소리를 듣기 쉽상이다.
그럼에도 불구하고, 저자는 다음과 같은 이유로 리팩터링을 해야 한다고 한다.
- 코드를 건강한 상태로 유지하는데 도움을 줄 수 있다.
- 소프트웨어 설계가 좋아진다 (아키텍쳐를 충분히 이해하지 못한 채 단기 목표만을 위해 코드를 수정하다 보면 기반구조가 무너지기 쉽다.)
- 소프트웨어를 이해하기 쉬워 진다.
- 버그를 쉽게 찾을 수 있다.
- 프로그래밍 속도를 높일 수 있다.
그리고 리팩터링을 하는 것은 내가 작성하는 코드를 개선 하고 싶고, 좀더 나은 개발자로 성장하고 싶다면 꼭 해야 한다고 생각 한다. 모든 기능을 지속적으로 개선해나가는 의지를 가지는 것은 자신의 성장에 크게 도움이 된다고 생각 한다.
책은 순서대로 리팩터링은 무엇인지, 언제 또 왜 해야하는지, 어떻게 해야하는지를 알려 주고 있다. 그리고 언제 하지 말아야 할 지 까지.
나의 경우 2장까지는 주욱 한번에 보았고 3장 부터는 코드를 쳐다 보다가 이걸 어떻게 개선할 방법이 없을까 할 때 찾아서 보고 또 보고 하고 있다.
작성된 코드를 리팩터링 할 때 마다, 프로그램의 성능이 좋아지지는 않을지라도 내머리속 성능은 좀나아지는거 같기는 하다.
내가 짠 코드 보고 내가 욕을 안하는 그날 까지 리팩터링은 계속 된다.
"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."