02 리팩터링 원칙

1. 리팩터링 정의

• 명사 : 소프트웨어 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부구조의 변경
• 동사 : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용 해서 소프트웨어를 재구성한다.
• 코드정리와 리팩터링은 다르다. 리팩터링 도중 코드가 깨져서 동작하지 않는다면 리팩터링 한것이 아니다.
• 리팩터링 동안에는 코드가 항상 정상 작동하기 때문에 작업이 끝나지 않았더라도 언제든 멈출 수 있다.

2. 두개의 모자

• 소프트웨어를 개발할 때 목적이 '기능추가'인가 아니면 '리팩터링'이냐를 명확히 구분해야 한다.
• 항상 내가 쓰고 있는 모자가 무엇인지와 그에 따른 미묘한 작업 방식 차이를 분명하게 인식해야한다.

3. 리팩터링하는 이유

코드를 건강한 상태로 유지하는 데 도와주는 약

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

• 리팩터링 하지 않으면 소프트웨어의 아키텍처가 썩기 쉽다.
• 코드 구조가 무너지기 시작하면 악효과가 누적된다.
• 코드만으로 설계를 파악하기 어려워 질수록 설계를 유지하기 어려워지고, 설계가 부패되는 속도는 더욱 빨라진다.
• 같은 일을 하더라도 설계가 나쁘면 코드가 길어진다.
• 중복 코드 제거는 설계 개선 작업의 중요한 한 축이고, 중복 코드를 제가하면 모든 코드가 언제나 고유한 일을 수행함을 보장할 수 있으며, 바람직한 설계의 핵심

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

• 프로그램을 동작시키는 데만 신경 쓰다 보면 나중에 그 코드를 다룰 개발자를 배려하지 못한다는 데 있다.
• 단지 다른 사람을 배려하기 위해서가 아니라 나 자신을 위해서 리팩터링이 중요하다.

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

• 코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말

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

- 내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.
- 모듈화가 잘 되어 있으면 전체중 작은 일부분의 코드만 이해하면 된다.
- 코드가 명확하면 버그를 만들 가능성도 줄고, 버그를 만들더라도 디버깅하기가 훨씬 쉽다.

4. 언제 리팩터링해야 할까?

4-1. 준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기

• 리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다. 이 시점에 현재 코드를 살펴보면서, 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 만한 부분을 찾는다.
• 버그를 잡을때도, 오류를 일으키는 코드가 복제되어 퍼져 있다면, 우선 한곳으로 합치는 편이 작업하기 훨씬 편하다.

4-2. 이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기

• 코드를 파악할 때마다 그 코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지를 찾아본다.

4-3. 쓰레기 줍기 리팩터링

• 코드를 파악하던 중 비효율적으로 처리하는 모습을 발견할때가 있다. 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 걸리는 일은 짧은 메모만 남긴 다음. 하던 일을 끝내고 나서 처리한다.

4-4. 계획된 리팩터링과 수시로 하는 리팩터링

• 정기적으로 리팩터링 하더라도 어떤 문제는 팀원 여럿 달려들어야 할 정도로 곪아갈 수도 있다. 하지만 이런 이유로 계획된 리팩터링을 하게 되는 일은 최소한으로 줄여야 한다.
• 리팩터링 작업 대부분은 드러나지 않게, 기회가 될 때마다 해야한다.

4-5. 오래 걸리는 리팩터링

• 주어진 문제를 몇 주에 걸쳐 조금씩 해결해가는 편이 효과적
• 누구든지 리팩터링해야할 코드와 관련한 작업을 하게 될 때마다 원하는 방향으로 조금씩 개선
• 리팩터링이 코드를 깨트리지 않는다는 장점을 활용하는 것

4-6. 코드 리뷰에 리팩터링 활용하기

• 코드 리뷰는 개발팀 전체에 지식을 전파하는데 좋다.
• 코드 리뷰를 하면 다른 사람의 아이디어를 얻을 수 있다는 장점도 있다.
• 리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는 데에도 도움된다.
• 작성자와 나란히 앉아서 코드를 훑어가면서 리팩터링하는 것이 Pair Programming이다.

4-7. 관리자에게는 뭐라고 말해야 할까?

• 소프트웨어 개발자는 프로다. 프로 개발자의 역할은 효과적인 소프트웨어를 최대한 빨리 만드는 것이다.
• 경험상 리팩터링하면 소프트웨어를 빠르게 만드는데 아주 효과적이다.

4-8. 리팩터링하지 말아야 할 때

• 지저분한 코드를 발견해도 굳이 수정할 필요가 없을 때
• 리팩터링하는 것보다 처음부터 새로 작성하는게 쉬울 때
  

5. 리팩터링 시 고려할 문제

5-1. 새 기능 개발 속도 저하

• 리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것.
• 건강한 코드의 위력을 충분히 경험해보지 않고서는 코드베이스가 건강할 때와 허약할 때의 생산성 차이를 체감하기 어렵다.

5-2. 코드 소유권

• 복잡해지기 때문에 코드 소유권을 작은 단위로 나눠 엄격히 관리하는데 반대
• 코드소유권을 팀에 두어 팀원이라면 누구나 팀이 소유한 코드를 수정할 수 있게 한다.

5-3. 브랜치

• CI와 리팩터링을 합친 익스트림 프로그래밍(XP)
• 기능별 브랜치를 사용하면 안된다는 말이 아니다. 브랜치를 자주 통합할 수 있다면 문제가 발생할 가능성을 크게 줄일 수 있다.

5-4. 테스팅

• 리팩터링의 두드러진 특성은 프로그램의 겉보기 동작은 똑같이 유지된다는 것이다.
• 리팩터링 하기 위해서는 테스트 코드를 마련해야 한다.
• 테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라, 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다.
• 리팩터링 과정에서 버그가 생길 위험이 아주 크다는 불안감을 해소할 수 있다.
• 테스트 코드는 통합 과정에서 발생하는 충돌을 잡는 메커니즘으로 활용할 수 있어 자연스럽게 CI와도 밀접하게 연관.

5-5. 레거시 코드

• 레거시 시스템을 파악할 때 리팩터링이 굉장히 도움된다.

5-6. 데이터베이스

• 다른 리팩터링과 마찬가지로 전체 변경 과정을 작고 독립된 단계들로 쪼개는 것이 핵심
• 데이터베이스 리팩터링은 프로덕션 환경에서 여러 단계로 나눠서 릴리스하는 것이 대체로 좋다는 점에서 다른 리팩터링과 다르다.

6. 리팩터링, 아키텍쳐, 애그니(YAGNI)

• 리팩터링이 아키텍처에 미치는 실질적 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는데 있다.
• 코딩전에 아키텍처를 확정지으려는 것은 불가능.
• 소프트웨어를 실제로 사용해보고 업무에 미치는 영향을 직접 확인하고 나서야 정말로 원하는 바를 알게 되는 경우가 허다하다.
• YAGNI는 아키텍처와 설계를 개발 프로세스에 녹이는 또 다른 방식이며, 리팩터링의 뒷받침 없이는 효과를 볼 수 없다.

7. 리팩터링과 소프트웨어 개발 프로세스

• 자가 테스트 코드와 리팩터링을 묶어서 테스트 주도 개발(TDD)
• 리팩터링의 첫 번째 토대는 자가 테스트 코드
• 팀으로 개발하면서 리팩터링을 하려면 각 팀원이 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링할 수 있어야 한다.

8. 리팩터링과 성능

• 리팩터링을 하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 그와 동시에 성능을 튜닝하기 더 쉬워진다.
• 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비
• 리팩터링 후 성능에 큰 영향을 주는 부분만 집중해서 최적화

9. 리팩터링의 유래

• 워드와 켄트는 생산성을 높이는 데 리팩터링의 역할이 크다는 사실을 깨닫고, 그 후로 리팩터링을 실전 프로젝트에 활용하면서 개선해나갔다.

10. 리팩터링 자동화

• 리팩터링을 자동화하는 가장 어설픈 방법은 소스 코드의 텍스트를 직접 조작하는 것.

마무리

• 리팩터링, 테스트코드, 아키텍처는 서로 필수적이며 시너지를 낸다.
• 경험상 나쁜설계 프로그램이 복잡해 질 수록 유지보수 시간과 기능추가에 큰 어려움을 겪었었다.

참고
리팩터링 2판