p.77 리팩터링을 효과적으로 하는 핵심은, 단계를 잘게 나눠야 더 빠르게 처리할 수 있고, 코드는 절대 깨지지 않으며, 이러한 작은 단계들이 모여서 상당히 큰 변화를 이룰 수 있다는 사실을 깨닫는 것이다.
p.81 리팩터링하면 소프트웨어 설계가 좋아진다. 같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 십상이다. 사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다. 그래서 중복코드 제거는 설계 개선 작업의 중요한 한 축을 차지한다. 코드량을 줄인다고 시스템이 빨라지는 것은 아니다. 프로그램의 용량이 속도에 영향을 주는 경우는 별로 없다.
p.82 리팩터링하면 프로그래밍 속도를 높일 수 있다. 내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠 지를 쉽게 찾을 수 있다. 모듈화가 잘 되어 있으면 전체 코드 베이스 중 작은 일부만 이해하면 된다. 코드가 명확하면 버그를 만들 가능성도 줄고, 버그를 만들더라도 디버깅하기가 훨씬 쉽다.
p.87 쓰레기 줍기 리팩터링 코드를 파악하던 중에 일을 비효율적으로 처리하는 모습을 발견할 때가 있다. 로직이 쓸데없이 복잡하거나, 매개변수화한 함수 하나면 될 일을 거의 똑같은 함수 여러개로 작성해놨을 수 있다. 이때 약간 절충을 해야한다. 원래 하려던 작업과 관련없는 일에 너무 많은 시간을 빼앗기긴 싫을 것이다. … 나라면 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 나서 처리한다. 캠핑 규칙이 제안하듯, 항상 처음 봤을 때보다 깔끔하게 정리하고 떠나자.
p.88 리팩터링은 프로그래밍과 구분되는 별개의 활동이 아니다. … 버전관리 시스템에서 리팩터링 커밋과 기능추가 커밋을 분리해야한다는 조언을 들은 적 있다. 이 견해에 동의 하지 않는다. 리팩터링은 기능 추가와 밀접하게 엮인 경우가 너무나 많기 때문에 굳이 나누는 건 시간 낭비일 수 있다. 또한 해당 리팩터링을 하게된 맥락정보가 사라져서 왜 그렇게 수정했는지 이해하기 어려워진다.
p.91 기술을 모르는 상당수의 관리자와 고객은 코드베이스의 건강상태가 생산성에 미치는 영향을 모른다. 이런 상황에서는 리팩터링한다고 말하지 말라
p.91 외부 API 다루듯 호출해서 쓰는 코드라면 지저분해도 그냥 둔다. 내부 동작을 이해해야할 시점에 리팩터링해야 효과를 제대로 볼 수 있다.
p.93 리팩터링의 본질은 코드베이스를 예쁘게 꾸미는 데 있지 않다. 오로지 경제적인 이유로 하는 것이다. 리팩터링은 개발기간을 단축하고자 하는 것이다. 기능 추가 시간을 줄이고, 버그 수정 시간을 줄여준다.
p.94 코드 소유권을 작은 단위로 나눠 엄격히 관리하는데 반대한다. … 코드 소유권을 나눠 관리하면 코드 베이스에서 곧바로 수정하면 훨씬 간단할 일을 계속해서 인터페이스를 관리하느라 시달리게되는 결과를 초래한다. 코드 소유권을 느슨하게 정하는 방식은 여러 팀으로 구성된 조직에도 적용가능하다. 어떤 팀은 다른 팀 사람이 자기 팀 코드의 브랜치를 따서 수정하고 커밋을 요청하는, 흡사 오픈소스 개발 모델을 권장하기도 한다. 이렇게하면 함수의 클라이언트도 바꿀 수 있다.
p.95 버전관리 시스템을 사용하여 팀원마다 코드베이스의 브랜치를 하나씩 맡아서 작업하다가 결과물이 어느정도 쌓이면 마스터 브랜치에 통합해 다른 팀원과 공유… 기능별 브랜치들이 독립적으로 개발되는 기간이 길어질 수록 머지가 복잡해진다. … 지속적 통합(CI)에 따르면 모든 팀원이 하루에 최소 한번은 마스터와 통합해야 한다. 이렇게하면 다른 브랜치들과의 차이가 크게 벌어지는 브랜치가 없어져서 머지의 복잡도를 크게 낮출 수 있다.
p.96 자가 테스트 코드는 리팩터링을 할 수 있게 해줄뿐만 아니라, 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다. 실수로 만든 버그를 빠르게 찾아서 제거할 수 있기 때문이다. 이때 핵심은 테스트가 실패한다면 가장 최근에 통과한 버전에서 무엇이 달라졌는지 살펴볼 수 있다는 데 있다. 테스트 주기가 짧다면 단 몇줄만 비교하면 되며, 문제를 일으킨 부분이 그 몇 줄 안에 있기 때문에 버그를 훨씬 쉽게 찾을 수 있다.
p.99 데이터베이스 리팩터링 기법의 핵심은 커다란 변경들을 쉽게 좝하고 다룰 수 있는 데이터 마이크레이션 스크립트를 작성하고, 접근 코드와 데이터베이스 스키마에 대한 구조적 변경을 이 스크립트로 처리하게끔 통합하는 데 있다. 데이터베이스 리팩터링은 프로덕션 환경에 여러 단계로 나눠서 릴리스하는 것이 대체로 좋다는 점에서 다른 리팩터링과 다르다. …( 심화 공부 필요 )
p.105 성능 최적화를 위한 방법 중 하나. 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다. 성능에 큰 영향을 주는 부분을 찾고 그 부분만 집중해서 최적화한다. 리팩터링 할 때 처럼 최적화를 위한 수정도 작은 단계로 나눠서 진행한다. 각 단계마다 컴파일과 테스트를 거치고 프로파일러를 다시 실행한다.
p.109 자동 리팩터링을 제대로 구현하려면 코드를 텍스트 상태가 아닌, 구문트리로 해석해서 다뤄야한다. 구문 트리를 조작하는 방식이 코드의 원래 의미를 보존하는 데 훨씬 유리하기 때문이다. ( 심화 공부 필요)
Comments powered by Disqus.