[리팩터링 2판 스터디] 1장. 리팩터링 첫 번째 예시
첫번째 장은 예시 코드를 리팩터링하는 과정을 보여주는 것이 주된 내용이기 때문에, 중간중간 나온 인상깊은 문구를 위주로 정리했다.
리팩터링 방법
- 리팩터링하기 전에 제대로 된 테스트부터 마련한다. 테스트는 반드시 자가진단하도록 만든다.
- 리팩터링은 프로그램 수정을 작은 단계로 나눠 진행한다. 그래서 중간에 실수하더라도 버그를 쉽게 찾을 수 있다.
리팩터링 책을 읽다보면 아닌게 아니라 정말 작은 단위로 리팩터링 과정을 나누고, 단계마다 항상 컴파일-테스트-커밋 하는 것을 확인할 수 있다. 변수 이름 하나 바꾸거나 코드 딱 한줄 옮긴 정도의 정말 사소한 수정까지도 항상 단계를 나누어 컴파일-테스트-커밋 했기 때문에, 처음에는 이렇게까지 할 필요가 있나 싶었다.
하지만 지금 생각해보면, 내가 지금까지 대규모 프로젝트에 투입된 적이 없었기 때문에 그런 생각이 든게 아닐까 싶다. 작은 프로젝트라면 그렇게까지 단계를 작게 나누지 않아도 충분히 실수를 바로잡을 수 있겠지만, 내가 수정할 코드가 대규모 시스템의 일부라면 코드 이름 하나 바꾸거나 라인 하나 옮기는것 만으로도 예상치 못한 오류를 발생할 수 있고 그걸 찾기도 어려울 지 모른다는 생각이 든다.
리팩터링 책의 첫 도입부에서도 ‘항시 책의 예시들이 대규모 시스템에서 발췌한 코드라고 상상하면서 따라오기 바란다.’ 라고 했기 때문에, 가끔 리팩터링 책에서 말하는 방식에 의문이 들 때에는 대규모 시스템을 가정하고 읽으면 좋을 것 같다.
수정을 위한 리팩터링
- 프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링하고 나서 원하는 기능을 추가한다.
- 좋은 코드를 가늠하는 확실한 방법은 ‘얼마나 수정하기 쉬운가’ 다.
이 말은 정말 격하게 공감하고 있다. 동료 개발자의 부재로 그의 코드를 내가 대신 수정해야 할 상황이 됐을 때, 항상 그 코드에 대해 이해하느라 얼마나 많은 시간을 쏟았는지 생각해보면 리팩터링이 얼마나 중요한지 실감하게 된다. 물론 나 없을 때 나 대신 내 코드를 수정해주신 개발자 분들도 같은 마음이었을 것이다.🥲
깔끔한 코드
- 컴퓨터가 이해하는 코드는 바보도 작성할 수 있다. 사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다.
- 캠핑자들에게는 ‘도착했을 때보다 깔끔하게 정돈하고 떠난다’ 는 규칙이 있다. 프로그래밍도 마찬가지다. 항시 코드베이스를 작업 시작 전보다 건강하게 만들어놓고 떠나야 한다.
솔직히 이 대목에서 많이 찔렸다. 나 또한 컴퓨터만 이해하는 코드를 짜는 바보였기 때문이다. 팀원들 뿐 아니라 나도 내 코드를 나중에 읽었을때 무슨 코드인지 못 알아볼 때가 종종 있었다. 이제는 나도 사람이 이해하는 코드를 작성하는 진정한 실력자가 되기 위해 리팩터링 책을 읽고 있다.
여담으로, 이번 챕터에서 위의 문구들을 보면서 문득 여기에 더 추가하고 싶은 한가지 문구가 떠올랐다.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
항상 내 코드를 유지보수할 사람이 내가 사는곳을 아는 폭력적인 사이코패스라고 가정하며 코딩해라.
- John F. Woods
어디선가 들었던 개발 명언인데, 나는 지금까지도 이것보다 임팩트있는 명언을 본 적이 없다.
개발 좌우명으로 이 말을 액자에 넣고 모니터 옆에 두면 정말 리팩터링하고 싶어질 것 같다.😂