본문 바로가기

programming study/Refactoring

Refactoring - 2장 리팩터링 원칙

본 내용은 한달한권의 리팩터링 강의를 토대로 작성되었습니다.

 

0. 리팩터링이 필요한 이유

  • 코드 리뷰
    • 남이 만든 코드의 문제점을 파악한 뒤 더 나은 코드로 전환할 것을 제안하는 것
    • 리팩터링의 원칙과 동일
  • 좋은 코드
    • 가독성 높은 코드, 경제성 있는 코드를 만들어서 현재의 동료 혹은 미래의 후임들에게 정보를 더 가시적으로 제공하는 것

 

1. 리팩터링 정의

  • 리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
    • 중간 단계에서도 코드 동작이 유지되어야 함
    • 어떻게 하느냐가 중요
  • 왜(why) : 이해하고 수정하기 쉬운 코드
  • 무엇을(what) : 내부 구조를 변경
  • 어떻게(how) : 겉보기 동작은 그대로 유지한 채
  • Restructuring > Refactoring
    • Restructuring(리스트럭쳐링/재구성) : 코드베이스를 정리하거나 구조를 바꾸는 모든 작업
    • Refactoring(리팩터링) : 코든 리스터럭쳐링 중에서 도중에 중단되더라도 동작이 유지되는 것

 

2. 두개의 모자

  • 기능 추가와 리팩터링을 명확하게 구분
  • 리팩터링 커밋과 기능추가 커밋을 분리
    • 단, 리팩터링은 기능 추가와 밀접하게 엮인 경우가 너무 많기 때문에 굳이 나누면 시간 낭비일 수도 있음
    • 대안책 : 최종 commit은 하나로 묶되, 코드리뷰는 여러 Revision으로 나누어 검토
    • git의 stash / commit / rebase 등의 기능을 잘 활용하기

 

3. 리팩터링, 왜 하는가?

  • 소프트웨어 설계가 좋아짐
  • 소프트웨어를 이해하기 쉬워짐
  • 버그를 쉽게 찾을 수 있음
  • 결과적으로, 프로그래밍 속도를 높일 수 있음
  • 설계 지구력
    • 내부 설계에 심혈을 기울이면, 소프트웨어의 지구력이 높아져서 빠르게 개발할 수 있는 상태를 더 오래 지속할 수 있음

 

4. 리팩터링, 언제 하는가?

4.1 3의 법칙 - 3진(아웃) 리팩터링

  1. 일단 개발하기
  2. 같은일을 두번하게 되면 일단 하기
  3. 또 같은일을 하게 되면, 이제야 말로 리팩터링 할 때

 

4.2 준비를 위한 리팩터링 - 기능을 쉽게 추가하게 만들기

  • 기능을 추가하기 직전해, '리팩터링을 하면 더 쉽게 추가할 수 있지 않을까' 고민

 

4.3 이해를 위한 리팩터링 - 코드를 이해하기 쉽게 만들기

  • 코드를 파악해야 할 일이 있을 때, 이해한 내용을 더 잘 반영할 수 있도록 리팩터링
  • 기능 추가하기 전

 

4.4 쓰레기 줍기 리팩터링

  • 코드를 파악하다가 '비효율적으로 처리하는 모습을 발견'하면 리팩터링

 

4.5 수시로 하는 리팩터링

  • 따로 하지 않고 일반 개발 과정에서

 

4.6 코드 리뷰에 리팩터링

  • 코드 리뷰를 할 때, 실제로 리팩터링

 

4.7 리팩터링 하지 말아야 할 때

  • 굳이 수정할 필요 없을 때
  • 차라리 새로 작성하는게 쉬울 때

 

4.8 실질적인 리팩터링

  • 준비를 위한 리팩터링을 주로 함
  • 기능을 추가하기 직전에, '리팩터링을 하면 더 쉽게 추가할 수 있지 않을까' 고민
  • 코드 리뷰를 진행하면서도 리팩터링이 많이 일어남

 

5. YAGNI

  • You Aren't Going to Need It
  1. 추측하지 말고 현재 요구사항만 충족해라
  2. 대신 그것을 최대한 멋지게 해결하도록 설계 해라
  3. 나중에 더 잘 이해하게 되면 리팩터링으로 바꿔라

이미 알고 있는 부분은 최대한 미리 준비하는 것이 좋지만, 모르는 걸 미리 대비하기 보다는 이해하고 나서 반영하는 것이 효율적

 

YAGNI의 등장 이유

  • 코딩을 시작하기 전에 아키텍쳐를 확정
    • 요구 사항을 사전에 파악하기가 현실적으로 불가능
    • 클라이언트의 바뀌는 요구 사항
    • 파악을 하여도, 완전한 아키텍쳐를 만들 수 없음
  • 유연성 메커니즘 심어두기
    • 요구사항을 예측하여 코드에 추가하는 것
    • 되려 대응 능력을 저하시킴

 

6. 리팩터링과 성능

  • 반복문 쪼개기
    • for문을 한번 돌 것을 두 번 돌도록 바꾸는 것
    • 직관적 설계를 위한 것이라면 하는 것이 좋음
  • 리팩터링은 이해하기 쉬운 코드를 위해 '속도가 느려지는' 방향인 경우가 많음
    • 성능을 튜닝하기 쉬워지기 때문에 오히려 성능이 좋아짐

리팩터링으로 성능 최적화하기

  1. 성능에 신경쓰지 않고, 보기 좋게 코딩
  2. 성능 최적화 단계가 되면, 프로파일러로 분석하여 오랜 시간을 잡아먹는 코드를 특정
  3. 그 부분을 개선

 

7. 기타 주의해서 읽어볼 것

  • 언제 리팩터링 해야할 까
    • 관리자에게 어떻게 말할지
  • 리팩터링시 고려 할 문제
    • 브랜치
    • 테스팅
  • 리팩터링 자동화