Refactoring 2판 마틴파울러 2.5 ~ 정리
특정한 기술, 도구, 아키텍처 등을 내세울 때마다 항상 문제점을 찾는다.
무언가를 언제, 어디에 적용할지 판단하려면 손익을 제대로 이해해야 한다.
리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.
기능 추가부터 하고 싶은 상황에 마주칠 수 있다. 이럴 때는 프로 개발자로서 가진 경험을 잘 발휘해서 결정한다.
내가 직접 건들일 일이 거의 없거나, 불편한 정도가 그리 심하지 않다고 판단되면 리팩터링하지 않는 편이다.
개발팀을 이끌고 있다면 코드베이스가 더 건강해지는 것을 추구한다는 사실을 팀원들에게 명확히 밝혀야 한다.
사람들이 빠지기 가장 쉬운 오류는 리팩터링을 클린 코드(clean code)나 '바람직한 엔지니어링 습관'처럼 도독적인 이유로 정당화하는 것이다.
리팩터링의 본질은 오로지 경제적인 이유로 하는 것이다.
기능 브랜치 방식의 단점
기능별 브랜치의 통합 주기를 2~3일 단위로 짧게 관리해야 한다고 주장하는 사람이 많다.
더 짧은 방식을 지속적 통합(Continuos Integration) 또는 트렁크 기반 개발(Trunk-Based Development)이라 한다.
CI를 잘 적용하기 위해서는, 마스터를 건강하게 유지하고, 거대한 기능을 잘게 쪼개는 법을 배우고, 각 기능을 끌 수 있는 기능 토글(feature toggle, 기능 플래그 feature flag)을 적용하여 완료되지 않은 기능이 시스템 전체를 망치지 않도록 해야 한다.
켄트 벡이 CI와 리팩터링을 합쳐 익스트림 프로그래밍(eXtreme Programming XP)을 만듬.
리팩터링하기 위해서는 (대부분의 경우에) 자가 테스트 코드(self-testing code)를 마련해야 한다.
자가 테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라, 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다.
뛰어난 자동 리팩터링 기능을 제공하는 환경이라면 굳이 테스트하지 않아도 오류가 생기지 않는다고 확신할 수 있다.
자가 테스트 코드는 통합 과정에서 발생하는 의미 충돌을 잡는 메커니즘으로 활용할 수 있어서 자연스럽게 CI와도 밀접하게 연관된다.
레거시 시스템을 파악할 때 리팩터링이 굉장히 도움된다. => 테스트 보강을 통해 리팩터링할 수 있다.
프로그램에서 테스트를 추가할 틈새를 찾아서 시스템을 테스트해야 함.
진화형 데이터베이스 설계(evloutionary database design)와 데이터베이스 리팩터링 기법
수년 동안 운영되던 소프트웨어라도 아키텍처를 대폭 변경할 수 있다.
리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 데 있다.
유연성 메커니즘(flexibility mechanism)의 단점
유연성 메커니즘을 리팩터링을 활용하여 다르게 접근하기
위와 같은 설계 방식을 간결한 설계(simple design), 점진적 설계(incremental design), YAGNI(에그니, You aren't going to need it의 줄임말)으로 부름.
자가 테스트 코드와 리팩터링을 묶어서 테스트 주도 개발(Test-Driven Development)이라 한다.
리팩터링과 YAGNI는 서로 긍정적인 영향을 준다. 리팩터링(과 그 선수 조건들)이 YAGNI의 토대인 동시에, YAGNI로 인해 리팩터링을 더욱 쉽게 할 수 있다.
리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 그와 동시에 성능을 튜닝하기는 더 쉬워진다.
소프트웨어를 빠르게 만드는 비결은, 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.
빠른 소프트웨어를 작성하는 방법 세 가지
프로그램을 잘 리팩터링해두면, 성능 튜닝에 투입할 시간을 벌 수 있다.
리팩터링이 잘 되어 있는 프로그램은 성능을 더 세밀하게 분석할 수 있다.