[Java] 리팩터링 원칙

리팩터링 정의

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성한다.

 

리팩터링하는 동안에는 코드가 항상 정상 작동하기 때문에 전체 작업이 끝나지 않아도 언제든 멈출 수 있다

 

누군가 "리팩터링하다가 코드가 깨져서 며칠이나 고생했다"라고 한다면, 리팩터링한 것이 아니다

 

두개의 모자

소프트웨어를 개발할 때 목적이 '기능 추가'냐, 아니면 '리팩터링' 이냐를 명확히 구분해 작업

기능을 추가할 때는 '기능 추가' 모자를 쓴 다음 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다.

리팩터링할 때는 '리팩터링' 모자를 쓴 다음 기능 추가는 절대 하지 않기로 다짐한 뒤 오로지 코드 재구성에만 전념한다.

 

리팩터링하는 이유

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

아키텍처를 이해하지 못한 채 목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽고 

코드만 봐서는 설계를 파악하기 어려워진다. 그럴수록 설계를 유지하기 어려워지고, 설계가 부패된다.

규칙적인 리팩터링은 코드의 구조를 지탱해줄 것이다.

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

누군가 내 코드를 수정하고자 읽게 될 수 있다. 사실 그 누군가가 나 자신일 때가 많다.

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

리팩터링은 코드가 더 잘 읽히게 도와준다.

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

리팩터링하면 코드가 하는 일을 깊이 파악하게 되면서 새로 깨달은 것을 곧바로 코드에 반영하게 된다.

프로그램의 구조를 명확하게 다듬으면 버그를 지나치려야 지나칠 수 없을 정도까지 명확해진다.

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

새로운 기능을 추가할수록 버그가 발생하는 일이 잦고, 이를 해결하는 시간은 한층 더 걸린다.

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.

코드가 명확하면 버그를 만들 가능성도 줄고, 버그를 만들더라도 디버깅하기가 훨씬 쉽다.

 

처음부터 좋은 설계를 마련하기란 매우 어렵다.
리팩터링하면 기존 코드의 설계를 얼마든지 개선할 수 있으므로, 요구사항이 바뀌더라도 설계를 지속해서 개선할 수 있다.

 

언제 리팩터링해야 할까?

3의 법칙

1. 처음에는 그냥 한다.
2. 비슷한 일을 두번째로 하게 되면 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

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

리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전

구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 만한 부분을 찾는다

이해를 위한 리팩터링

코드를 수정하려면 먼저 그 코드가 하는 일을 파악해야 한다.

리팩터링하면 이해한 것을 코드에 옮겨 담을 수 있다.

쓰레기 줍기 리팩터링

간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음

하던 일을 끝내고 나서 처리한다.

작업을 잘게 나누면 몇 달에 걸쳐 진행하더라도 그 사이 한 순간도 코드가 깨지지 않기도 한다.

수시로 하는 리팩터링

리팩터링 시간을 일정에 잡아두지 않고, 다른 일을 하는 중에 리팩터링한다.

보기 싫은 코드를 발견하면 리팩터링하자. 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다.

 

뛰어난 개발자는 새 기능을 추가하기 쉽도록 코드를 수정하는 것이
그 기능을 가장 빠르게 추가하는 길일 수 있음을 안다.
새로 작성해 넣는 코드보다 기존 코드의 수정량이 큰 경우가 대체로 많다.

오래 걸리는 리팩터링

팀 전체가 오래 걸리는 리팩터링에 매달리는 데는 회의적이다.

주어진 문제를 몇 주에 걸쳐 조금씩 해결해가는 편이 효과적일 때가 많다.

코드 리뷰에 리팩터링 활용하기

리팩터링은 다른 이의 코드를 리뷰하는 데 도움된다.

가장 좋은 방법은 Pair Programming 으로 리팩터링하는 것

리팩터링하지 말아야 할 때

지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링하지 않는다.

외부 API 다루듯 호출해서 쓰는 코드라면 그냥 둔다.

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.

레거시 시스템의 규모가 크다면 자주 보는 부분을 더 많이 리팩터링한다.
코드를 훑게 되는 횟수가 많다는 말은 그 부분을 이해하기 쉽게 개선했을 때 얻는 효과도 그만큼 크다는 뜻이니

YAGNI

You aren't gonna need it

프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙

 

리팩터링과 성능

의도적으로 성능 최적화에 돌입하기 전까지는 성능에 신경 쓰지 않고 코드를 다루기 쉽게 만드는데 집중한다.

성능 최적화 단계가 되면 다음의 구체적인 절차를 따라 프로그램을 튜닝한다.

1. 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다.
2. 성능에 큰 영향을 주는 작은 부분들을 찾아서 개선한다.
3. 각 단계마다 컴파일과 테스트를 거치고 프로파일러를 다시 실행해본다.
4. 성능이 개선되지 않았다면 수정 내용을 되돌린다.

 

리팩터링은 성능 좋은 소프트웨어를 만드는 데 기여한다.

리팩터링이 잘 되어 있다면 기능 추가가 빨리 끝나서 성능에 집중할 시간을 더 벌 수 있다.

코드가 깔끔하면 개선안들이 더 잘 떠오를 것이고, 그중 어떤 튜닝이 효과가 좋을지 파악하기 쉽다.