[실용주의 프로그래머] 리팩터링

[실용주의 프로그래머] 리팩터링

-

코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져 있어야 할 두 개를 발견했을 때, 어떤 것이든 ‘잘못’ 되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. 어떤 것이라도 코드를 리팩터링해야 할 이유가 될 수 있다.

중복, 직교성이 좋지 않은 설계, 유효기간이 끝난 지식, 성능

-

코드를 리팩터링하는 것은 사실 고통 관리(pain management)를 실천하는 것이다.

현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다.

거의 작동하는 수준까지 올려놓은 코드였는데, 이제 완전히 망가져 버린다.

코드를 산산조각으로 해체하는 일을 주저하는 개발자들이 많은데, 그 까닭은 그런 일을 하면 안 될 것 같기 떄문이다.

-

리팩터링을 하지 않는 핑계로 자주 사용되는 이유가 일정의 압박이다. 하지만 이것은 설득력 있는 이유가 되지 못한다.

지금 리팩터링을 하지 않으면, 일이 더 진척되었을 때, 곧 신경 써야 할 의존성이 더 많이 생겼을 때 문제를 고치기 위해 훨씬 더 많은 시간을 투자해야 한다.

그 때가 되면 일정에 더 여유가 생길까? 경험에 비추어 봤을 때 그런 일은 없다.

-

상사에게 리팩터링이 필요한 코드를 “종양” 이라고 설명하자.

종양을 제거하려면 수술이 필요하다.

지금 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다.

하지만 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다.

하지만 그 때가 되면 제거하는 데 드는 비용도 더 커질 뿐더러 위험도 훨씬 커진다.

시간을 더 끌면, 환자는 생명을 잃을지도 모른다.

-

일찍 리팩터링하고, 자주 리팩터링하라.

-

리팩터링해야 할 것들의 명단을 만들고 유지하라.

어떤 것을 지금 당장 리팩터링하기 힘들다면, 일정에 그것을 리팩터링할 시간을 확실히 포함시켜 두도록 한다.

-

리팩터링에 대한 조언.

1. 리팩터링과 새로운 기능 추가를 동시에 하지 말라.

2. 리팩터링을 시작하기 전 든든한 테스트 집합이 있는지 먼저 확인한다. 할 수 있는 한 자주 테스트들을 돌려본다.

3. 단계를 작게 나누어서 신중하게 작업한다. 단계를 작게 나누고, 한 단계가 끝날 때마다 테스트를 돌린다.

-

탄탄한 회귀 테스트 집합을 유지하는 것이야말로 확신을 가지고 리펙터링하기 위한 비결이다.

-

모듈에 큰 변화가 있다면, 즉 모듈의 인터페이스나 기능을 이전과 호환성을 유지할 수 없을 정도로 변경하는 변화가 있다면, 일부러 빌드를 실패하도록 변화를 주는 기법도 유용하다.

리팩터링 대상 코드에 의존하는 옛날 코드들이 컴파일이 안 되게 만들어버리는 것이다.

그러면 리팩터링 대상 코드에 어떤 코드들이 의존하는지 쉽게 찾아내서 지금 상황에 맞도록 고칠 수 있다.

-

깨진 창문을 그대로 놓아두지 말라.

pain management, [실용주의 프로그래머] 리팩터링 (#33), 고통 관리, 깨진 창문, 리펙터링 종양, 리펙토링, 일정의 압박, 일찍 리펙터링하고 자주 리펙터링하라, 테스트, 테스트 집합