[REFACTORING] 1장 리팩터링: 첫 번째 예시(~1.4)

컴파일러는 코드가 깔끔하든 지저분하든 잘 작동함

그 코드를 수정하는 것이 사람이기 때문에 정리할 필요성이 있음

 

프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 리팩터링한 후 기능을 추가한다

수백 줄짜리 코드를 수정할 때에 프로그램의 작동 방식을 쉽게 파악할 수 있도록 코드를 재구성하고,

프로그램 구조가 빈약하다면 구조를 잡은 뒤 수정하는 것이 작업하기 수월함

 

한 번 작성한 코드를 다시 볼 일이 없다면 상관 없지만

다른 사람이 읽고 이해해야 할 일이 생겼는데 로직을 파악하기 어렵다면 수정이 필요함

 

 

예시 코드 리팩터링 순서

테스트 코드 만들기

함수 전달인자와 결괏값 몇을 미리 작성하고 단축키로 테스트를 실행할 수 있도록 설정

성공/실패에 따라 색상을 부여하여 테스트 결과를 한눈에 알아볼 수 있도록 만들기

 

테스트 작성하는데 시간이 걸리지만 디버깅 시간이 줄어서 작업 시간 단축에 도움 됨

 

** 작업 하나(ex. 한 변수 이름 수정) 진행할 때마다 컴파일-테스트-커밋하기 **

 

함수 추출하기

긴 함수를 리팩터링할 때는 특정 동작을 하는 코드를 별도 함수로 추출하고 그 코드가 하는 일으로 이름 짓기

 

새 함수에서 곧바로 사용할 수 없는 변수가 있는지 확인하여

- 새 함수에서 값을 변화시키지 않는 변수면 매개변수로 받아 사용

- 값이 바뀌는 변수라면 주의해야 함(새 함수 내부에 변수 선언)

 

수정 후에는 바로 컴파일하고 테스트하여 실수한 내용이 없는지 확인

한 가지를 수정할 때마다 테스트하면 오류가 생겨도 변경 폭이 작아 문제를 찾고 해결하기 쉬움

한 번에 너무 많이 수정하려다 실수한다면 디버깅이 어려워 오히려 작업 시간이 늘어나게 됨

조금씩 변경하고 매번 테스트하는 것이 리팩터링 절차의 핵심

 

문제가 없다면 로컬 버전 관리 시스템에 커밋

어느 정도 커밋이 쌓이면 공유 저장소로 푸시

 

함수 추출하기는 IDE(Integrated Development Environment. 통합 개발 환경)에서 자동으로 수행해 줌

 

 

 

변수 인라인하기

값이 바뀌지 않거나 여러 번 사용하지 않는 변수 없애고 인라인하기

지역 변수를 줄이면 유효 범위를 신경 써야 할 대상이 줄어 추출 작업이 쉬워짐

 

함수 선언 바꾸기

함수 이름을 코드를 읽지 않고도 무슨 일을 하는지 알 수 있는 이름으로 짓기

- 당장 떠오르는 최선의 이름으로 사용하다가

- 더 좋은 이름이 떠오를 때 바꾸기

 

반복문 쪼개기

한 반복문 안에서 실행되던 두 기능을 두 반복문으로 분리하기

반복문이 중복되어 성능이 느려지지 않을까 우려될 수 있지만 성능에 미치는 영향이 미미할 때가 많음

실제로 이 리팩터링으로 인해 성능이 크게 떨어졌다면 

- 성능 개선을 위해 코드를 수정하거나

- 이전 코드로 되돌리기

 

대체로 리팩터링 덕분에 성능 개선을 더 효과적으로 수행할 수 있음

→ 성능 문제는 일단 무시하고 리팩터링 후 성능이 떨어진다면 개선하기

 

리팩터링 중간에 테스트가 실패하고 원인을 바로 찾지 못한다면

가장 최근 커밋으로 돌아가 리팩터링 단계를 더 작게 나눠 다시 시도하기

 

- 이 책에서 나오는 코드 스타일

함수의 반환 값(변수)에 result라는 이름 주기

매개변수 이름에 타입을 접두어로 설정하기(헝가리식 표기법 → 옛 방식)

 

 

 

 

2023.04.19~ 04.22