해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.
소스
8.1 함수 옮기기
- 대상 함수의 현재 컨텍스트, 후보 컨텍스트를 둘러본다. 함께 옮길만한 요소가 있는지 둘러보기.
- 선택한 함수가 다형 메소드인지 확인
- 선택한 함수를 타깃 컨텍스트로 해당 영역에 맞도록 다듬는다.
- 소스 컨텍스트에서 타깃 함수를 참조할 방법을 찾아 반영한다.
- 소스 함수를 타깃 함수의 위임 함수가 되도록 수정한다.
8.2 필드 옮기기
- 필드가 잘못되었을 때
- 구조체 여러 개에 정의된 똑같은 필드들을 갱신해야하는 경우
- 한 레코드를 변경할 때 다른 레코드의 필드까지 변경해야하는 경우
- 캡슐화 작업
- 테스트
- 타깃 객체에 필드, 접근자 메소드를 생성한다.
- 소스 객체에서 타깃 객체를 참조할 수 있는지 확인
- 접근자들이 타깃 필드를 사용하도록 수정한다.
- 소스 필드 제거
8.3 문장을 함수로 옮기기 (<-> 8.4 문장을 호출한 곳으로 옮기기)
문장이 피호출 함수의 일부라는 확신이 있는 경우 문장들을 함수 안으로 옮긴다.
8.4 문장을 호출한 곳으로 옮기기 (<-> 8.3 문장을 함수로 옮기기)
- 작은 변경: 문장을 호출한 곳으로 옮기기
- 호출자와 호출 대상의 경계를 완전히 그어야하는 경우: 함수 인라인 + 문장 슬라이드 + 함수 추출하기
8.5 인라인 코드를 함수 호출로 바꾸기
8.6 문장 슬라이드하기
- 조건문이 있을 때의 슬라이드
- 조건문 밖으로 슬라이드: 중복 로직 제거
- 조건문 안으로 슬라이드: 중복 로직 추가 - 문장 교환하기: 인접한 코드 조각을 이동하지만, 문장 하나짜리 조각만 취급한다. (작은 단위)
8.7 반복문 쪼개기
반복문에서 2가지 일을 수행하는 경우 각각의 반복문으로 분리해두는 것이 좋다. 이 방법이 추후 코드를 이해하고 사용하는 것이 더 쉬워지기 때문.
반복문을 분리한 후 함수로 분리할 지도 나중에 생각해보는 것이 좋다.
이 리팩터링이 불편하다고 느낀다면 최적화와 리팩터링을 구분하자.
최적화는 코드를 깜끔히 정리한 이후 수행하는 것으로 코드가 깔끔하게 정리된 후 반복문을 분리한 작업이 불필요하다고 느껴지면 그 때 다시 합치면 된다.
8.8 반복문을 파이프라인으로 바꾸기
반복문을 파이프 라인으로 바꾸자.
8.9 죽은 코드 제거하기
버전 관리 시스템이 보편화 된 지금, 나중에 사용할 코드임을 염려하여 코드를 그대로 두거나 주석으로 처리할 필요가 없다.
모듈성: 프로그램의 어딘가를 수정하려 할때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력
정적분석: 실제 실행없이 소프트웨어를 분석하는 것
zero-base 한달한권 | 리팩터링
- 코드 깨짐 -> "부수 효과" 로 표현하자.
08. 기능 이동 을 읽고..
이 글의 저자는 변수를 최상단에 전부 선언해서 사용하는 것이 아닌, 사용하기 직전에 선언하는 방식을 선호한다고 하였다.
나의 이전 코드스타일은 이 글의 저자처럼 사용하기 직전에 선언하는 방식을 선호했고, 같이 일했던 사람은 이 방식을 선호하지 않아 의견 차이가 발생한 경험이 있다.
무조건 저자의 의견에 따르지 말고 협업하는 사람과 스타일을 맞추고 어떤 방식이 올바른지 스스로 생각해보기 바란다.
