Topic 40 리펙터링
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
소프트웨어 개발은 건축보다 정원 가꾸기에 더 가깝다. 딱딱하기보다는 유기적인 활동이다. 정원에는 최초 계획과 조건에 맞추어 여러 가지 식물을 심는다. 몇몇은 잘 자라겠지만, 몇몇은 퇴비가 될 운명이다. 빛과 그림자, 비와 바람의 상호 작용을 더 잘 이용하기 위해 식물들의 상대적인 위치를 옮기기도 한다. 너무 많이 자란 식물은 포기를 나누거나 가지치기를 한다.
p.301
필자도 소프트웨어 설계를 아키텍처로 표현하듯 건축과 유사하다고 생각을 했다. 그렇지만 저자는 건축이 아니라 정원 가꾸기라는 표현을 사용하고 있는데 매우 신선하면서 적지 않은 충격이기도 하다. 계속해서 프로그램은 자라고 커지며 개발자는 다듬고 때로는 다른 곳에 심기도하며 잦은 변화를 마주치기 때문이다. 다음부터는 소프트웨어를 생각하고 설명할 때 건축보다는 정원 가꾸기라는 표현을 사용해야겠다는 생각이 든다.
리펙터링을 식물을 다시 심기 위해 정원 전체를 갈아엎듯이 해서는 안 된다.
p.302
리펙터링은 외부의 동작은 같지만 내부가 달라지는 것이기 때문에 조금씩 확실하게 변경해야한다. 궁극적으로는 전체가 달라질 수는 있으나 소규모로 진행해 나아가야한다.
리펙터링은 언제 하는가?
여러분의 코드를 리팩터링하는 것-기능을 이리저리 옮기고 이전에 내린 결정을 바꾸는 것-은 사실 ‘고통 관리(pain management)’를 실천하는 것이다.
p.303
리팩터링은 지금보다 더 낫도록 개선하는 것이라고 생각했지만 고통 관리라고 생각하니 더욱 와닿는 것 같다. 리팩터링할 것이 있다는 것은 고통이 언제든 발생할 수 있고 더 커질 수 있다는 것을 의미하기 때문이다.
중복
DRY 원칙 위반을 발견했다.
p.302
직교적이지 않은 설계
더 직교적으로 바꿀 수 있는 무언가를 발견했다.
p.302
더 이상 유효하지 않은 지식
코드는 지금 상황에 뒤떨어지지 않아야한다.
p.303
사용 사례
“꼭 필요하다”고 생각했던 기능은 그렇지 않은 경우도 있다는 것을 깨닫게 될 것이다.
p.303
성능
성능을 개선하려면 시스템의 한 영역에서 다른 영역으로 기능을 올겨야한다.
p.303
테스트 통과
앞에서 설명했듯이 리팩터링은 작은 규모의 활동이고, 좋은 테스트가 뒷받침되어야 한다. 그러니 여러분이 코드를 조금 추가한 후 추가한 테스트가 통과했을 때가, 방금 추가한 코드로 다시 뛰어들어 깔끔하게 정리하기에 최고의 타이밍이다.
p.303
현실 세게의 복잡한 문제들
리펙터링이 필요한 코드를 일종의 ‘종양’이라고 생각하자. 종양을 제거하려면 수술이 필요하다. 지금 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다. 아니면 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다. 하지만 그때가 되면 제거하는 데 드는 비용도 더 늘어날뿐더러 위험도 훨씬 커진다. 시간을 더 끌면 환자는 생명을 잃을지도 모른다.
p.304
어떤 날은 리팩터링을 하다보니 하루가 가는 경우도 있다. 그만큼 무심코 코드를 작성한게 많다는 뜻이기도 하다. 필자의 선호하는 방법은 코드를 작성하고 동작한다면 우선 커밋을하고 리팩터링을 진행하는 것이다. 이럴 떄 되돌리기도 쉽고 file diff 를 통해 다시금 잘못된 부분이 없는지 확인하기도 좋기 때문이다. 무엇보다 리팩터링을 진행하고 file diff 를 보면 기분이 은은하게 좋아진다.
Topic 40 느낌
Topic 40 에서는 리펙토링을 빨리 진행해서 종양을 키우지 말라고 설명하고 있다.