리팩터링 Chapter 2 - 리팩터링 원칙
이번 챕터는 조금 근본적인 이야기가 많은 챕터였습니다.
그래서 정리를하며 내용을 이해하는 방식으로 책을 읽었습니다.
스터디 중 Branch와 YAGNI에 대해서 토론한 내용도 정리해봤습니다.
2-1 리팩터링의 정의
리팩터링(명사) : 소프트웨어의 겉보기 동작은 그대로 유지한 채,
코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
리팩터링(동사) : 소프트웨어의 겉보기 동작은 그대로 유지한 채,
여러가지 리팩터링 기법을 적용해 소프트웨어를 재구성하는 기법
누군가 "리팩터링하다가 코드가 깨져서 며칠이나 고생했다고 하면 그것은 리팩터링한 것이 아니다.
2-2 두 개의 모자
소프트웨어 개발의 목적을 '기능 추가'냐 아니면 '리팩터링'이냐를 확실히 구분합니다.
기능추가는 테스트를 추가하여 통과하는지 확인하는 방식을 이용.
리팩터링은 테스트는 만들지 않고 오로지 코드 재구성에 전념.
2-3 리팩터링하는 이유
리팩터링하면 소프트웨어 설계가 좋아진다.
리팩터링하면 소프트웨어를 이해하기 쉬워진다.
리팩터링하면 버그를 쉽게 찾을 수 있다.
리팩터링하면 프로그래밍 속도를 높일 수 있다.
2-4 언제 리팩터링을 할까?
3의 법칙 : 그냥 한다 → 비슷해도 그냥 한다(2번은 가능)→ 또 발생 시 리팩터링한다.
준비를 위한 리팩터링(기능을 쉽게 추가하게 만들기)
버그가 수정된 상태가 오래 지속될 가능성을 높이고 같은 곳에서 버그가 발생할 확률이줄어듬.
리팩터링하기 가장 좋은 시점 = 코드베이스에 기능을 새로추가하기 직전
이해를 위한 리팩터링(코드를 이해하기 쉽게 만들기)
로직구조가 이상하지는 않은지 함수 이름이 명확한지 살펴봄.
쓰레기 줍기 리팩터링
비효율적인 로직에 대해 간단한 것은 수정하고 시간이 걸리는 일은 짧은 메모를 남기고 작업.
계획된 리팩터링과 수시로 하는 리팩터링
버전 관리 시스템에서 리팩터링 커밋과 기능 추가 커밋은 반드시 분리하자.
무언가를 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고 쉽게 수정하자.
오래 걸리는 리팩터링
모든 사람이 리팩터링을 하는 건 반대. 조금씩 해결해나가는 편이 효과적.
코드 리뷰에 리팩터링 활용하기
짝 프로그래밍 추천(서로 앉아 코드를 설명하고 훑어가는 과정)
머리로만 상상하는게 아닌 직접 리팩터링을 하면 한 차원 높은 아이디어가 떠오름.
리팩터링하지 말아야 할 때
코드들은 리팩터링 필수.
외부 API 다루듯 호출해서 쓰는코드라면 지저분해도 됨. 내부적인 동작을 이해해야하는 부분만 신경써야함.
2-5 리팩터링 시 고려할 문제
새 기능 개발 속도 저하
상황에 맞게 리팩터링을 조율. 리팩터링은 자주하는 것이 효율적.
리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것.
코드 소유권
특정 관리자가 아닌 오픈소스 프로젝트와 같이 관리. 브랜치를 따서 커밋을 요청하는 형식.
테스팅
오류를 빠르게 잡아내고 그 원인을 쉽게 고칠 수 있는 방법 중 하나.
레거시 코드
해결방법은 "테스트 보강".
레거시 코든느 복잡하고 테스트도 갖춰지지 않은 것이 대부분임.
데이터베이스
데이터베이스 리팩터링은 프로덕션 환경에 여러 단계로 나눠서 릴리즈하는 것을 추천.
브랜치
그러나 작업 기간이 길어지면 머지나 리베이스하기 어려움. 그래서 수시로 머지해줘야함.
오픈소스 프로젝트 = 브랜치 방식, 풀타임 개발팀 = CI
지속적 통합(CI) 또는 트렁크 기반 개발(TBD)라고 함.
흔히 브랜치를 하나씩 맡아서 작업하다가 결과물이 쌓이면 마스터 브랜치에 통합해서 공유.
2-6 리팩터링, 아키텍처, 애그니(YAGNI)
레거시코드는 테스트 코드가 탄탄하지 않기때문에 변경하기 어려움.
향후 변경을 유연하게 대처하기위해서 유연성 메커니즘을 소프트웨어에 심어둠.
다양한 상황에 대비해 매개변수 추가. 그러나 너무 과하면 변화대응능력이 떨어짐.
따라서 점진석 설계, 간결한 설계, YAGNI(you aren't going to need it)를 추가함.
2-7 리팩터링과 소프트웨어 개발 프로세스
자가 테스트 코드와 리팩터링을 묶어서 테스트 주도 개발(TDD)이라고 함.
자가 테스트 코드는 지속적 통합(CI)의 핵심요소.
자가 테스트 코드와 지속적 통합 그리고 리팩터링을 적용한다면 YAGNI설계 방식 개발.
2-8 리팩터링과 성능
리팩터링하면 성능이 느려질까봐 걱정하는 사람이 많음.
그건 어느 정도 인정하지만 성능을 튜닝하기 쉬워짐. 빠른 소프트웨어 방법 세 가지 제안.
첫 번째는 시간 예산 분배방식. 하드리얼타임 시스템에 사용. 컴포넌트에 적절한 시간을 할당.
두 번째는 끊임없이 관심을 기울이는 것. 시스템에 대해 잘 알더라도 추측하지말고 성능 측정은 필수.
세 번째는 90%의 시간은 낭비. 대부분은 한 곳에 엄청난 시간을 소모. 그래서 그 부분을 적극적 수정.
2-9 리팩터링의 유래
스몰토크에서 유래. 스몰토크는 기능이 풍부한 소프트웨어를 빠르게 작성 할 수 있는
굉장히 역동적인 환경. 컴파일 - 링크 - 실행 주기가 상당히 짧음.
내부수정이 외부에 미치는 영향을 최소로 줄일 수 있다는 것이 핵심.(XP)
2-10 리팩터링 자동화
자동 리팩터링 기능을 대부분 IDE에서 제공.
자동 리팩터링은 코드를 텍스트 상태가 아닌 구문 상태로 해석해서 다뤄야함.
언어 서버란 구문 트리를 구성해서 텍스트 에디터에 API형태로 제공하는 소프트웨어.
이를 통해 다양한 텍스트 에디터를 지원하고 정교한 코드분석, 리팩터링 기능을 제공.
스터디 내용
이번 스터디에서는 크게 2가지 주제에 관해서 토론했습니다.
1. Branch
이 부분에 대한 공부는 따로 하여 링크로 걸어두겠습니다.
2. YAGNI
다음 주제는 YAGNI입니다.
YAGNI는 미래를 얼마나 예측하고 설계할것인가입니다.
즉 앞으로의 변화에 얼마나 유연하게 설계할 지 정하는 것입니다.
그러나 안타깝게도 이것에 대해서 정답은 없습니다.
적절하게 해야한다. 책에서도 답을 알려주지 않았습니다.
너무 과하게 미래를 예측하고 설계를하면 오히려 변화대응능력이 떨어진다고 나와있습니다.
결과적으로는 적절하게 설계를 한 후작업도중 문제를 더 깊이 이해하게 됐을 때 처리하는 쪽이 훨씬 낫다고 생각합니다.