리팩터링 2판 스터디 - 12

리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.

6장 이후로 각 기법의 절차, 예시보단 배경 위주로 정리한다.

리팩터링 기법 명칭은 빨간색으로 표시한다.

변수 스코프 내에서 두 가지 목적으로 사용되는 변수를 각각의 이름으로 바꿔준다. 예시처럼 temp를 선언하고 여러 번 쓰거나 함수에서 result를 만들어가는 중간 과정이 있는 경우가 대다수 일거 같다.

‘쉽게’ 바꿀 수 있다는 역시 코드로써 다룰 수 있음을 말한다. 캡슐화가 우선되어야 한다. 바꾸려는 필드의 레코드 스코프가 좁다면 캡슐화 없이도 쉽게 바꿀 수 있다.

getter는 단순히 변수를 반환하고 다른 곳 또는 여러 다른 곳에서 해당 변수를 바꿀 때 필요하다. 질의 함수는 getter가 아니라 다른 곳에 있는 연산을 인라인 한다. 경우에 따라 getter 이름을 그대로 쓰거나 더 명확한 질의 함수 이름을 쓴다.

참조와 값 둘 다 뒤에 ‘객체’가 생략되어 있다. 불변 즉, 코드에서 읽기만 하는 것(객체)이라면 해당 객체를 참조할 필요가 없다(참조는 객체가 바뀔 때 어느 곳에서 바뀌어도 적용되게 하기 위함이다).

값으로 바꿀 수 있는 것 뿐만 아니라 값으로 바꾸는게 나은 상황도 있다. 즉, 어디선가 변경하고 있지만 값 객체로 쓰는 것이 나을 경우 (아직 클래스가 아닐 경우)변경, setter를 제거한다.

동치성 메소드 또는 연산자를 만들어 값이 속성의 비교로 동일함을 보장해야한다.

위와 반대의 상황, 쓰기(갱신)가 여러 번, 여러 곳에서 일어날 수 있다면 값 대신 참조 객체를 사용해야한다. (불변으로 다뤄야 할) 값 객체를 쓴다면 복사 후 바꾸고 원본 갱신도 따로 해주어야한다.

참조 객체를 한 곳에서 관리할 수 있도록 저장소를 만든다.

martinfowler.comRepository 참조 객체는 저장소에서 찾아 읽을 수 있고 쓰기 역시 그 저장소 위치의 객체를 갱신한다.

•

리터럴 값의 의미를 모를 때 상수로 써준다.

•

리터럴에 대한 비교 로직이 자주 쓰이는 곳은 상수 대신 함수 호출을 한다.

•

리터럴 그대로를 상수 이름으로 쓰는 남용을 하지 않는다.

•

반환 값이 있는 함수는 함수 선언과 동시에 상단에 let result 를 쓰는 것이 좋을듯 하다.

•

temp 는 변수 쪼개기를 하기에 그러라고 선언한 변수가 아닌가 싶다. 물론 각각 중간 단계의 의도가 더 드러나는 이름을 쓰는 것이 명확하긴하다.

•

lsp rename(vscode F12)는 (필드) 이름 바꾸기의 ‘스코프’를 넓혀 ‘쉽게’ 한다.

•

‘파생 변수를 질의 함수로 바꾸기’라는 이름은 좀 어렵다. 절차를 보면 더 그러하다. ‘값을 바꾸는 곳이 멀리 떨어져 있는데에 대한 부작용을 줄인다’(말은 더 길다)가 낫지 않나…

◦

useState → useReducer(dispatch 호출)와 비슷하다; reactjsuseReducer – React

•

5와 6은 (특히 최근) 둘의 차이를 크게 체감 못하고 있었다.

◦

일단 변수에 대한 이야기이고 객체일거라고 생각 못했다.

◦

go에선 참조(포인터) 위주로 들고 다니는거 같다; 라이브러리가 그렇게 반환하는 것이 더 많은 듯

◦

react에서는 setstate 쓰느라 갱신에 크게 신경 안쓴 듯