<div id="readability-page-1" class="page"><div><article><div><p><h2 id="00dc">리팩터링 2판 스터디</h2></p><p id="51fd"><em>이탤릭체는 개인적인 의견이다.</em></p><h2 id="2e31">79p 리팩터링 정의</h2><p id="452d">소프트웨어의 <strong>겉보기 동작은 그대로 유지</strong>한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 ⇒ 모든 코드 정리를 말하는게 아니라 <strong>일정한 기법에 따라 정리하는 것만이</strong> 리팩터링.</p><h2 id="bdaa">80p 두 개의 모자</h2><p id="0111">기능 추가와 리팩터링은 두개의 모자. 리팩터링 할 때는 리펙터링 모자만 쓰고 기능추가는 하지 않는다.</p><h2 id="a28e">81p 리펙터링 하는 이유</h2><ul><li id="47be">소프트웨어 설계가 좋아진다.</li><li id="68b1">소프트웨어를 이해하기 쉬워진다.</li><li id="c145">버그를 쉽게 찾을 수 있다.</li><li id="9573">프로그래밍 속도를 높일 수 있다 ⇒ 좋은 설계는 기능 추가의 속도를 빠르게 유지할 수 있다. 그러나 처음부터 좋은 설계는 매우 어려우므로 리펙터링이 반드시 필요하다.</li></ul><h2 id="9db5">85p 언제 리펙터링 할까</h2><ul><li id="4daa">기능을 추가하기 직전, 기능을 추가하기 쉽게 만들기</li><li id="90b8">코드를 파악할때 코드의 의도가 더 명확히 드러나게할 리팩터링 : 이 과정은 더 멀리 보기위한 창문딱기, 깊은 수준의 이해 가능.</li><li id="b2fc">쓰레기 줍기 리팩터링 : 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 메모를 남기고 넘어간다.</li><li id="fdd7">코드리뷰할때 리팩터링 활용하기</li><li id="93d6">수정하지 말아야할때</li><li id="6586">굳이 수정할 필요가 없을때</li><li id="634f">처음부터 새로 작성하는 게 쉬울 때</li></ul><h2 id="d593">92p 리펙터링 시 고려할 문제</h2><ul><li id="e711"><strong>새 기능 개발 속도 저하</strong> : 리팩터링의 궁극적 목적은 개발 속도를 높이는것. 도덕적인 이유가 아니라 경제적인 이유로 접근해야.</li><li id="42ad"><strong>코드의 소유권</strong> : 코드의 소유권이 나눠져 있으면 리팩터링에 방해가 됨. 코드 수정권한은 팀원 모두에게 주는것이 좋다. 각자 책임 지는 영역이 있을 수 있지만 그것이 다른 사람의 수정을 막으라는 뜻은 아님.</li><li id="72d5"><strong>브랜치</strong> : 기능별 브랜치의 독립적인 개발기간이 길어질수록 통합이 어렵다. 통합 주기를 짧게 관리해야 한다. 지속적 통합(CI). 최소 하루에 한번 마스터와 통합하면 상당히 복잡도를 낮출 수 있다. ⇒ <em>그러나 쉽지 않을 수 있음. 기능을 잘게 쪼갤줄 알아야 하고 기능 플래그도 적용해야 할 수 도 있다.</em></li><li id="81c9"><strong>테스트</strong> : 리펙터링은 겉보기 동작은 유지하는것이 특성이다. 그래서 테스트코드를 작성하는것이 중요하다. 테스트 코드는 리펙터링 뿐 아니라 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다. 역으로, 복잡한 코드인데 테스트가 없으면 리펙터링 할때 자신감이 없어지고 실제로 사이드 이펙트로 문제가 될 수도 있다.</li><li id="a427"><strong>레거시 코드</strong> : 레거시 시스템 파악할때 리팩터링이 굉장히 도움된다. 그러나 테스트가 없으면 어렵다. 그러면 테스트를 작성하라. 물런 그것도 쉬운일은 아니다. 테스트를 염두해두고 설계한 시스템만 쉽게 테스트를 할 수 있다.</li></ul><h2 id="eec1">100p 리팩터링, 아키텍처, 애그니(YAGNI)</h2><ul><li id="a56e">소프트웨어는 실제 만들어져 사용할때 정말 원하는 바가 무엇인지 알게되는 경우가 많다.</li><li id="fee7">그래서 어떤 유연성이 필요하고 변화가 있을지 미리 예측하지 말고 계획된 요구사항을 잘 구축하되, 리팩터링을 미루면 훨씬 힘들어진다는 확신이 들 때 유연성 매커니즘을 미리 추가한다.</li><li id="eef8">YAGNI : You aren’t going to need it ⇒ 진화형 아키텍처 원칙 발전.</li></ul><h2 id="fd3b">102p 리팩터링과 소프트웨어 개발 프로세스</h2><ul><li id="cb51">지속적 통합 + 테스트코드 + 리팩터링 : XP</li><li id="3795">이 세가지 요소는 서로 강력한 상승 효과 발휘.</li><li id="68e7">지속적 통합 → 동료와 리팩터링 빠르게 공유, 테스트 → 안전하고 잦은 리팩터링</li></ul><h2 id="ae18">103p 리팩터링과 성능</h2><ul><li id="8513">리팩터링하면 느려질 수도 있는건 사실이지만 동시에 성능을 튜닝하기는 더 쉬워진다.</li><li id="7538">시스템에 대해 잘 알더라도 추측보다는 성능을 측정해봐야 한다.</li><li id="79d0">대부분의 프로그램은 극히 일부에서 대부분의 시간을 소비한다.</li></ul><h2 id="4f06">108p 리팩터링 자동화</h2><ul><li id="f74d">IDE에서 제공하는 도구</li><li id="cca4">찾기 바꾸기, 변수 추출하기…</li><li id="938b">정적타입 언어가 자동화 구현이 더 쉬움.</li><li id="411e"><em>깃헙의 </em><a href="https://github.com/features/copilot" rel="noopener ugc nofollow" target="_blank"><em>copilot</em></a><em> 과 같은 서비스가 리팩터링 자동화 도구로서 활용 가치가 있지 않을까.</em></li></ul></div></article></div></div>

Stories by Jeong Woo Ahn on Medium

Jeongwoo Ahn

리팩터링 2판 스터디
이탤릭체는 개인적인 의견이다.
79p 리팩터링 정의
소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 ⇒ 모든 코드 정리를 말하는게 아니라 일정한 기법에 따라 정리하는 것만이 리팩터링.
80p 두 개의 모자
기능 추가와 리팩터링은 두개의 모자. 리팩터링 할 때는 리펙터링 모자만 쓰고 기능추가는 하지 않는다.
81p 리펙터링 하는 이유
소프트웨어 설계가 좋아진다.
소프트웨어를 이해하기 쉬워진다.
버그를 쉽게 찾을 수 있다.
프로그래밍 속도를 높일 수 있다 ⇒ 좋은 설계는 기능 추가의 속도를 빠르게 유지할 수 있다. 그러나 처음부터 좋은 설계는 매우 어려우므로 리펙터링이 반드시 필요하다.
85p 언제 리펙터링 할까
기능을 추가하기 직전, 기능을 추가하기 쉽게 만들기
코드를 파악할때 코드의 의도가 더 명확히 드러나게할 리팩터링 : 이 과정은 더 멀리 보기위한 창문딱기, 깊은 수준의 이해 가능.
쓰레기 줍기 리팩터링 : 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 메모를 남기고 넘어간다.
코드리뷰할때 리팩터링 활용하기
수정하지 말아야할때
굳이 수정할 필요가 없을때
처음부터 새로 작성하는 게 쉬울 때
92p 리펙터링 시 고려할 문제
새 기능 개발 속도 저하 : 리팩터링의 궁극적 목적은 개발 속도를 높이는것. 도덕적인 이유가 아니라 경제적인 이유로 접근해야.
코드의 소유권 : 코드의 소유권이 나눠져 있으면 리팩터링에 방해가 됨. 코드 수정권한은 팀원 모두에게 주는것이 좋다. 각자 책임 지는 영역이 있을 수 있지만 그것이 다른 사람의 수정을 막으라는 뜻은 아님.
브랜치 : 기능별 브랜치의 독립적인 개발기간이 길어질수록 통합이 어렵다. 통합 주기를 짧게 관리해야 한다. 지속적 통합(CI). 최소 하루에 한번 마스터와 통합하면 상당히 복잡도를 낮출 수 있다. ⇒ 그러나 쉽지 않을 수 있음. 기능을 잘게 쪼갤줄 알아야 하고 기능 플래그도 적용해야 할 수 도 있다.
테스트 : 리펙터링은 겉보기 동작은 유지하는것이 특성이다. 그래서 테스트코드를 작성하는것이 중요하다. 테스트 코드는 리펙터링 뿐 아니라 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다. 역으로, 복잡한 코드인데 테스트가 없으면 리펙터링 할때 자신감이 없어지고 실제로 사이드 이펙트로 문제가 될 수도 있다.
레거시 코드 : 레거시 시스템 파악할때 리팩터링이 굉장히 도움된다. 그러나 테스트가 없으면 어렵다. 그러면 테스트를 작성하라. 물런 그것도 쉬운일은 아니다. 테스트를 염두해두고 설계한 시스템만 쉽게 테스트를 할 수 있다.
100p 리팩터링, 아키텍처, 애그니(YAGNI)
소프트웨어는 실제 만들어져 사용할때 정말 원하는 바가 무엇인지 알게되는 경우가 많다.
그래서 어떤 유연성이 필요하고 변화가 있을지 미리 예측하지 말고 계획된 요구사항을 잘 구축하되, 리팩터링을 미루면 훨씬 힘들어진다는 확신이 들 때 유연성 매커니즘을 미리 추가한다.
YAGNI : You aren’t going to need it ⇒ 진화형 아키텍처 원칙 발전.
102p 리팩터링과 소프트웨어 개발 프로세스
지속적 통합 + 테스트코드 + 리팩터링 : XP
이 세가지 요소는 서로 강력한 상승 효과 발휘.
지속적 통합 → 동료와 리팩터링 빠르게 공유, 테스트 → 안전하고 잦은 리팩터링
103p 리팩터링과 성능
리팩터링하면 느려질 수도 있는건 사실이지만 동시에 성능을 튜닝하기는 더 쉬워진다.
시스템에 대해 잘 알더라도 추측보다는 성능을 측정해봐야 한다.
대부분의 프로그램은 극히 일부에서 대부분의 시간을 소비한다.
108p 리팩터링 자동화
IDE에서 제공하는 도구
찾기 바꾸기, 변수 추출하기…
정적타입 언어가 자동화 구현이 더 쉬움.
깃헙의 copilot 과 같은 서비스가 리팩터링 자동화 도구로서 활용 가치가 있지 않을까.

2장 리팩터링 원칙

댓글