리팩토링 is 리모델링

리팩토링은 다시 구조화 하는 것이다. 건물로 비유하면 리모델링 정도라고 보면 될거 같다.

보통 개발자들은 남들이 짜놓은 코드를 보면 코드가 엉망이라고 다시 짜야 한다고 한다. 대개는 다시 처음부터 짜고 그 복잡한 기능들을 구현하다보면 다시 스파게티 코드가 된다. (스파게티 코드라는 말을 쓴다. 엉망진창이라는 뜻이다.) 그러면 다른 누군가는 말을 한다. 다시 처음부터 짜야 한다고

역사는 반복된다고 했던가
그러면 건축물로 치면 처음부터 다시 짠다는 의미는 무너뜨린다는 것이다. 그리고 다시 짜는 것이다. 과연 효율적일까? 왜 그렇게 복잡한 코드가 되었을까 생각해보면 그럴만한 사연이 있기도 하다.

그러면 무엇이 좋을까? 개발을 처음할 때는 몰랐던 사실을 기능을 구현하고 나니 알았다면 알고 났을 때 어떤 구조가 더 좋은가를 생각해볼 수는 있다. 그러면 처음부터 개발하는 것이 아니라 기존 것을 좀 정비하면 되는 것들도 있을 것이다. 이것이 리팩토링이다.

기능을 바꾸지 않고, 코드의 구조를 바꾸는 것이다. 단순하게 주석 달고, 띄어쓰기 하는 수준보다는 클래스의 구조를 바꾼다든지 함수를 최적화 한다든지의 작업을 한다.

리팩토링은 부분적으로 하나씩만 해야 한다. 리팩토링의 위험성이 도사린다. 달리는 기차의 바퀴를 바꾸는 것일 수도 있다. 그러려면 바꿀 때 문제가 있을 수 있기때문에 수정 후 문제가 발생된다면 수정한 곳에서 문제일 가능성이 매우 높다. 그래서 동시에 2가지 이상하면 안된다. 한군데만 수정하고 기능테스트, 통합 테스트, 재귀 테스트등 전체 기능에 이상이 없는지를 테스트해봐야 한다.

리팩토링을 하면서 전체를 고치려고 하면 안되고, 안정성을 고려하고, 영향도를 생각해야한다. 리팩토링은 코드를 최적화 하고, 전체 기능 성능을 좋게 할 수도 있다. 겨우 겨우 아무런 문제가 없게 만든 코드이니 절대 손대서는 안된다라는 관점보다는 리팩토링을 통해서 개선을 할 수 있다면 개선을 해보는 것도 좋다. 막연하게 두려워할 문제는 아니다. 기획, 설계, 개발도 페어 프로그래밍이 좋지만, 리팩토링은 페어 프로그램을 하는 것이 매우 좋다. 개발자간에 의견을 나누면서 개선 포인트를 찾고, 우려 사항이라든가 문제 될 소지를 생각해보는 것이다. 페어 프로그래밍에 대해서도 언급하고자 한다. 

책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22337