리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
6.6 변수 캡슐화하기
•
함수는 데이터보다 다루기 수월하다
◦
전달 함수(feature flag와 비슷하게 느껴짐)를 써서 치환할 수 있다
◦
데이터는, 전달 함수 같은게 없이, 한번에 바꿔야 하는데 접근 영역이 넓을 수록 제어하기 어렵다
•
데이터를 함수로 캡슐화하면 감시가 쉽다 ?
•
유효범위가 넓다면(함수 하나보다) 데이터를 게터, 세터로 캡슐화하자
•
변수 접근 범위를 제한하는 방법; 변수 이름을 바꿔서 테스트를 돌려보자
◦
눈에 띄는 이름으로 바꿔 보자…?
•
값 캡슐화하기
◦
게터/세터에서 복사본을 반환한다
6.7 변수 이름 바꾸기
6.8 매개변수 객체 만들기
•
데이터 구조를 하나로 모은다
◦
함수들이 사용하는 이름을 통일할 수 있다
•
데이터에 공통으로 적용되는 동작을 함수로 만들 수 있다
◦
데이터 클래스 → 클래스(”진정한 객체”)로 가는 발판이 된다
6.9 여러 함수를 클래스로 묶기
•
공통적으로 넣어주는 함수 인수가 있을 때 그 함수들을 묶고 싶다
•
이어서 함수로 묶기도 있지만 클래스를 더 선호
◦
객체 데이터 변경이 가능하다
◦
파생 객체를 관리할 수 있다
•
◦
리액트 함수형 컴포넌트; 훅을 쓰기 때문에 완전히 같진 않다
◦
vue composable api 가 더 그렇다. 현대적인 function as object 패턴입니다 by gpt
•
객체에 불변성이 없다면, 객체 바깥에서 데이터 갱신의 가능성이 있다면, 클래스로 캡슐화 하는게 더 낫다
6.10 여러 함수를 변환 함수로 묶기
•
변환 함수 원본 데이터를 받아 복사한 후 (여러) 함수에서 변환하여 출력으로 반환
•
작명
◦
덧붙이는 변환함수: enrich
◦
데이터 형태가 변하면: transform
6.11 단계 쪼개기
•
여러 단계가 순차적으로 연결된 형태라면 각 단계에서의 수정이 더 용이하다
◦
e.g. 컴파일러: 토크나이즈 → ast 파싱 → ast 변환 …
느낀점
•
•
“이름 앞에 타입을 드러내는 문자를 붙이는 스타일 선호한다”
◦
관사 이야기?
◦
영알못이라(영어권이 아니라) 그런지 와 닿지 않는다
◦
변수에만 강제적으로 다 쓰면 좋을거 같기도 한데 pluralize까지 생각하면 또 모르겠다
•
“상수 이름 바꾸기”처럼 아주 작은 단위의 임시 변수 swap이 좋은지 모르겠다
◦
lsp 기능 + 정적 검사(타입) + 테스트로 충분치 않나
•
매개 변수 객체 만들기가 프론트 작업하면서 가장 많이 공감이 갔다.
◦
데이터 구조를 하나로 모은다
▪
함수들이 사용하는 이름을 통일할 수 있다
◦
데이터에 공통으로 적용되는 동작을 함수로 만들 수 있다
▪
데이터 클래스 → 클래스(”진정한 객체”)로 가는 발판이 된다
◦
◦
▪
리액트 함수형 컴포넌트; 훅을 쓰기 때문에 완전히 같진 않다
▪
vue composable api 가 더 그렇다. 현대적인 function as object 패턴입니다 by gpt
•
단계 쪼개기가 규칙화하기 어렵고 이 단원에서 가장 어려운 유형의 리팩터링으로 느껴진다
◦
단계라는 다소 추상적인(리팩터링 전에는 엄청 그럴듯) 개념을 구체화 시키는게 중요한거 같다
▪
여기서는 리팩터링 잘게 나누는게 유효할 수 있을것도 같다
◦
중간 데이터와 함수의 이름이 그 역할을 할 수 있을거 같다
◦
상품 결제 금액 - (할인, 수량 등) 가격 데이터 → 배송 가격 적용
◦
명령줄 프로그램 - 명령줄 인수, 옵션 플래그, 파싱 → 데이터 가공(주문 세기)
▪
변환기: 클래스로 단계 추상화