[개발] 리팩토링 정리

리팩토링 프로그램의 가치를 높이는 코드 정리 기술 - http://www.yes24.com/24/goods/7951038

마틴 파울러 저/김지원 역, 한빛미디어

Chapter 01 - 맛보기 예제

리팩토링 작업의 첫 단계는 늘 똑같다

리팩토링할 코드 부분에 대한 신뢰도 높은 각종 테스트를 작성하는 것이다

대개 리팩토링 기법을 실시하면 코드 양이 줄게 마련인데 방금의 리팩토링은 오히려 코드가 늘었다.

또 한가지 문제점은 성능이다. 수정 전 코드는 while 문 루프를 1회만 실행했는데 수정 후 코드는 3회나 실행한다

타 객체의 속성을 switch 문의 인자로 하는 것은 나쁜 방법이다

하위 클래스를작성해 상속 구조를 만들면 switch 문을 재정의로 바꿀 수 있다

예제의 리팩토링을 위해 매서드 추출, 매서드 이동, 조건문을 재정의로 전환 같은 몇 가지 기법을 사용했다.

기능 분배가 균등해지고, 코드 유지보수도 쉬워진다. 

절차적 코드에 익숙한 사람은 생소해서 적응에 시간이 걸리지만, 일단 익숙해지면 오히려 절차적 코드가 더 낯설어 보일 것이다.

가장 중요한 교훈은 '간단한 수정->테스트'를 리듬처럼 반복한다는 것이다.

Chapter 02 - 리팩토링 개론

리팩토링은 주로 소프트웨어를 조금 수정하는 작업을 뜻한다.

리팩토링은 단순한 코드 정리보다는 더 포괄적인 개념이라고 할 수 있다

리팩토링의 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다. 리팩토링은 성능 최적화에 상반된다.

리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다

소프트웨어 개발에 리팩토링을 적용할 때 기능 추가와 리팩토링이라는 별개의 두 작업에 시간을 분배해야 한다.

리팩토링을 실시하면 코드는 더 파악하기 쉬워진다

난 뛰어난 프로그래머는 아니고, 단지 습관을 잘 들인 착실한 프로그래머다 - 켄트벡

리팩토링이 코드를신속하게 개발할 수 있게 만들어 준다는 것이다

리팩토링하면 코드 품질이 좋아진다는 사실은 쉽게 이해한다.

이런 품질 향상 요소로 인해 개발 속도가 느려지는 것은 아닌가 하는 점이다.

깔끔한 설계야말로 소프트웨어 개발 속도를 높이기 위한 핵심

깔끔한 설계는 전적으로 신속한 개발을 목적으로 한다

리팩토링을 일부러 시간 내서 하진 말라고 답한다. 일상적으로 틈틈이 해야 한다.

처음 할 땐 그냥 하고, 두 번째 해야 할 땐 중복 작업이라 좀 망설여져도 일단 그냥 하고, 세 번째 하게 되면 그 때 리팩토링을 실시하는 것이다.

리팩토링이 필요한 첫 번째 상황은 소프트웨어에 새 기능을 추가해야 할 때다.

버그를 수정할 땐 주로 코드를 이해하기 쉽게 만들려고 리팩토링한다.

일부 업체에선 정기적으로 코드를 검수한다.

프로그램이 지닌 가치는 두 종류다.하나는 현재의 기능이라는 가치이고, 또 하나는 미래의 기능이라는 가치다

프로그래머가 품질에 대해 압박을 받는다지만 일정에 대한 압박만 못하다

코드는 반드시 제대로 돌아가는 것이 우선이고, 리팩토링은 나중 일임을 명심하자.

납기가 임박했을 때도 리팩토링은 삼가야 한다.

리팩토링이 사전 설계를 대체할 수 있다는 일각의 주장도 있다. 설계 대체 리팩토링 방식도 인정할만하다.

리팩토링하지 않을 때는 사전 설계를 정확히 해야 한다는 부담감이 크다

작업 중점 이동으로 얻게 되는 장점은 설계가 단순해진다는 점이다

시스템 내부가 어떻게 돌아가는지 정확히 알고 있더라도 추측하지 말고 성능 측정을 실시해야 한다.

리팩토링이 소프트웨어 개발 기간을 단축하는 데 도움이 됨을 알았다. 

리팩토링하는 동안에는 단기적으로 소프트웨어가 느려지지만, 최적화를 거치면서 튜닝하기가 쉬워져서 결과적으로는 소프트웨어 개발이 더 빨라진다.

Chapter 03 - 코드의 구린내

리팩토링을 어떨 때 시작하고 어떨 때 그만둬야 할지 판단하는 일은 리팩토링 기법을 적용하는 방법만큼 중요하다

인스턴스 변수가 너무 많다는 건 도대체 몇 개부터를 의미하는지, 메서드가 장황하다는 건 도대체 코드가 몇 줄 이상을 의미하는지

구린내의 제왕은 중복 코드다

한 클래스의 두 메서드 안에 같은 코드가 들어 있는 경우다

객체를 처음 접하는 개발자는 객체 프로그램을 보고는 기능이 거의 없는 메서드가 서로 위임만을 일삼고 있다고 생각한다.

프로그램 개념이 생겨났을 때부터, 오래된 언어일 수록 하위 루틴 호출할 때 오버헤드가 수반됐고 짧은 메서드를 기피했다.

주석을 달아야 할 것 같은 부분에 주석을 넣는대신 메서드를 작성한다.

초보 시절 루틴에 필요한 모든 걸 매개변수를 사용해 전달하라고 배웠다 당시엔 이것이 당연했다.

매개변수를 사용하지 않으면 전역데이터를 사용해야 하고 바람직하지 않다.

객체의 등장으로 상황은 달라졌다.

객체지향 코드의 확연한 특징 중 하나는 switch-case 문을 적게 사용한다는 점이다.

대부분의 switch 문은 고민할 필요 없이 재정의로 바꿔야 한다.

Chapter 04 - 테스트 작성

리팩토링을 실시하기 위한 전제조건은 견고한 테스트를 해야 한다는 것이다.

기능을 추가해야 할 때는 우선 테스트부터 작성하자. 해야 할 작업이 무엇인지 자문하게 된다. 인터페이스에 집중하게 된다.

리팩토링엔 테스트가 필수다

참고자료

나쁜 디자인 코드를 좋은 디자인으로 바꾸는 방법 - http://pds26.egloos.com/pds/201301/18/75/Refactoring_Part_2.pdf

코드 리뷰 사례로 알아보는 좋은 JavaScript 코드 - https://cimfalab.github.io/deepscan/2016/09/code-review-2