[REFACTORING] 2장 리팩터링 원칙(2.7~)

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

리팩터링

지속적 통합

자가 테스트 코드

 

팀으로 개발할 때 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링 할 수 있어야 함

지속적 통합을 적용하면 팀원 각자가 수행한 리팩터링 결과를 동료와 빠르게 공유할 수 있음

(리팩터링의 결과가 팀원의 작업에 문제를 일으키면 즉시 알아낼 수 있음)

 

지속적 배포는 소프트웨어를 언제든 릴리스할 수 있는 상태로 유지해 줌

 

2.8 리팩터링과 성능

직관적인 설계 vs 성능

소프트웨어를 이해하기 쉽게 만들기 위해 속도가 느려지는 방향으로 수정하는 경우가 많음

그러나 성능을 개선하기 더 쉬워짐

 

빠른 소프트웨어를 작성하는 방법 세 가지

1. 시간 예산 분배 방식

하드 리얼타임 시스템에서 많이 사용

설계를 여러 컴포넌트로 나눠서 컴포넌트마다 자원(시간과 공간) 예산을 할당, 예산 초과 불과함

엄격한 시간 엄수를 강조하여 데이터가 늦게 도착하면 안 되는 시스템에 적당(ex. 심장 박동 조율기)

 

2. 끊임없이 관심을 기울이는 것

직관적이나 성능 개선을 위한 최적화가 진행될수록 프로그램이 다루기 어려운 형태로 변하여

개발이 더뎌지기에 효과가 변변치 않음

 

3. 성능 최적화에 돌입하기 전에는 성능에 신경쓰지 않고 코드를 다루기 쉽게 만드는데에만 집중

시스템이 느리다면 원인을 섣불리 추측하지 말고 성능을 측정해 볼 것

대부분의 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비하기 때문에

코드 전체를 최적화한다면 그중 90%는 효과가 거의 없음

 

프로파일러로 프로그램을 분석하여 시간과 공간을 많이 소요하는 부분을 알아낸 후 그 부분 개선

최적화도 리팩터링과 마찬가지로 작은 단계로 나눠서 진행,

컴파일과 테스트를 거치고 프로파일러를 다시 실행했는데 성능이 개선되지 않았다면 수정 내용을 되돌림

 

리팩터링은 최적화에 도움을 줌

1. 성능 튜닝에 투입할 시간을 벌 수 있음

리팩터링으로 인해 기능 추가가 빨리 끝나 성능에 집중할 시간이 생김

 

2. 성능을 더 세밀하게 분석할 수 있음

프로파일러가 지적해주는 코드의 범위가 좁아서 튜닝하기 쉬워짐

 

리팩터링은 성능 좋은 소프트웨어를 만드는 데 기여

단기적으로 보면 성능이 느려지는 것처럼 보이지만 최적화 단계에서 코드 튜닝이 쉬워지기 때문

 

2.9 리팩터링의 유래

워드 커닝햄과 켄트 벡의 스몰토크(객체 지향 언어) 개발에서 시작

빌 옵다이크의 개발 도구에서 리팩터링을 지원하는 방법 연구(최초)

존 브랜트와 돈 로버츠가 빌의 연구를 발전시켜 스몰토크 환경을 위한 리팩터링 도구 '리팩터링 브라우저'를 개발

 

2.10 리팩터링 자동화

텍스트 변경 시

• '찾아 바꾸기' 기능으로 변경하기
  • 테스트 필수
• 구문 트리(syntax tree)로 해석해서 다루기
  • IDE 지원
• 언어 서버(language server)
  • 구문 트리를 구성하여 텍스트 에디터에 API 형태로 제공하는 소프트웨어

 

 

 

 

2023.05.09