이 챕터는 소프트웨어가 그냥 동작하게 만드는 것과 올바르게 동작하게 만드는 것의 차이에 대해 설명한다. 그리고 코드 구조의 가치와 관련된 내용이기도 하다.
리팩토링
리팩토링이란 마틴 파울러가 그의 저서 "리팩토링"에서 아래와 같이 정의한다.
외부 행위를 바꾸지 않으면서 내부 구조를 개선하는 방법으로, 소프트웨어 시스템을 변경하는 프로세스
소프트웨어 모듈의 기능
실행 중에 동작하는 기능
- 그 모듈의 존재 이유
② 변경 기능
- 대부분의 모듈은 생명주기 동안 변경 과정을 겪음
- 최대한 간단하게 그런 변경이 가능할 수 있게 만드는 것이 개발자의 책임
- 즉 모듈이 자신의 기능대로 잘 동작하더라도 변경하기 어려울 경우 그것은 망가진 것
③ 그것을 읽는 사람과 의사소통하는 기능
- 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 함
- 읽는 사람과 의사소통할 수 없는 모듈은 망가진 것
리팩토링은 이렇게 자신의 기능을 잘 하고 있는 소프트웨어 모듈을 그 기능은 그대로 잘 동작하게 하면서 더 읽기 쉽고 변경하기 쉽게 만드는 것이다. 즉 망가진 부분을 수리하는 과정이다.
리팩토링 Example에서...
책에서는 소수 생성기 프로젝트 코드를 보여주며 리팩토링의 예를 보여준다. 이 글은 책을 읽고 정리하는 글이므로 내 기준에서 예제를 보며 핵심적이라고 느낀 부분을 정리한다.
🔑 Point
① 여러가지 동작을 하는 메서드는 분리한다!
② 변수명, 함수명을 더 의미있는 것, 실제로 그것의 역할, 하고 있는 것을 표현하도록 바꾼다!
③ 필요없는, 중복되는 변수를 없앤다!
④ 리팩토링을 하면서 테스트를 수행하며 잘못된 부분이 없는지, 수시로 테스트가 깨지진 않았는지 확인하다!
⑤ 이중 부정으로 인한 혼란이 생기는 것을 주의하자!
⑥ 조건문이 혼란이 생기지 않는지 그 조건이 잘 이해가 되는지 확인하자!
⑦ 항상 마지막 관문으로 모든 프로그램을 처음부터 끝까지 읽으며 해당 프로그램이 읽을 수 있는 총체로서 제대로 결합이 되어 있는지 확인하자!
결론
리팩토링을 올바르게 진행하면 프로그램은 이해하기도, 변경하기도 훨씬 쉬워진다. 또한 부분들이 서로 분리된 프로그램 구조가 만들어지게 되고, 그것은 프로그램을 훨씬 변경하기 쉬운 유연한 구조로 만들어준다.
리팩토링을 하다보면 리팩토링 후 오히려 성능에 부정적인 영향을 줄까봐 걱정되는 부분이 보이기도 한다. 하지만 대부분의 경우 향상된 가독성과 유연한 구조가 주는 이점이 더 큰 경우가 많다. 물론 너무 성능에 영향을 많이 줄 것 같은 코드가 보일 수도 있다. 책에서는 그 경우에는 성능의 손해는 무시할 수 있다고 가정하고, 그것이 틀렸다는 것이 증명될 때가지 기다려보라고 조언한다.
작성한 모든 모듈과 유지보수하는 모든 모듈에 대해 항상 이런 리팩토링 과정을 적용하자. 처음에는 귀찮고 하기 싫을 수 있지만 리팩토링에 투자하는 시간은 가까운 미래에 본인과, 본인의 팀이 들여야하는 시간에 비하면 극히 적을 것이다.
리팩토링은 청소와 같다. 저녁 식사 후, 청소를 생략한다고 그 저녁 식사를 빨리 끝낼 수 있는 것은 아니다. 청소할 것은 쌓여만 가고 나중에는 손대기 힘들 수도 있다. 리팩토링의 목표는 매일 코드를 청소하는 것이다. 최소한의 노력으로 시스템을 확장하고 수정할 수 있도록 항상 코드의 깔끔함을 유지하자! 우리는 원칙과 패턴에 신경 쓰기 전에, 간결하고 분명한 코드를 만드는 것에 신경을 써야 한다.
