리팩토링 2판 - Chapter2 요약

리팩터링 2판

• 자바스크립트로 예시가 되어 있음
• 리팩터링 패러다임은 언어를 초월하여 의미가 있음
• 그러나 실제 활용은 언어에 귀속됨

배워서 어디에 써먹을까?

• 리팩터링이 필요한 이유를 설득할 수 있음
  • 책 한권 읽는다고 설득할 수 있는 것은 아님
  • 적어도 물꼬는 틔워줄 수 있음
• 리팩터링 중 발생하는 고민을 일정량 줄일 수 있다.
  • 간결한 코드가 좋을까, 성능이 우월한 방법이 좋을까?
  • 어느정도의 성능 감소를 용인할 수 있을까?
  • 깔끔한 코드와 디버깅이 용이한 코드 중 무엇을 할까?
• 언제 리팩터링 할까?
  • 냄새나는 코드
  • 냄새가 얼마나 나야 리팩터링 해야하나?
• 훨씬 깔끔한 코드를 작성할 수 있음
  • 리팩터링을 수정하는 것이지만, 창조할때도 유용
• 동료의 Code Review 할 때
  • 동료와 팀의 생산성에 기여할 수 있다!

스터디에서 다루는 범위

• 챕터 1 생략
• 매주 가이드 영상에서 책의 내용을 요약해줌
• 이렇게 스터디 해본적은 없는데, 내용 요약에 대한 부담이 줄어서 오히려 의문이 드는 부분만 핵심적으로 파볼 수 있을 것 같다.

챕터 2: 리팩터링 원칙

리팩터링 정의

• Why: 코드 이해와 수정이 쉽도록
• What: 내부 구조 변경
• How: 겉보기 동작은 유지

겉보기 동작 유지

• 콜스택이나 인터페이스가 달라지는 것은 변화가 아님
  • 같은 함수인데 지역변수를 함수의 파라미터로 놓기
  • 어디까지나 겉보기 동작에는 변화가 없음
• 그런 어디부터 변화? (추상적 기준)
• 버그도 그대로 남아 있어야 한다
  • 만약 리팩터링 하는 과정에 사소한 버그가 발견되면 수정해도 상관없음
  • 하지만 이미 알고 있는 버그이고, 수정할 계획이 있었다면 리팩터링 중에는 수정하지 않기

이 책에서 정의한 리팩터링은 굉장히 좁다

• 누군가 리팩터링 하다가 코드가 꺠져서 며칠이나 고생했다 라고 한다면, 십중팔구 리팩터링 한것이 아니다 (80페이지)
• 이건 어떤 의도로 한 말일까?

두개의 모자

• 기능추가 / 리팩터링
• 하나의 모자를 쓸 때는 하나의 변화만
• 리팩터링 할 때는 버그도 그대로 둬야함

리팩터링 하는 이유

• 소프트웨어 설계가 좋아진다
• 소프트웨어를 이해하기 좋아진다
• 버그를 쉽게 찾을 수 있다
• 프로그래밍 속도를 높일 수 있다: 이게 가장 핵심적인 이유

언제 리팩터링해야 할까?

• 3의 법칙 (3진아웃 리팩터링)
  • 비슷한 일을 3번째 하게되면 리팩터링한다
• 준비를 위한 리팩터링
  • 기능을 쉽게 추가하게 만들기
  • 리팩터링을 조금만 하면 기능 추가하기 쉬울것 같을 때
  • "잠깐, 지도를 찾아보고 가장 빠른 경로를 찾아보자"
• 이해를 위한 리팩터링
  • 코드를 이해하기 쉽게 만들기
  • 이해한 바를 명시적으로 코드에 드러내도록 수정할 수 있음
  • 새로운 설계에 도움
  • 동료간 교류에 도움
    • 새로운 코드를 접했을 때 리팩토링을 하는 것이 코드 이해에 도움이 될 수 도 있겠다
• 쓰레기 줍기 리팩토링
  • 코드가 일을 비효율적으로 처리하는것을 발견했을 때
    • 간단히 수정할 수 있으면 바로 고친다
    • 아니라면 기록 후, 하던일을 마치고 처리한다
      • 이슈 작성해서 큐에 넣어두기
• 계획된 리팩터링과 수시로 하는 리팩터링
  • 프로그래밍 중 상시 지속되는 활동: 저자가 지향하는 것
  • 소홀했던 부분을 작성하고 리팩터링하는 것도 필요
    • 무조건 나쁜 것은 아님
• 오래 걸리는 리팩터링
  • 리팩터링은 대부분 몇 분 안에 끝난다. 길이야 몇 시간 정도다
  • 조금씩 개선
• 코드 리뷰에 리팩터링 활용하기
  • 팀원의 코드 리뷰를 할 때 리팩터링 기법을 이용
• 관리자에겐 뭐라고 말해야 할까?
  • "어설픈 재구성"은 리팩터링이 아니다
  • "설계 지구력 가설": 추진력을 얻기위해 무릎을 꿇는 과정을 관리자에게 어필
  • 아니면 아예 리팩터링 한다고 말하지 말아라
    • 리팩터링은 어차피 프로그래밍의 일부
• 리팩터링 하지 말아야 할 때
  • 굳이 수정할 필요가 없을 때
    • 코드가 지저분한데 한 함수안이 지저분하다... 블랙박스로 되어 있고 성능이 잘나오고 있다면 굳이 수정할 필요 없음
  • 처음부터 새로 작성하는게 쉬울 때

리팩터링 시 고려할 문제

• 새 기능 개발 속도 저하된다는 오해
  • 이후에 개발 속도를 빠르게 하기 위함
  • 팀원들을 설득하고 훈련시키는 것이 중요함
  • 리팩터링은 '클린코드', '바람직한 엔지니어링 습관' 같은 도덕적인 것이 아님
  • 오로지 경제적인 이유로 하는 것
• 코드 소유권
  • 구현코드와 호출코드의 소유자가 다른 팀일 때, 공개 API를 사용할 때 등
  • 여전히 리팩터링 가능하다. 제약이 따를 뿐
  • 코드 소유권을 세부적으로 나눠서 관리하는 것을 바람직하지 않다고 함. 아마존에서도 소스코드를 팀별로 관리하고 있다고 함
  • 오픈소스 개발 모델 차용
• 브랜치
  • 메인 브랜치 → A / B / C 브랜치 나눠서 작업 → 나중에 머지
  • 이 처럼 독립브랜치로 일할 때 통합되는 기간이 길어질 수록 통합이 어려워짐
  • 브랜치 통합주기를 2~3일, 그 보다 더 짧게, 최소 하루에 한번 통합
  • 단, 완료되지 않은 기능이 시스템 전체를 망치지 않도록 주의
  • 리팩터링이 일어나면 코드 전반에 소규모 수정이 일어남 → 머지 중에 충돌이 발생할 가능성이 높음
• 테스팅
  • 리팩터링은 동작 변화가 없어야 한다
  • 테스트 자체가 하나의 기준이 될 수 있음
  • 의도치 않은 버그를 빠르게 잡을 수 있음
  • 버그 생길 위험이 크다는 불안감 해소 가능
• 레거시 코드
  • 한계를 언급함
  • 대부분의 코드베이스는 다른사람이 작성한 것
  • 테스트 없이 리팩터링은 어렵다 → 테스트를 보강하라!
  • 쉽게 해결할 방법은 없다
• 데이터베이스
  • 안 되는 줄 알았는데 가능하더라

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

• 기존 패러다임
  • 요구사항 사전에 완벽 파악 → 코딩전에 아키텍처 확정
  • 사실상 불가능
  • 요구사항이 계속 변함
• 유연성 메커니즘을 심어두는 방안
  • 미래를 대비해서 기능을 미리 만들어두는 것
  • 코드를 너무 유연하게 하면 오히려 대응 능력을 떨어트림...
• YAGNI(You aren't going to need it: 아마 필요 없을 거다)
  • 현재까지 파악한 요구사항만 해결
  • 해당 요구사항을 멋지게 해결
  • 진행중 요구사항을 파악하면 그때그떄 리팩터링하여 수정
  • 요구사항을 이해했을 때 처리하는게 훨씬 더 낫다

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

• XP
• TDD
• 애자일 소프트웨어
• 테스트 코드, 지속적 통합

리팩터링과 성능

• 하드웨어가 발전하기 때문에 성능은 상관없음이 아님
• 리팩터링을 하고나면 성능을 튜닝하기 쉬워진다
• 결과적으로는 성능에도 도움이 됨

성능 중심 개발방법

• 시간예산분배: 제한된 조건에서만 사용됨
• 끊임없이 관심 기울이기: 모든 코드를 쓸 때 성능향상에 초점
  • 실제 효과가 변변치는 않음

90%시간은 낭비

• 대부분의 프로그램은 극히 일부분에서 대부분의 시간을 소모한다
  • 아무것도 안 만드는데도 시간이 걸린다
  • ex) 알고보니 하나의 함수를 쓸데없이 여러번 호출
• 성능상 문제가 되는 부분은 10%밖에 안된다
• 그 부분을 찾기 쉽게하려면 리팩터링
• 프로파일러로 분석하여 해당 부분만 성능 개선
• 크게 느려지지 않은 나머지 90%의 성능개선에 투자하는것은 낭비

기타