[리팩토링 2판] 2장. 리팩토링 원칙 (10월 12일)

리팩토링 정의

리팩토링 → 겉보기 동작은 유지한 채, 이해하기 쉽게 내부 구조를 변경하는 기법

리팩토링 과정에서 발견된 버그는 리팩토링 후에도 남아 있어야 한다.

리팩토링은 코드를 이해하고 수정하기 쉽게 만드는 것이다.

리팩토링을 진행하며 버그를 고치지 말라고 하는데... 눈앞에 버그를 놔두고 지나가야 하는 건가 라는 의문이 든다.

 

리팩토링 하는 이유

• 코드만 봐서는 설계를 파악하기 어렵다.
• 코드량이 줄면 수정하는데 드는 노력은 크게 달라진다.
• 모든 코드가 언제나 고유한 일을 수행함을 보장한다.
• 내 의도를 더 명확하게 전달하기 위해
• 다른 사람을 배려하기 위해서가 아니라 바로 나 자신을 위해
• 버그를 찾기 쉽다.

기억할 필요가 있는 것들은 최대한 코드에 담아내자 (외부에 담으려 X)

 

일단 리팩토링을 하는 이유로 가장 와닿았던 이유는 나 자신을 위해 해야 한다고 하는 것이다.

여러 프로젝트를 동시에 진행하다 보면 내가 작성했던 코드들도 기억이 가물가물 할 때가 있다.

작성하는 당시에는 진행사항들이 머릿속에 있어서 이해하기 쉬웠지만 시간이 지나면 기억하기 어렵기 때문이다.

많은 코드들을 다시 되짚어봐야 하기 때문에 위의 이유들이 맞다고 생각이 든다.

 

언제 리팩토링해야 할까?

• 비슷한 일을 세 번째 하게 되면 리팩토링한다.
• 간단히 수정할 수 있는 것은 즉시, 시간이 좀 걸리는 일은 메모 후 하던 일 끝내고 한다.
• 기능을 추가하거나 버그를 잡는 동안 함께 한다.

비슷한 코드가 2번만 겹쳐도 리팩토링해야 되겠다는 생각이 든다. (물론 생각만)

리팩토링을 귀찮아하지 말자

 

리팩토링 시 고려할 문제

• 내가 직접 건드릴 일이 거의 없거나, 불편한 정도가 심하지 않다고 판단되면 리팩토링하지 않는다.

위의 의견은 아직까지는 잘 모르겠다. 확실히 내가 작성하지 않아서 그 코드들을 100% 이해하지 못했다면

함부로 건들지 않는 것이 좋을 듯하다.

 

리팩토링과 성능

리팩토링을하면 소프트웨어가 느려질 수도 있다. 하지만 성능을 튜닝하기는 더 쉬워진다.

먼저 튜닝하기 쉽게 만들고 원하는 속도가 나게끔 튜닝한다.

 

무조건 속도가 빠르다고 좋은 코드는 아니라고 생각한다.

속도가 빠른데 읽기 어려운 코드라면... 전혀 도움이 되지 않는다.

 

개발자가 알아보지 못하는데 속도가 빨라서 무엇하리...

 

리팩토링의 유래

실력 있는 프로그래머는 항상 자신의 코드를 정리하는 데 어느 정도의 시간을 할애해왔다.

인터페이스만 잘 정의해두면 내부 수정이 외부에 미치는 영향을 최소로 할 수 있다.

 

개발하다 보면 여러 중복된 코드들이 보이고 그 코드들을 수정하기 위해서 여러 곳을

왔다 갔다 하며 반복된 일을 하게 되었을 때를 마주치면 리팩토링 마려울 것 같다.

 

리팩토링 했을 때와 안 했을 때의 코드 수정 시간 차이와

버그 발생 확률은 경험이 별로 없는 내가 봐도 엄청나다.