Refactoring

[리팩터링 2판] 2장

ㅋ. ㅋ 2023. 2. 21. 16:25

2장 리팩터링 원칙

리팩터링 적용 원칙에 대하여

2.1 리팩터링 정의

그냥 코드 정리하는게 아닌 특정 방식을 따른 정리만이 리팩터링

리팩터링 동안에는 항상 코드가 정상 작동해야함. 따라서 '리팩터링 하다 코드가 깨졌다'라는 말은 없음. 재구성이라 봐야함

2.2 두개의 모자

2.3 리팩터링 하는 이유

소프트웨어 설계가 좋아짐 : 코드 설계 파악 및 설계 용이, 중복 코드 제거함으로써 실수 감소
소프트웨어를 이해하기 쉬워짐
버그를 쉽게 찾을 수 있음
프로그래밍 속도를 높일 수 있음
기능 추가 시간 단축, 버그 수정 시간 단축 -> 개발 기간 단축
리팩토링 시 오히려 시간이 오래 걸리지 않나?
- 리팩토링 x : 새 기능 추가 시 기존 코드베이스에 녹여내는 방법 찾기, 그로 인한 버그 발생
- 기능 추가의 어려움
- 리팩토링 o : 내부설계가 잘 된 소프트웨어, 모듈화가 되어있으면 전체 코드베이스 중 일부 지점만 이해/수정 가능

2.4 언제 리팩터링 해야할까?

비슷한 일을 3번째 하게 된다면 리팩터링 하기 (스트라이크 3번이면 리팩터링)
준비를 위한 리팩터링 - 기능을 쉽게 추가하게 만들기 : 복제된 코드를 한 곳에 모아야한다
이해를 위한 리팩터링 - 코드를 이해하기 쉽게 만들기 : 구조 파악, 함수명/변수명 명확하게, 긴 함수 나누기
쓰레기 줍기 리팩터링 : 원래 하던 일 중 발견하게 되는 복잡한 로직, 중복 함수 등 고치기와 같은 일을 간단하면 즉시 고치고 복잡하면 메모만 적고 하던 일 다 끝나면 처리하기. 조금이나마 개선해두기
계획된 리팩터링과 수시로 하는 리팩터링 : 리팩터링은 수시로. 계획된 리팩터링을 최소한으로. 리턱터링/feat 커밋 나누는게 꼭 좋지만은 않을 수 있으니 상황에 팀에 맞게 적용할 것
오래 걸리는 리팩터링 : 라이브러리 교체 시 기존 것, 새 것 모두 포용하는 추상 인터페이스 마련. 기존 코드가 추상 인터페이스 호출 하도록. (추상화로 갈아타기)
코드 리뷰에 리팩터링 활용하기 : 정기적 코드리뷰 좋음. 다른 사람의 아이디어 획득 가능.
리팩터링 하지 말아야 할 때 : 리팩터링보다 새로 작성하는 게 쉬울 때,

2.5 리팩터링 시 고려할 문제

2.6 리팩터링, 아키텍처, 애그니(YAGNI)

2.7 리팩터링과 소프트웨어 개발 프로세스

2.8 리팩터링과 성능

리팩더링을 하면 성능 저하가 될 수 있지만 튜닝하기 쉬워짐, 리팩터링 후 성능 개선을 위한 튜닝을 하기
코드의 극히 일부에서 대부분의 성능 저하를 일으킴
고른 코드의 최적화는 소용이 없음
리팩터링 완료 후 프로그램 튜닝 절차
1. 프로파일러를 통해 프로그램을 분석해 시간, 공간을 많이 쓰는 지점 찾기
2. 해당 부분 개선, 작은 단계로 나눠 컴파일, 테스트를 진행
3. 개선이 되지 않았다면 원복
리팩터링 시 최적화에 도움이 되는 2가지 측면
1. 성능 튜닝 시간을 벌 수 있다. (기능 추가가 빠르게 끝나 튜닝시간이 늘어남)
2. 성능을 세밀하게 분석할 수 있다. (프로파일러가 지적해주는 코드의 범위가 더 좁아짐)

2.9 리팩터링의 유래

2.10 리팩터링 자동화

자동리팩터링 지원 도구 등장
어설픈 자동 리팩터링 방법 : 소스코드 텍스트 직접 조작 (찾아 바꾸기, 변수 추출을 위해 코드를 재구성) <- 허점이 많기 때문에 테스트 전에 결과를 신뢰 x