|
| 1 | +# 1. 리팩토링이란? |
| 2 | + |
| 3 | +> 리팩토링은 코드를 변경하는 것이 아니다 |
| 4 | +
|
| 5 | +- 코드 동작을 바꾸면 안 된다는 것 |
| 6 | +- 코드 동작이 변하지 않는다는 것을 어떻게 보장? |
| 7 | +- 코드 동작은 변하지 않으면서 코드를 변경한다는 것은 어떤 의미일까? |
| 8 | + |
| 9 | +## 1.1 코드 동작이 변하지 않는다는 것을 어떻게 보장할 수 있을까? |
| 10 | + |
| 11 | +리팩토링할 때 동작의 모든 유형을 다루는 것이 아닌, 다음 내용을 주로 다룬다 |
| 12 | + |
| 13 | +- 구현 세부 사항 |
| 14 | +- 불특정하고 검증되지 않은 동작 |
| 15 | +- 성능 |
| 16 | + |
| 17 | +=> 테스트, 버전 관리를 사용 |
| 18 | + |
| 19 | +## 1.2 구현 세부 사항에 관심을 두면 어떨까? |
| 20 | + |
| 21 | +예를 들어, 숫자에 2를 곱하는 간단한 함수를 구현할 때 |
| 22 | + |
| 23 | +- `return number * 2` |
| 24 | +- `return number << 1` |
| 25 | + |
| 26 | +이런 부분이 구현 세부 사항 |
| 27 | + |
| 28 | +이때 `number` 값이 너무 커지면 두번째 경우는 문제가 발생 |
| 29 | + |
| 30 | +-> 테스트 케이스는 처음 생각했던 것보다 더 많은 경우를 포함해야 한다는 것을 의미 |
| 31 | + |
| 32 | +- 변경한 구현 세부 사항에서 숫자를 두 배로 한 부분이 우리가 신경 써야 할 동작, |
| 33 | +- 세부 사항 테스트는 대부분 불필요 |
| 34 | + |
| 35 | +## 1.3 불특정하고 검증되지 않은 동작에 관심을 두면 어떨까? |
| 36 | + |
| 37 | +실행 테스트, 수동 절차, 어떻게 동작하는지 최소한의 설명이 없으면 기본적으로 해당 코드를 검증할 수 없다는 것을 의미 |
| 38 | + |
| 39 | +테스트가 부족한 코드 또는 실행시킬 수 있는 최소한의 문서가 없는 코드는 코드를 변경하기 어렵고, 그러면 동작 변경을 검증할 수 없어 리팩토링하기 어렵다 |
| 40 | + |
| 41 | +> 테스트를 거치지 않은 코드는 리팩토링할 수 없다 |
| 42 | +
|
| 43 | +## 1.4 성능에 관심을 두면 어떨까? |
| 44 | + |
| 45 | +사용자는 성능보다는 동작과 기댓값에 더 중점을 둔다 |
| 46 | + |
| 47 | +첫번째 구현에서 결과가 충분히 좋다는 것은 적절한 시간 안에 입력으로 기댓값을 산출할 수 있다는 의미; 비기능적 검증 (nonfunctional testing) |
| 48 | + |
| 49 | +## 1.5 동작이 변하지 않는다면 리팩토링의 요점은? |
| 50 | + |
| 51 | +> 리팩토링의 요점은 행동을 유지하면서 품질을 향상하는 것 |
| 52 | +
|
| 53 | +## 1.6 품질 균형 잡기와 일 끝마치기 |
| 54 | + |
| 55 | +기술부채 |
| 56 | + |
| 57 | +- 소규모 프로젝트에서 가시적이고 설명 가능한 기술부채는 어느 정도 허용될 수 있지만, |
| 58 | +- 큰 프로젝트에서는 품질을 중요하게 여기며 진행해야 |
| 59 | + |
| 60 | +## 1.7 품질이란 무엇이며 리팩토링과 어떤 관련이 있을까? |
| 61 | + |
| 62 | +코드 품질을 좋게 하려는 수많은 노력들 |
| 63 | + |
| 64 | +- SOLID; 단일 책임, 개방 폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전 |
| 65 | +- DRY; 반복 X |
| 66 | +- KISS; 정말 간단해야 |
| 67 | +- GRASP; 일반적인 책임 할당 소프트웨어 패턴 |
| 68 | +- YAGNI; 나중에 필요 없어질 것을 고려 |
| 69 | + |
| 70 | +명확한 기준은 없다, 다만 제대로 작동하고 쉽게 확장될 수 있는 코드를 만드는 것 |
| 71 | + |
| 72 | +코드 테스트를 작성하고 쉽게 테스트할 수 있는 코드를 작성하는 것 |
| 73 | + |
| 74 | +- 인터페이스 단순화하기 위해 함수와 모듈 추출 |
| 75 | +- 테스트를 이용해 코드 동작 확인 |
| 76 | +- 가능하면 불순한 기능 피하기 |
| 77 | +- 변수 및 함수 이름 잘 짓기 |
| 78 | + |
| 79 | +자신만의 `소프트웨어 품질 원칙`을 구성해보라 |
| 80 | + |
| 81 | +## 1.8 탐험으로서 리팩토링 |
| 82 | + |
| 83 | +리팩토링은 코딩에 자신감을 갖게 하고 작업 중인 내용을 잘 이해하는 데 도움을 준다 |
| 84 | + |
| 85 | +## 1.9 어떤 것이 리팩토링이고 어떤 것이 아닐까? |
| 86 | + |
| 87 | +새로운 코드와 기능을 만드는 것은 리팩토링이 아니다 |
| 88 | + |
| 89 | +기존 코드에서 인터페이스(동작)에 대한 변경 사항은 테스트를 중단시키거나, 충분하지 않은 테스트를 하게 할 수 있음 |
| 90 | + |
| 91 | +반면 구현 세부 사항을 변경할 때는 테스트가 중단되어서는 안된다 |
| 92 | + |
| 93 | +## 1.10 마무리 |
0 commit comments