리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
6장 이후로 각 기법의 절차, 예시보단 배경 위주로 정리한다.
리팩터링 기법 명칭은 빨간색으로 표시한다.
11.3 플래그 인수 제거하기
•
함수 실행 로직을 호출하는 쪽에서 선택하기 위해 전달하는 인수를 제거하자
•
호출을 단순하게 만들기 위함
11.4 객체 통째로 넘기기
•
매개변수 목록을 자주 수정하지 않도록
•
레코드 의존성을 낮추려면 하지 않는다
•
다른 객체의 메소드에 자신의 필드를 여럿 보낸다면 자신(this)을 보내자
11.5 매개변수를 질의 함수로 바꾸기
•
호출을 단순하게 만들기 위함
11.6 질의 함수를 매개변수로 바꾸기
•
위와 반대되는 리팩터링이지만, 함수 참조 투명성을 해치는 경우 그 참조를 매개변수로 바꾼다
11.7 세터 제거하기
•
필드를 생성자에서만 설정하고 수정하지 않을 때(또는 그럴 것이다)
11.8 생성자를 팩터리 함수로 바꾸기
•
언어의 생성자를 더 유연하게 사용하기 위해 함수로 정의
11. 9 함수를 명령으로 바꾸기
•
함수를 위한 캡슐화
◦
복잡성이 증가하는걸 원치 않으면 일급함수 사용을 고려해보자
11.10 명령을 함수로 바꾸기
•
복잡하지 않은 연산은 명령 객체 대신 함수로 바꾼다
11.11 수정된 값 반환하기
11.12 오류 코드를 예외로 바꾸기
11.13 예외를 사전확인으로 바꾸기
느낀점
•
당연히 그렇게 하지 않나 싶은 리팩터링들; 11.6, 11.11, (11.13)
◦
그렇게 생각이 바뀌어가는(책을 읽으며 점점 선호되는) 리팩터링; 11.4
•
플래그 인수
◦
변수 또는 리터럴 조차 의미 있는 상수로 만들어서 보내면 되는거 아닌가?
▪
display(node: Node, verbose: bool)
◦
인터페이스에선 (지원하는 언어라면) named arg 사용해도 좋을 것
•
객체 통째로 넘기기를 수행하다 보면 메소드 추출이 되기도 한다
◦
로직이 있어야 할 곳을 잘못 고른 경우
◦
메소드 결과가 인수가 되기도 한다
•
11.5 와 6은 결국 함수가 접근할 수 있는 스코프의 문제 같다.
◦
캡슐화가 잘 되어 접근 가능한 영역에선 5를 해야하지만
◦
6은 당연히 하면 안된다(물론 매번 내가 그렇게 잘한다 라는 뜻은 아니지만, 예시에선 보이지 않는 참조가 그냥 전역 변수로 보여서…)
•
스크립트 예시: fluent builder api
◦
+ 무지성 세터 선언을 하지 말자
•
팩터리 함수 == 다형성이라고 생각했는데 함수가 되는 것만으로도 유연하게 쓸 여지가 있다(그럼에도 예시는 결국 다형성에 대한 것이었다..)
•
책의 예시를 일급함수 실행으로 바꾸면?
◦
execute(fn, params)? 무슨 이점?
•
커맨드 패턴; 명령 객체가 효과를 보는 더 구체적이고 확장된 예시◦
state를 갖게 된다
▪
독립 실행
•
패턴에선 invoker와 receiver 가 있다
▪
원격 실행, 큐잉(지연, 예약 실행), 로깅 ← 직/역직렬화
▪
undo
•
가능하면 예외 던지기를 안하려고 했었다.
◦
프레임워크가 처리하는 경우를 빼고 대부분 오류는 예측 되는 경우였다
◦
api 코드를 많이 안 만들었던 듯
◦
go는 예외가 아닌 오류를 바로 받아서 처리하거나 열심히 올려줘야 한다