리팩토링 하는 이유
소프트웨어 설계가 개선되니까
리팩토링 하지 않으면 설계는 노후된다.
단기 목적의 수정은 코드가 산만해지게 하고 리팩토링은 이를 정리한다.
이해하기 쉬워지니까
리팩토링 대상은 제대로 실행되지만 구조가 완전하지 못한 코드이고
리팩토링 후에 코드가 본연의 목적에 더 충실해지고 의도한 바를 정확히 전달할 수 있다.
버그 찾기 쉬워지니까
리팩토링은 코드를 근본적으로 이해하는 작업이 깨달음이 코드에 즉시 반영된다.
프로그램을 명료하게 만들 수 있는 수준이라면 버그를 놓치기 어렵다.
리팩토링으로 프로그래밍 속도가 빨라진다. 설계가 지저분하면 새 기능을 추가하는 시간, 버그 찾는 시간, 시스템을 이해하고 중복 코드에 적용하는 시간 등으로 코드가 길어지고 시간이 늘어난다.
깔끔한 설계는 개발속도를 적절히 유지할 수 있다.
리팩토링은 언제하는가
시간내서 따로 하는게 아니라 일상적으로 틈틈히 해야한다.
작정해서 하는게 아니라 다른 작업을 하는데 리팩토링을 하면 작업이 쉬워지기 때문에 하는 것.
같은 작업을 세번 할 때
처음할 땐 그냘하고 두번째는 망설여져도 그냥하고 세 번째 하게되면 리팩토링하는 기법
기능을 추가할 때
이때 하는 이유는 코드를 이해하기 쉽게 만들기 위해서이다.
리팩토링 후 코드가 더 이해하기 쉬워진다고 확신한다면 리팩토링한다.
설계가 지저분해서 기능 추가가 어려울 때 ‘이런 설계였으면 좋았겠다’ 싶을 때 설계를 수정한다.
버그를 수정할 때
버그 수정시엔 기능을 이해하려고 리팩토링한다.
앞서 말했듯 리팩토링하면 이해가 쉬워진다.
코드를 검수할 때
코드를 검수하면 다른 사람이 짠 코드를 보고 새로운 아이디어가 생기기도 하고 리팩토링하여 코드 검수가 더 잘되기도 한다.
리팩토링의 효용성
프로그램이 지닌 가치는 두 종류이다.
- 현재의 기능이라는 가치.
- 미래의 기능이라는 가치.
현재 기능이 프로그램의 일부에 불과하다는 사실을 깨우치지 않으면 개발자로서 오래갈 수 없다.
오늘 일은 할 수 있어도 내일 일을 내일 할 능력을 일게 되기 때문이다.
리팩토링은 과거의 판단이 불합리하다는 것을 발견하고 수정하는 작업으로 가치를 높이는 일이다.
리팩토링 문제들
데이터베이스
리팩토링으로 데이터베이스 스키마를 수정하면 데이터도 바뀌기 때문에 별도의 계층을 두면 좋다.
인터페이스
인터페이스의 변경은 호출하는 부분도 바뀌어야한다.
그렇지만 published interface의 경우엔 이게 어렵다.
사용하는 client들(다른 팀)의 수정까지 interface를 한동안 유지해줘야 한다.
- 그러니 published를 필요할 때가 아니면 만들지 말자.
- 서버에겐 api와 같다. api는 필요한 것만 만드는 것도 중요하지만 필요하지 않은 param, body가 들어오지 않도록 클라이언트와 명확하게 설계하는게 좋다.
리팩토링하면 안되는 상황
차라리 완전히 처음부터 새로 작성하는게 나을 때가 있다. 물론 이 판단은 쉽지 않고 기준도 없다.
납기가 임박한 시점에도 리팩토링을 삼가야한다.
리팩토링으로 인한 생상성이 납기 이후에 가시화 될테니.
납기가 임박하지 않다면 시간이 없다는 핑계로 리팩토링을 미뤄선 안된다.
언제나 시간에 쫓긴다면 그건 리팩토링해야하는 신호이다.
켄트 백의 모자 두 개
리팩토링이라는 모자와 기능 추가 모자가 있다.
모자는 각각 번갈아가며 쓸 수 있다. 그치만 두 모자를 동시에 쓸 수는 없다.
리팩토링 때는 코드 구조만 개선되고 테스트도 추가될 필요가 없다.
그러나 기능을 추가할 땐 리팩토링을 하지 않는다.
리팩토링과 설계
리팩토링은 설계를 보완하는 역할을 한다.
사전 설계를 빡세게 하지 않아도 리팩토링으로 잡을 수 있기 때문에 최상의 솔루션을 찾지 못해도 괜찮다.
단순히 구현하고 나중에 리팩토링하면 비용(시간)이 얼마나 들까를 고려해서 단순한 솔루션을 사용할지 결정할 수 있다.
유연하고 복잡한 설계가 필요하지 않은 경우도 많다.
리팩토링과 성능
코드를 이해하기 쉽게 만들려면 수정할 일이 많은데 수정으로 프로그램이 느려질수도 있다.
설계의 순수성을 강조하더라도 성능을 무시하는건 이론을 가르치는 교수나 하는 말.
더 좋은 성능을 포기해선 안된다.
성능 개선에서 재밌는 사실은 대부분의 개발자들이 코드를 분석할 때 작은 코드 조각에 얽메여 있다는 것이다.
모든 코드를 최적화한다고 했을 때 그 최적화 중 90%는 실행될 일이 거의 없는 코드를 최적화하는 의미없는 일이다.
성능과 관련해선 프로그램의 시간과 공간을 알수있는 프로파일러 하에 프로그램을 실행해야 한다.
이렇게하면 성능에 영향을 주는 프로그램의 작은 부분을 찾을 수 있고 그 부분에 대해 최적화를 적용한다.
리팩토링으로 작은 부분을 쪼개고나면 성능 분석을 더 정밀하게 할 수 있고 튜닝도 쉬워진다.
reference
- 마틴 파울러, 리팩토링 2장