Martin Fowler - Refactoring을 읽고 정리한 글입니다.(137~139p)
Motivation
네이밍을 잘하는 것은 clear programming의 핵심이다. 이름을 잘 지은 변수들은 아주 많은 것을 설명할 수 있다.
하지만 종종 변수이름을 잘못 짓는다.
- 충분히 생각하지 않았을 수 있다.
- 내가 더 배울수록 문제에 대한 이해가 깊어지기 때문에 잘 지을 수 있다.
- 유저의 니즈에 의해서 프로그램의 용도가 변경된 경우.
심지어 대부분의 프로그램 요소들보다도, 이름의 중요성은 그것이 얼마나 널리 사용되느냐에 달려있다.
one-line lambda expression에 사용되는 변수는 대개 따라가기(이해하기) 쉽다.
- Users.map((u)=>u.id)
- 이렇게 용도가 확실한 경우에는 한글자짜리 변수를 쓰는것도 괜찮다.
자바스크립트처럼 동적 프로그래밍 언어에서는 타입을 변수명에 넣기도 한다(aCustomer)
단일 함수 호출 이상으로 지속되는 영구 필드(여러 스코프에 걸쳐서 사용되는 변수)에는 보다 세심한 이름 지정이 필요하고 여기에 집중한다.
Mechanics
변수가 널리 사용되면, 변수 캡슐화를 고려한다.
변수의 모든 레퍼런스를 찾아서 바꾼다.
- 만약 다른 코드베이스에 있으면 그 변수는 published variable이므로 리팩토링 불가
- 변수가 바뀌지 않으면, 새로운 이름으로 바꾸고, 점진적으로 변화시키고, 바꿀때마다 테스트한다.
테스트한다
Example
보통은 그냥 찾아서 바꾸면 됨. 하지만 문제는 단일 함수 이상일때.
어떤 코드는 변수에 접근하고, 어떤 변수는 업데이트한다. 이럴땐 변수 캡슐화를 주로 함.
그리고 이 타이밍에 변수이름을 바꿔줌.
래핑해주는 펑션을 인라인으로 할수도 있었다. 이렇게하면 모든 콜러가 변수를 직접 갖다쓸수있다. 하지만 이렇게 잘 안한다. 변수가 널리 사용되면 이름을 바꾸기위해 캡슐화한다. 함수에 캡슐화하는걸 유지하는건 미래를 위해 가치있는 일이다.
인라인으로 할땐 언더바 안씀.
const쓰면 캡슐화 안할수도 있다. 그래도 점진적 리네이밍은 한다. 리네이밍하고 원래 변수에 대입해줌.
이렇게하면 오래된 이름에서 새 이름으로 점진적으로 바꿀수있다. 끝나면 옛날걸 지운다.
클라이언트에게만 읽기 전용인 변수뿐만이 아니라, 상수에도 효과가 있다.
'Web development > Books' 카테고리의 다른 글
Refactoring - Inline Class (0) | 2019.12.31 |
---|---|
Refactoring - Encapsulate Collection (0) | 2019.12.31 |
Refactoring - Introduce Parameter Object (0) | 2019.12.31 |
Refactoring - Building Test (0) | 2019.12.31 |
Refactoring - Bad Smells (0) | 2019.12.31 |
댓글