chapter2.md

리팩터링 chp2. 리팩터링 원칙

​

두 개의 모자

• 기능을 추가 할때는 ‘기능 추가’ 모자를 쓴 다음 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 하자
• 리팩터링 할 때는 ‘리팩터링’ 모자를 쓴 다음 기능 추가는 절대 하지 않기로 하자. 오로지 코드 재구성에만 전념한다. ​

리팩터링 해야하는 이유

리팩터링을 하면 소프트웨어 설계가 좋아진다.

• 아키텍쳐를 충분히 이해하지 못한 채 단기목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽다.
• 반면, 규칙적인 리팩터링은 코드의 구조를 지탱해준다. ​

리팩터링을 하면 소프트웨어를 이해하기 쉬워진다.

• 프로그램을 동작시키는데만 신경쓰다 보면 나중에 그 코드를 다룰 개발자를 배려하지 못한다. ​

리팩터링을 하면 버그를 쉽게 찾을 수 있다.

• 리팩터링을 하면 코드가 하는 일을 깊게 파악하면서, 새로 깨달은 것을 곧바로 코드에 반영하게 된다.
• 프로그램의 구조를 명확하게 다듬으면 그냥 ‘이럴 것이다’라고 가정하던 점들이 분명히 드러나는데, 버그를 지나치려야 지나칠 수 없을 정도까지 명확해진다. ​

리팩터링을 하면 프로그래밍 속도를 높일 수 있다.

• 새로운 기능을 추가할 수록, 기존 코드베이스에 잘 녹여낼 방법을 찾는데 드는 시간이 늘어난다.
• 내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.
• 즉, 내부 설계에 심혈을 기울이면 소프트웨어의 지구력이 높아져서 빠르게 개발 할 수 있는 상태를 오래 지속 할 수 있다. ​

언제 리팩터링할까?

1. 처음에는 그냥 한다.
2. 비슷한 일을 두번째로 하게 되면(중복되는 사실에 당황스럽겠지만), 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링 한다. ​

리팩터링 시 고려할 문제

• 리팩터링의 본질은 코드 베이스를 예쁘게 꾸미는데 있지 않다. 오로지 경제적인 이유로 하는 것이다. 리팩터리은 개발기간을 단축하고자 하는 것이다. 기능 추가 시간을 줄이고, 버그 수정 시간을 줄여준다.
• 아무튼..리팩터링을 이끄는 동력은 언제까지나 경제적인 효과에 있다. ​

리팩터링, 아키텍쳐, YAGNI

유연성 매커니즘

• 함수를 정의하다보면, 범용적으로 사용 할 수 있겠다는 생각이 들 때가 있다. 이 때, 다양한 에상 시나리오에 대응하기 위한 매기변수를 추가한다. 이런 매개변수가 바로 유연성 매커니즘이다.
• 하지만..유연성 매커니즘을 잘못 구현하면 오히려 변화애에 대응하는 능력을 떨어뜨리기 일쑤이다. ​

YAGNI

• 따라서, 앞으로 어느 부분에 유연성이 필요하고, 어떻게 해야 그 변화에 가장 잘 대응할 수 있을지 추측하지 않고 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다.
• 진행하면서 사용자의 요구사항을 더 잘 이해하게 되면 아키텍쳐도 그에 맞게 리팩터링해서 바꾼다.
• 그 과정에서 소프트웨어의 복잡도에 지장을 주지 않는 매커니즘은 마음껏 추가하지만, 복잡도를 높일 수 있는 유연성 메커니즘은 반드시 검증을 거친 후에 추가한다.