<div id="readability-page-1" class="page"><div>
  <p><span>Written by</span>
    KimCoding

    
      <br>
      <span>on&nbsp;</span><time datetime="2020-05-06 00:00:00 +0900">May 06, 2020</time>
    
  </p>

  <h2>리팩터링에 대한 단상</h2>
  

  <p><img src="https://coderk.github.io/assets/images/new/2020-05-06-36-background.jpeg" loading="lazy"></p>

<p>팀 스터디로 <a href="http://www.yes24.com/Product/Goods/89649360?scode=032&amp;OzSrank=1">“리팩터링 2판의 Chapter 02 - 리팩터링 원칙”</a>을 읽다가 떠오르는 생각을 정리한 글입니다.</p>

<hr>

<h2 id="리팩터링의-정의">리팩터링의 정의</h2>

<p>리팩터링은 <u>"소프트웨어의 겉보기 동작은 그대로 유치한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법"</u>을 말한다. 변경에 유리한 설계를 확보하면 이후의 작업을 더 쉽게 할 수 있다. 궁극적으로 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하려는 활동이다. 따라서 리팩터링은 도덕이 아닌 경제의 관점에서 접근을 해야 한다. 현실에서는 리팩터링을 도덕의 문제로 이야기하는 경우를 많이 보지만.
​</p>
<h2 id="리팩터링의-딜레마">리팩터링의 딜레마</h2>

<p>설계를 잘하면 개발 속도가 더 빨라진다는 주장을 책의 저자인 마틴 파울러는 <u>설계 지구력 가설(Design Stamina Hypothesis)</u>이라고 부른다. 가설인 이유는 그런 것 같다고 느끼는 사람은 많지만 이를 수치로 증명하지 못했기 때문이다. 경제의 문제임에도 현실에서 리팩터링의 가치를 수치로 증명하기는 어렵다. 우리가 부족해서가 아니다. 이 동네가 원래 그렇다. 개발자의 생산성을 증명하기 어려운 것과 같다.</p>

<p>​어쨌든 리팩터링은 경제의 문제이기에 수고 대비 얻을 수 있는 <u>효과가 분명한 영역에서, 필요한 수준</u>으로 행해져야 한다. 속도보다 품질이 더 중요한 순간, 또는 품질을 높여서 속도를 더 증가시킬 수 있을 때 리팩터링을 한다. 효용을 수치로 증명할 수 없는데, 경제적으로 판단을 해야 한다? 이것이 리팩터링의 딜레마다.</p>

<p>​어렵지만 개발자는 매 순간 판단할 수밖에 없다. 리팩터링을 할 것인가 말 것인가. 판단을 하려면 알아야 한다. 아는 만큼 본다. 알려면 공부를 하고 경험을 해야 한다. 그래도 수치로 증명하기는 어렵다. 그저 설득을 할 수 있을 뿐. 이 지점에서 리팩터링은 정치의 영역과 맞닿아 있다.
​</p>
<h2 id="리팩터링과-개발-프로세스">리팩터링과 개발 프로세스</h2>

<p>애자일의 실천 사례 중 하나인 XP는 필요할 때까지 의사결정을 미루는 걸 지향한다. 섣불리 미래를 가정 하지 않는다. 대신에 지금 확실히 알 수 있는 것에 집중한다. 미래가 현실이 되었을 때, 그때야 비로소 의사결정을 한다. 대신에 피드백을 빨리 받는 전략을 택한다. 불확실한 미래로 가득한 환경에서 애자일은 그렇게 낭비를 줄이고, 점진적으로 목표를 향해 나아간다.</p>

<p>이런 개발 프로세스 아래에서는 설계도 점진적으로 만들어져야 한다. 자주 바뀌는 정책을 계속 반영해야 한다. 점진적으로 설계를 하려면 리팩터링은 필수다. 리팩터링을 자주 하려면 테스트 비용을 최소화해야 한다. 그렇지 않으면 변경 비용을 감당할 수 없다. 적정 수준의 설계, 리팩터링, 그리고 테스트 자동화는 떼어놓을 수 없다.</p>

<p>​불확실한 상황을 적응적으로 헤쳐나가려는 최근의 개발 프로세스와 리팩터링은 이렇게 연결되어 있다.</p>

<h2 id="리팩터링은-언제-해야-할까">리팩터링은 언제 해야 할까?</h2>

<p>책의 저자인 마틴 파울러는 리팩터링을 하기 좋은 시기를 세 단계로 구분한다.
​</p>
<ul>
  <li>
<b>준비를 위한 리팩터링</b>: 새로운 기능을 추가하기 전에 기존 부채를 해소하고 설계를 개선</li>
  <li>
<b>이해를 위한 리팩터링</b>: 코드를 분석할 때 리팩터링을 하면서 코드를 리뷰</li>
  <li>
<b>쓰레기 줍기 리팩터링</b>: 다른 작업을 하던 중에 발견한 문제를 해결하고 지나가기</li>
</ul>

<p>사실 리팩터링은 거창한 활동이 아니다. 지역 변수의 이름을 바꾸거나, 변수의 선언 위치를 바꾸는 작은 행동 하나하나가 모두 리팩터링이다. 알게 모르게 우리는 시도 때도 없이 리팩터링을 하고 있다. 리팩터링은 코딩과 분리할 수 있는 별개의 과정이 아니다.</p>

<p>수시로 리팩터링을 하는 게 가장 좋겠지만, 어렵다면 최소한 “코딩을 시작하기 전에 몸풀기로 리팩터링”을 하는 습관이라도 만들어 보면 어떨까? 일정을 추정할 때 리팩터링을 부작업으로 추가하고, 추정에 반영하는 것도 방법이다.
​</p>
<h2 id="리팩터링과-기술-부채">리팩터링과 기술 부채</h2>

<p>기술 부채는 주로 상황이 긴급해서 쌓인다. 몰라서 쌓는 기술 부채는 제외하자. 일단 돌아가게 만들고 나중에 수정하자고 합의하지만, 나중은 오지 않는다. 그렇게 부채는 쌓인다.</p>

<p>물론 모든 기술 부채를 다 해소해야 하는 것은 아니다. 좋은 개발자라면 비즈니스 목표를 달성하기 위해서 속도와 품질 사이에서 적절한 균형을 찾아야 한다.</p>

<blockquote>
  <p>필요한 순간에 필요한 리팩터링을 한다.</p>
</blockquote>

<p>미루고 쌓아두었다가도 필요한 순간이 오면 필요한 리팩터링을 할 수 있어야 한다. 말은 쉽지만 필요한 순간을 포착하려면 아는 게 있어야 하고, 필요한 리팩터링을 하려면 <u>언제든 기술 부채를 해소할 수 있는 장치를 확보</u>해 두어야 한다. 비즈니스 관계자를 설득하여 시간을 구할 수 있는 전략과 정치력도 가져야 한다.</p>

<p>여기까지 생각을 정리하자 우리 팀에 필요한 세 가지가 보였다.
​</p>
<ol>
  <li>설계를 보는 눈 향상</li>
  <li>기술 부채 관리 전략</li>
  <li>테스트 자동화</li>
</ol>

<p>1번은 열심히 공부하는 하는 걸로. 2번과 3번은 평소에 고민하고 있었는데 마침 기회가 닿아 동료와 따로 논의하는 자리를 만들기로 했다. 하나씩 부러뜨려 보자.</p>


</div></div>

Huns.me

팀 스터디로 “리팩터링 2판의 Chapter 02 - 리팩터링 원칙”을 읽다가 떠오르는 생각을 정리한 글입니다.
리팩터링의 정의
리팩터링은 "소프트웨어의 겉보기 동작은 그대로 유치한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법"을 말한다. 변경에 유리한 설계를 확보하면 이후의 작업을 더 쉽게 할 수 있다. 궁극적으로 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하려는 활동이다. 따라서 리팩터링은 도덕이 아닌 경제의 관점에서 접근을 해야 한다. 현실에서는 리팩터링을 도덕의 문제로 이야기하는 경우를 많이 보지만.
​
리팩터링의 딜레마
설계를 잘하면 개발 속도가 더 빨라진다는 주장을 책의 저자인 마틴 파울러는 설계 지구력 가설(Design Stamina Hypothesis)이라고 부른다. 가설인 이유는 그런 것 같다고 느끼는 사람은 많지만 이를 수치로 증명하지 못했기 때문이다. 경제의 문제임에도 현실에서 리팩터링의 가치를 수치로 증명하기는 어렵다. 우리가 부족해서가 아니다. 이 동네가 원래 그렇다. 개발자의 생산성을 증명하기 어려운 것과 같다.
​어쨌든 리팩터링은 경제의 문제이기에 수고 대비 얻을 수 있는 효과가 분명한 영역에서, 필요한 수준으로 행해져야 한다. 속도보다 품질이 더 중요한 순간, 또는 품질을 높여서 속도를 더 증가시킬 수 있을 때 리팩터링을 한다. 효용을 수치로 증명할 수 없는데, 경제적으로 판단을 해야 한다? 이것이 리팩터링의 딜레마다.
​어렵지만 개발자는 매 순간 판단할 수밖에 없다. 리팩터링을 할 것인가 말 것인가. 판단을 하려면 알아야 한다. 아는 만큼 본다. 알려면 공부를 하고 경험을 해야 한다. 그래도 수치로 증명하기는 어렵다. 그저 설득을 할 수 있을 뿐. 이 지점에서 리팩터링은 정치의 영역과 맞닿아 있다.
​
리팩터링과 개발 프로세스
애자일의 실천 사례 중 하나인 XP는 필요할 때까지 의사결정을 미루는 걸 지향한다. 섣불리 미래를 가정 하지 않는다. 대신에 지금 확실히 알 수 있는 것에 집중한다. 미래가 현실이 되었을 때, 그때야 비로소 의사결정을 한다. 대신에 피드백을 빨리 받는 전략을 택한다. 불확실한 미래로 가득한 환경에서 애자일은 그렇게 낭비를 줄이고, 점진적으로 목표를 향해 나아간다.
이런 개발 프로세스 아래에서는 설계도 점진적으로 만들어져야 한다. 자주 바뀌는 정책을 계속 반영해야 한다. 점진적으로 설계를 하려면 리팩터링은 필수다. 리팩터링을 자주 하려면 테스트 비용을 최소화해야 한다. 그렇지 않으면 변경 비용을 감당할 수 없다. 적정 수준의 설계, 리팩터링, 그리고 테스트 자동화는 떼어놓을 수 없다.
​불확실한 상황을 적응적으로 헤쳐나가려는 최근의 개발 프로세스와 리팩터링은 이렇게 연결되어 있다.
리팩터링은 언제 해야 할까?
책의 저자인 마틴 파울러는 리팩터링을 하기 좋은 시기를 세 단계로 구분한다.
​
준비를 위한 리팩터링: 새로운 기능을 추가하기 전에 기존 부채를 해소하고 설계를 개선
이해를 위한 리팩터링: 코드를 분석할 때 리팩터링을 하면서 코드를 리뷰
쓰레기 줍기 리팩터링: 다른 작업을 하던 중에 발견한 문제를 해결하고 지나가기
사실 리팩터링은 거창한 활동이 아니다. 지역 변수의 이름을 바꾸거나, 변수의 선언 위치를 바꾸는 작은 행동 하나하나가 모두 리팩터링이다. 알게 모르게 우리는 시도 때도 없이 리팩터링을 하고 있다. 리팩터링은 코딩과 분리할 수 있는 별개의 과정이 아니다.
수시로 리팩터링을 하는 게 가장 좋겠지만, 어렵다면 최소한 “코딩을 시작하기 전에 몸풀기로 리팩터링”을 하는 습관이라도 만들어 보면 어떨까? 일정을 추정할 때 리팩터링을 부작업으로 추가하고, 추정에 반영하는 것도 방법이다.
​
리팩터링과 기술 부채
기술 부채는 주로 상황이 긴급해서 쌓인다. 몰라서 쌓는 기술 부채는 제외하자. 일단 돌아가게 만들고 나중에 수정하자고 합의하지만, 나중은 오지 않는다. 그렇게 부채는 쌓인다.
물론 모든 기술 부채를 다 해소해야 하는 것은 아니다. 좋은 개발자라면 비즈니스 목표를 달성하기 위해서 속도와 품질 사이에서 적절한 균형을 찾아야 한다.
필요한 순간에 필요한 리팩터링을 한다.
미루고 쌓아두었다가도 필요한 순간이 오면 필요한 리팩터링을 할 수 있어야 한다. 말은 쉽지만 필요한 순간을 포착하려면 아는 게 있어야 하고, 필요한 리팩터링을 하려면 언제든 기술 부채를 해소할 수 있는 장치를 확보해 두어야 한다. 비즈니스 관계자를 설득하여 시간을 구할 수 있는 전략과 정치력도 가져야 한다.
여기까지 생각을 정리하자 우리 팀에 필요한 세 가지가 보였다.
​
설계를 보는 눈 향상
기술 부채 관리 전략
테스트 자동화
1번은 열심히 공부하는 하는 걸로. 2번과 3번은 평소에 고민하고 있었는데 마침 기회가 닿아 동료와 따로 논의하는 자리를 만들기로 했다. 하나씩 부러뜨려 보자.

리팩터링에 대한 단상

댓글