Refactoring_01.리팩터링 기본

Refactoring 2판, 마틴 파울러, 요약 정리

01.리팩터링 기본

~p.78

 

만약 프로그램이 새 기능을 추가하기 복잡한 구조라면, 먼저 기능을 추가하기 쉬운 구조로 리팩터링한 다음 원하는 기능을 추가한다

 

리팩터링의 첫 단계는 리팩터링 코드 영역을 검사할 테스트 코드부터 짠다. 테스트의 성공 여부 확인은 자동화시켜서 효율을 높인다. 리팩터링 코드가 정상 작동되는지 비교 확인할 수 있기 때문이다

 

리팩터링을 할 때 작은 단계로 수정 후 바로 테스트를 진행한다. 작게 수정했을 때 발생한 문제는 금방 해결할 수 있기 때문이다. 

 

Git은 리팩터링 하나 했을 때 바로바로 커밋하고, 자잘한 변경들이 유의미한 단위로 뭉쳐지면 푸시한다

 

매개 변수 대신 질의 함수로 바꾸기

• 질의 함수 : 값을 계산하여 리턴하는 함수
• 질의 함수에 부수효과가 없다면 변수에 저장해서 호출하지 말고 그냥 함수를 바로 변수로 사용해서 로컬 변수를 줄임

 

좋은 코드는 수정하기 쉬운 코드

• 코드 수정을 해야할 때 고칠 곳을 빠르게 찾아 수정할 수 있다면, 생산성을 올리고 고객에게 필요한 기능을 낮은 비용으로 제공할 수 있기 때문

 

리팩터링 요소

• 구조 : 더 기능 추가하기 쉬운 구조로 바꿀 수 없는가?
• 분해 : 이를 위해 더 쪼갤 수 있는가?
• 이름 : 함수명, 변수명을 더 명확하게 바꿀 수 있는 곳은 없는가? ex) 반환값은 -> result, 매개변수 역할 뚜렷하지 않는 경우 부정 관사(a/an) 붙여서 -> ePerformance
• 질의함수 : 질의 함수(값을 계산하여 리턴하는 함수)로 바꿀 수있는 매개 변수가 있는가?
• 이해 : 코드 기능 이해하기 쉬운가? 의도가 명확한가?

 

Quotes

• 간결함이 지혜의 정수일지 몰라도, 프로그래밍에서만큼은 명료함이 진화할 수 있는 소프트웨어의 정수다
• 캠핑장에 도착했을 때보다 깔끔하게 정돈하고 떠나듯, 프로그래머도 코드베이스를 작업 전보다 건강하게(Healthy) 만들어놓고 떠나야 한다

02. 리팩터링 원칙

 

리팩터링 정의

• 소프트웨어의 외부 동작은 유지한 채, 코드를 이해하고 수정하기 쉽게 내부 구조를 바꾸는 기법

 

리팩터링의 목적

• 개발속도 향상. 더 적은 노력과 효율적인 구조로 가치를 더 창출하기 위함(경제적 목적)

 

두 개 모자

• 소프트웨어 개발 목적은 1)기능 추가와 2)리팩터링, 2가지다. 개발을 하다보면 두 모자를 자주 바꿔서 작업하게 된다

 

리팩터링 해야할 때(Don Roberts가 알려주는)

• 처음엔 그냥 한다
• 두 번째 중복을 봐도 일단 계속 진행한다
• 비슷한 작업을 세 번째 할 때 비로소 리팩터링 한다

 

리팩터링 하지말아야 할 때

• 리팩토링보다 처음부터 작성하는게 더 쉬울 때
• 지저분하지만 단순 외부 api 호출 같이 중요도 낮은 코드의 경우

 

리팩터링 시 고려할 것

• 새 기능 개발 속도 저하. 개발 속도 높여서 가치 창출하는 것이 목표
• 코드 소유권. 수정하고자 하는 코드의 소유권이 내가 아닐 수도 있음.
• 브랜치. 브랜치 작업 후 통합 기간 길어지면 할 일이 더 많아짐. 짧은 시간 내 자주 통합하는 Continuous Integration | Trunk-Based Development(TBD) 방식을 통해 머지 복잡도를 줄이는 것을 추천
• 테스팅. 리팩터링 전 후 겉보기 동작이 같다는 것을 확실히 하기 위해 자가 테스트코드를 마련한다

 

매니지먼트

• 코드 소유권 : 코드 소유권을 너무 쪼개면 관리 복잡도가 증가. 따라서 코드 소유권은 개인이 아닌 팀에 둬서 팀원이라면 모두 수정 가능하도록 하는 느슨한 관리 방식이 더 효율적

 

흥미로웠던 부분

• 리팩토링 여부와 코드베이스의 건강 상태 간 상관관계가 있다
• 켄트 벡이 CI와 리팩터링을 합쳐서 익스트림 프록래밍 eXtreme Programming(XP)을 만든 이유도 바로 이 두 기법의 궁합이 잘 맞기 때문