리팩터링이랑 기능은 그대로인데 설계를 개선하는 행위다. 리팩터링을 하는 능력도 중요하지만, 언제 리팩터링해야 하는지 신호를 알아차리는 것도 중요하다. 그리고 단계를 작게 나눠서 코드가 깨지지 않도록 유지하면서 리팩터링하는 능력도 중요하다.
또한 리팩터링은 시간을 따로 두고 하는 활동이 아니라 개발과 동시에 해야 한다. 그러려면 항상 코드를 검증해 줄 수 있는 테스트가 있어야 하고, 이러한 것을 쉽게 해주는 것에 테스트 주도 개발이 있다.
프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링하고 나서 원하는 기능을 추가한다.
좋은 코드는 변경하기 쉬운 코드다. 변경하기 어려운 코드를 발견했다면, 리팩터링해야 할 신호로 받아들여 변경하기 쉬운 코드로 리팩터링 후 원하는 기능을 추가해야 한다.
캠핑자들에게는 “도착했을 때보다 깔끔하게 정돈하고 떠난다”라는 규칙이 있다. 프로그래밍도 마찬가지다. 항시 코드베이스를 작업 시작 전보다 건강하게(healthy) 만들어놓고 떠나야 한다.
보이스카우트 원칙 이라고 불리는 이 원칙은 실무에서 가장 실용적인 원칙인 것 같다. 때로는 기능 추가 때문에 리팩터링이 소홀할 수 있지만, 기능을 추가하기 전보다는 더 나은 설계가 있어야 하고, 또다시 코드를 수정해야 할 때 이전보다 더 나은 설계를 만들다 보면 완벽하지는 않더라도 점점 더 나아지게 만든다.
리팩터링을 효과적으로 하는 핵심은, 단계를 잘게 나눠야 더 빠르게 처리할 수 있고, 코드는 절대 깨지지 않으며, 이러한 작은 단계들이 모여서 큰 변화를 일 수 있다는 사실을 깨닫는 것이다.
리팩터링을 하다보면, 수정하고 싶은 것들이 한 번에 눈에 들어온다. 그러면 한 번에 코드를 수정하고 싶은 욕구가 생기는데, 그러다 보면 결국에는 점진적으로 설계를 개선하는 것이 아니라 코드를 다시 짜는 수준이 된다. 그러면 작업 시간이 길어지게 되고 테스트도 내 코드를 검증하는 수단이 아닌, 코드를 변경하는데 방해가 되는 장애물로 여겨지게 된다.
책의 리팩터링 예제나 카탈로그의 예제를 보면 코드가 깨지지 않도록 유지를 하며 리팩터링을 하는데, 이렇게 할 수 있어야 한다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!
