<div id="readability-page-1" class="page"><div><article><div><p><h2 id="9d8f">리팩터링 2판 스터디</h2></p><p id="8fd7">재밋게도 리펙토링이 필요한 느낌이 드는 상황을 냄새(악취)로 표현했다.</p><p id="a44c"><em>이탤릭체는 내 의견을 덧붙인 것이다.</em></p><h2 id="ef53">악취1 기이한 이름</h2><ul><li id="f1e0">이름짓기는 프로그래밍에서 <strong>가장 어렵기로 손꼽</strong>히는 두 가지중 하나다. 그 때문에 우리가 가장 많이 사용하는 리팩터링도 이름을 바꾸는 리팩터링이다. ⇒ <strong>문맥파악에 들이는 시간을 크게 절약</strong>할 수 있다.</li><li id="3eba"><em>&lt;</em><a href="http://www.yes24.com/Product/Goods/105911017" rel="noopener ugc nofollow" target="_blank"><em>프로그래머의 뇌</em></a><em>&gt;에서 텍스트를 읽는 것과 코드를 읽는 것은 유사하다 라고 얘기한바 있다. 이런 맥락에서보면 이름을 잘 지어야 잘 읽을 수 있는 코드가 된다. 이름짓기를 잘하면 코드의 문맥 파악에 들이는 시간을 절약할 수 있다는 것이 자연스럽게 이해가 된다.</em></li></ul><h2 id="5b7d">악취2 중복코드</h2><h2 id="1c65">악취3 긴 함수</h2><ul><li id="8c9d">짧은 함수의 중요성 ⇒ <strong>간접 호출(indirection)</strong>의 효과, 즉 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점은 함수를 짧게 구성할 때 나오는 것이다.</li><li id="1881"><em>자바스크립트의 간접호출 역할을 가능하게 하는 메서드는 call/apply/bind등이 있다.</em></li><li id="df92">함수가 많아지면 비용이 증가? ⇒ 요즘 언어는 함수 호출 비용이 거의 없다.</li><li id="0a7c">코드를 읽을때 함수를 왔다갔다 해야하는 부담이 있지만 도구를 사용하면 부담이 줄어든다. 그것보다 더 좋은 방법은 <strong>좋은 이름 짓기</strong>이다.</li><li id="35f8">주석을 달아야 할 만한 부분은 함수로 만든다</li><li id="1986">무엇을 하는지 코드가 잘 설명하지 못할수록 함수로 만드는게 유리하다.</li><li id="2f0b">매개변수와 임시변수가 많으면 함수 추출 작업에 방해가 된다.</li><li id="2563">조건문이나 반복문도 함수 추출의 실마리를 제공한다.</li></ul><h2 id="ad9a">악취4 긴 매개변수 목록</h2><ul><li id="c65e">매개변수를 질의 함수로 바꾸기 11.5절</li><li id="265f">객체 통째로 넘기기 11.4절</li><li id="abd1">매개변수 객체 만들기 6.8절</li><li id="db42">플래그 인수 제거하기 11.3절</li><li id="6330">여러 함수를 클래스로 묶기 6.9절</li></ul><h2 id="f205">악취 5 전역 데이터</h2><ul><li id="8fbb">악취 중 가장 지독한 축에 속한다.</li><li id="8cd2">전역 데이터는 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제. ⇒ 끊임없는 버그.</li><li id="133e">가장 좋은 방법은 변수 캡슐화하기 6.6절</li><li id="5b28"><strong>접근자 함수</strong>는 클래스나 모듈에 집어넣어 접근범위를 줄이는 것도 좋다.</li><li id="6335"><em>접근자 함수란 변수의 값을 반환하는 함수.</em></li></ul><h2 id="817b">악취6 가변 데이터</h2><ul><li id="836a">데이터를 변경하면 예상치 못한 사이드 이펙트가 나오기 쉽고 원인 찾기가 어려운 경우도 있다.</li><li id="6420">이런 이유로 함수형 프로그래밍에서는 데이터를 변경하려면 반드시 변경하려는 값에 해당하는 복사본을 만들어서 반환한다는 개념을 기본으로 삼고 있다.</li><li id="2bf0">방법들: 변수 캡슐화하기(정해놓은 함수를 거쳐야만 값을 수정할 수 있도록), 변수 쪼개기(역할 하나 당 변수 하나), 문장 슬라이드하기(관련코드들을 가까이 모아 놓기), 함수 추출하기(변수 갱신하는 로직을 함수로 추출), <strong>질의 함수</strong>와 <strong>변경 함수</strong> 분리하기, 세터 제거하기, <strong>파생변수</strong>를 <strong>질의함수</strong>로 바꾸기, 여러 함수를 클래스로 묶기(유효범위 제한), 여러 함수를 변환 함수로 묶기(유효범위 제한), 참조를 값으로 바꾸기(값은 불변이다. 불변이 다루기 더 쉽다.)</li><li id="c578"><em>나의 생각: 웹 프레임워크 생태계에서 말하는 상태관리에서 상태의 참조를 값으로 관리함으로써 불변성을 이뤄내고 히스토리를 만들어 관리를 용이하게 한것이 아닌가.</em></li></ul><h2 id="61f5">악취7 뒤엉킨 변경</h2><ul><li id="eaa0">뒤엉킨 변경은 단일 책임 원칙(SRP)이 제대로 지켜지지 않을 때 나타난다.</li></ul><h2 id="9f7f">악취8 산탄총 수술</h2><ul><li id="5757">뒤어킨 변경과 비슷하면서 정반대다. 코드를 변경할 때마다 수정해야하는 클래스가 많을 때 풍긴다.</li></ul><h2 id="a7f1">악취9 기능 편애</h2><ul><li id="8b71">어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 함수의 데이터와 상호작용이 더 많을 때 풍기는 냄새.</li><li id="eb87">해법은 함수 옮기기 : 가까워지고 싶어하는 데이터 근처 혹은 특정 함수의 모듈로 옮겨주기.</li></ul><h2 id="7118">악취10 데이터 뭉치</h2><ul><li id="7e34">서로 어울려 몰려다니는 데이터 뭉치는 클래스 추출하기로 하나의 객체로 묶는다.</li><li id="4d62">메서드 시그니처에 있는 데이터 뭉치의 경우 매개변수 수를 줄여본다.</li><li id="7bc8">데이터 뭉치인지 판별하려면 값 하나를 삭제했을때 나머지 데이터만으로는 의미가 없다면 객체로 환생하길 갈망하는 데이터뭉치임.</li></ul><h2 id="790b">악취11 기본형 집착</h2><ul><li id="f4f6">화폐, 좌표, 구간등을 기본형으로 표현하면 악취가 난다.</li><li id="fd3d">기본형을 객체로 바꾸기</li><li id="7b0d">기본형으로 표현된 코드가 조건부 동작을 제어하는 타입코드로 쓰였다면 타입 코드를 서브클래스로 바꾸기와 조건부 로직을 다형성으로 바꾸기를 차례로 적용.</li><li id="452e">데이터 뭉치와 관련있다.</li></ul><h2 id="10cd">악취12 반복되는 switch문</h2><ul><li id="ffde">모든 반복문과 스위치문이 리팩토링 대상은 아님</li><li id="9e76">중복된 스위치문이나 길게 나열된 조건문이 등장할때 냄새남.</li><li id="e9b7">다형성이 해결책.</li></ul><h2 id="01c9">악취13 반복문</h2><ul><li id="85ac">반복문을 파이프라인으로 바꾸기.</li></ul><pre><span id="1490">const names = input<br>  .filter(i =&gt; i.job === "programmer")<br>  .map(i =&gt; i.name) <br>;</span></pre><h2 id="6e93">악취14 성의없는 요소</h2><ul><li id="54a3">본문 코드를 그대로 쓰는것과 진배없는 함수</li><li id="bd48">예를 들면, 메서드 하나뿐인 클래스</li></ul><h2 id="6983">악취15 추측성 일반화 : 너무 미리 대비해 놓은 코드들</h2><ul><li id="13f2">어떤 경우냐 하면</li><li id="82d7">하는 일이 없는 추상 클래스 혹은</li><li id="0274">쓸데없이 위임하는 코드 혹은</li><li id="86e3">사용되지 않은 매개변수 혹은</li><li id="476b">테스트 코드에서만 사용하는 함수나 클래스(죽은 코드)</li></ul><h2 id="c47b">악취16 임시 필드</h2><ul><li id="a1be">특정 상황에서만 값이 설정되는 필드. 쓰이지 않는 것처럼 보이는 이 필드의 존재 이유를 파악하기 어려움.</li><li id="74bb">해법: 관련된 곳으로 옮겨준다.</li></ul><h2 id="a133">악취17 메시지 체인</h2><ul><li id="2602">위임 숨기기로 해결한다.</li></ul><pre><span id="86a0">managerName = aPerson.department.manager.name; <br>managerName = aPerson.managerName; // department, manager의 존재를 숨김.</span></pre><h2 id="efdf">악취18 중개자</h2><ul><li id="a382">클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하고 있다면 중개자 제거하기를 활용하여 객체와 직접 소통.</li></ul><h2 id="0668">악취19 내부자 거래</h2><ul><li id="d568">모듈 사이의 데이터 거래가 많으면 결합도(coupling)가 높아진다. 거래양을 최소로 줄이고 투명하게 처리해야.</li></ul><h2 id="cc9e">악취20 거대한 클래스</h2><ul><li id="f8df">한 클래스가 너무 많은 일을 하려다 보면 필드 수가 상당히 늘어난다. 필드가 너무 많으면 중복 코드가 생기기 쉽다.</li></ul><h2 id="c2a6">악취21 서로다른 인터페이스의 대안 클래스들</h2><h2 id="5407">악취22 데이터 클래스</h2><ul><li id="0c3f">데이터 클래스란 데이터 필드와 게터/세터 메서드로만 구성된 클래스.</li><li id="9f2e">공개될 필요가 없는것은 비공개로</li><li id="b40b">변경하면 안되는 필드가 있다면 세터를 제거.</li><li id="5fa3">다른 클래스의 메서드로 옮길 수 있는지 살펴보기</li><li id="4a1b">불변데이터는 게터 없이 필드를 공개해도 된다.</li></ul><h2 id="2582">악취23 상속 포기</h2><ul><li id="6607">서브 클래스가 부모의 유산을 원치 않거나 필요없을 때.</li><li id="67d6">부모의 코드와 필드를 서브클래스로 내리기. 심하게는 추상 클래스로 만들기.</li><li id="6a55">열에 아홉은 냄새가 심하지는 않음.</li><li id="8e93">서브클래스를 위임으로 바꾸기 등으로 상속 메커니즘을 벗어나야 할때도 있다.</li></ul><h2 id="ae92">악취24 주석</h2><ul><li id="25bb">주석이 장황하면 코드가 잘못된 경우 많음.</li><li id="7025">주석이 코드 블록을 설명하고 있다면 함수 추출하기 6.1</li><li id="5682">함수로 추출했는데도 설명이 필요하다면 함수 이름을 바꾸기 6.5</li><li id="b402">선행조건을 명시하고 싶다면 어서션 추가하기 10.6</li><li id="f03d">주석은 건망증이 심한 프로그래머에게 유용할수도</li></ul></div></article></div></div>

Stories by Jeong Woo Ahn on Medium

Jeongwoo Ahn

리팩터링 2판 스터디
재밋게도 리펙토링이 필요한 느낌이 드는 상황을 냄새(악취)로 표현했다.
이탤릭체는 내 의견을 덧붙인 것이다.
악취1 기이한 이름
이름짓기는 프로그래밍에서 가장 어렵기로 손꼽히는 두 가지중 하나다. 그 때문에 우리가 가장 많이 사용하는 리팩터링도 이름을 바꾸는 리팩터링이다. ⇒ 문맥파악에 들이는 시간을 크게 절약할 수 있다.
<프로그래머의 뇌>에서 텍스트를 읽는 것과 코드를 읽는 것은 유사하다 라고 얘기한바 있다. 이런 맥락에서보면 이름을 잘 지어야 잘 읽을 수 있는 코드가 된다. 이름짓기를 잘하면 코드의 문맥 파악에 들이는 시간을 절약할 수 있다는 것이 자연스럽게 이해가 된다.
악취2 중복코드
악취3 긴 함수
짧은 함수의 중요성 ⇒ 간접 호출(indirection)의 효과, 즉 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점은 함수를 짧게 구성할 때 나오는 것이다.
자바스크립트의 간접호출 역할을 가능하게 하는 메서드는 call/apply/bind등이 있다.
함수가 많아지면 비용이 증가? ⇒ 요즘 언어는 함수 호출 비용이 거의 없다.
코드를 읽을때 함수를 왔다갔다 해야하는 부담이 있지만 도구를 사용하면 부담이 줄어든다. 그것보다 더 좋은 방법은 좋은 이름 짓기이다.
주석을 달아야 할 만한 부분은 함수로 만든다
무엇을 하는지 코드가 잘 설명하지 못할수록 함수로 만드는게 유리하다.
매개변수와 임시변수가 많으면 함수 추출 작업에 방해가 된다.
조건문이나 반복문도 함수 추출의 실마리를 제공한다.
악취4 긴 매개변수 목록
매개변수를 질의 함수로 바꾸기 11.5절
객체 통째로 넘기기 11.4절
매개변수 객체 만들기 6.8절
플래그 인수 제거하기 11.3절
여러 함수를 클래스로 묶기 6.9절
악취 5 전역 데이터
악취 중 가장 지독한 축에 속한다.
전역 데이터는 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제. ⇒ 끊임없는 버그.
가장 좋은 방법은 변수 캡슐화하기 6.6절
접근자 함수는 클래스나 모듈에 집어넣어 접근범위를 줄이는 것도 좋다.
접근자 함수란 변수의 값을 반환하는 함수.
악취6 가변 데이터
데이터를 변경하면 예상치 못한 사이드 이펙트가 나오기 쉽고 원인 찾기가 어려운 경우도 있다.
이런 이유로 함수형 프로그래밍에서는 데이터를 변경하려면 반드시 변경하려는 값에 해당하는 복사본을 만들어서 반환한다는 개념을 기본으로 삼고 있다.
방법들: 변수 캡슐화하기(정해놓은 함수를 거쳐야만 값을 수정할 수 있도록), 변수 쪼개기(역할 하나 당 변수 하나), 문장 슬라이드하기(관련코드들을 가까이 모아 놓기), 함수 추출하기(변수 갱신하는 로직을 함수로 추출), 질의 함수와 변경 함수 분리하기, 세터 제거하기, 파생변수를 질의함수로 바꾸기, 여러 함수를 클래스로 묶기(유효범위 제한), 여러 함수를 변환 함수로 묶기(유효범위 제한), 참조를 값으로 바꾸기(값은 불변이다. 불변이 다루기 더 쉽다.)
나의 생각: 웹 프레임워크 생태계에서 말하는 상태관리에서 상태의 참조를 값으로 관리함으로써 불변성을 이뤄내고 히스토리를 만들어 관리를 용이하게 한것이 아닌가.
악취7 뒤엉킨 변경
뒤엉킨 변경은 단일 책임 원칙(SRP)이 제대로 지켜지지 않을 때 나타난다.
악취8 산탄총 수술
뒤어킨 변경과 비슷하면서 정반대다. 코드를 변경할 때마다 수정해야하는 클래스가 많을 때 풍긴다.
악취9 기능 편애
어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 함수의 데이터와 상호작용이 더 많을 때 풍기는 냄새.
해법은 함수 옮기기 : 가까워지고 싶어하는 데이터 근처 혹은 특정 함수의 모듈로 옮겨주기.
악취10 데이터 뭉치
서로 어울려 몰려다니는 데이터 뭉치는 클래스 추출하기로 하나의 객체로 묶는다.
메서드 시그니처에 있는 데이터 뭉치의 경우 매개변수 수를 줄여본다.
데이터 뭉치인지 판별하려면 값 하나를 삭제했을때 나머지 데이터만으로는 의미가 없다면 객체로 환생하길 갈망하는 데이터뭉치임.
악취11 기본형 집착
화폐, 좌표, 구간등을 기본형으로 표현하면 악취가 난다.
기본형을 객체로 바꾸기
기본형으로 표현된 코드가 조건부 동작을 제어하는 타입코드로 쓰였다면 타입 코드를 서브클래스로 바꾸기와 조건부 로직을 다형성으로 바꾸기를 차례로 적용.
데이터 뭉치와 관련있다.
악취12 반복되는 switch문
모든 반복문과 스위치문이 리팩토링 대상은 아님
중복된 스위치문이나 길게 나열된 조건문이 등장할때 냄새남.
다형성이 해결책.
악취13 반복문
반복문을 파이프라인으로 바꾸기.
const names = input
  .filter(i => i.job === "programmer")
  .map(i => i.name) 
;
악취14 성의없는 요소
본문 코드를 그대로 쓰는것과 진배없는 함수
예를 들면, 메서드 하나뿐인 클래스
악취15 추측성 일반화 : 너무 미리 대비해 놓은 코드들
어떤 경우냐 하면
하는 일이 없는 추상 클래스 혹은
쓸데없이 위임하는 코드 혹은
사용되지 않은 매개변수 혹은
테스트 코드에서만 사용하는 함수나 클래스(죽은 코드)
악취16 임시 필드
특정 상황에서만 값이 설정되는 필드. 쓰이지 않는 것처럼 보이는 이 필드의 존재 이유를 파악하기 어려움.
해법: 관련된 곳으로 옮겨준다.
악취17 메시지 체인
위임 숨기기로 해결한다.
managerName = aPerson.department.manager.name; 
managerName = aPerson.managerName; // department, manager의 존재를 숨김.
악취18 중개자
클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하고 있다면 중개자 제거하기를 활용하여 객체와 직접 소통.
악취19 내부자 거래
모듈 사이의 데이터 거래가 많으면 결합도(coupling)가 높아진다. 거래양을 최소로 줄이고 투명하게 처리해야.
악취20 거대한 클래스
한 클래스가 너무 많은 일을 하려다 보면 필드 수가 상당히 늘어난다. 필드가 너무 많으면 중복 코드가 생기기 쉽다.
악취21 서로다른 인터페이스의 대안 클래스들
악취22 데이터 클래스
데이터 클래스란 데이터 필드와 게터/세터 메서드로만 구성된 클래스.
공개될 필요가 없는것은 비공개로
변경하면 안되는 필드가 있다면 세터를 제거.
다른 클래스의 메서드로 옮길 수 있는지 살펴보기
불변데이터는 게터 없이 필드를 공개해도 된다.
악취23 상속 포기
서브 클래스가 부모의 유산을 원치 않거나 필요없을 때.
부모의 코드와 필드를 서브클래스로 내리기. 심하게는 추상 클래스로 만들기.
열에 아홉은 냄새가 심하지는 않음.
서브클래스를 위임으로 바꾸기 등으로 상속 메커니즘을 벗어나야 할때도 있다.
악취24 주석
주석이 장황하면 코드가 잘못된 경우 많음.
주석이 코드 블록을 설명하고 있다면 함수 추출하기 6.1
함수로 추출했는데도 설명이 필요하다면 함수 이름을 바꾸기 6.5
선행조건을 명시하고 싶다면 어서션 추가하기 10.6
주석은 건망증이 심한 프로그래머에게 유용할수도
이 글이 마음에 드셨다면 👏🏽👏🏽와 커피한잔 후원하기 (카카오페이), 이메일로 소식을 받아보고 싶으시다면 ✉️ 이메일 구독하기 해주세요.

3장 코드에서 나는 악취

댓글