한 번에 완벽한 코드를 완성하는 것은 거의 불가능에 가깝다. 글을 쓸 때 초안을 먼저 작성하고, 수정을 거쳐 완성하듯 코드도 수정을 통해 점진적으로 개선해야한다. 이러한 점진적인 개선이 바로 리팩토링이다.
리팩토링(refactoring)이란
리팩터링(refactoring)은 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.
프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. 최악의 경우 개선 전과 똑같이 프로그램을 돌리기 아주 어렵기 때문이다. 따라서 테스트를 기반으로 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아간다는 것을 늘 확인하며 점진적으로 개선해나가야 한다.
즉, 리팩토링을 잘하기 위해서는 테스트 주도 개발(TDD)이 중요하다. TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다. 다시 말해 TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 덕분에 안전하게 코드를 수정해나가며 더 좋은 방향으로 나아갈 수 있다.
⊕ TDD에 대한 더 자세한 사항은 클린코드 JS - 11. 테스트 만들기
를 참고하자.
다음으로, 리펙토링의 주요 핵심 중 하나는 '자주'이다. 코드의 양이 적으면 적을 수록 리펙토링하기 좋다. 모든 로직을 완성하고 난 뒤에 대대적으로 리팩토링을 하는 것이 아니라, 함수 하나 로직 하나를 완성할 때마다 조금씩 더 나은 방향으로 리펙토링하는 습관을 들여야 한다. 코드를 몇 줄 추가할 때마다 잠시 멈추고, 스스로 질문해보자. "새로 추가한 코드가 기존 기능을 깨트리지는 않는가? 코드 품질을 낮추고 있지는 않은가?"
리펙토링에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다. 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 함수와 클래스의 크기를 줄이고, 더 나은 이름으르 선택하는 등 다양한 기법을 동원해보자. 단, 모든 단계에서 여전히 이전과 동일하게 동작하는지 확인해야 한다.
아래는 도서 Clean Code(클린 코드)
에 나오는 '착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙'이다. 소프트웨어 설계 규칙이라고 나오지만 리팩토링 과정에 다음 네 가지 규칙을 따르고 반복하면 좋을 것 같아 함께 소개하고자 한다.
켄트 벡이 제안하는 깔끔하고 단순한 소프트웨어 설계 규칙
1. 모든 테스트를 실행한다.
2. 중복을 없앤다.
3. 프로그래머의 의도를 표현한다.
4. 클래스와 매서드 수를 최소로 줄인다.
(위 목록은 중요도 순이다.)
1. 모든 테스트를 실행한다.
무엇보다 먼저, 시스템이 의도한 대로 돌아가는지 검증하기 위해서 테스트를 만들고 실행하는 것은 몹시 중요하다. "테스트 케이스를 만들고 계속 돌려라" 라는 단순한 규칙을 지키면 설계 품질이 저절로 높아진다.
2. 중복을 없앤다.
중복은 클린코드의 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다. 똑같은 코드 혹은 비슷한 코드는 함수로 만들거나 추상화하여 재사용하는 것이 좋다.
3. 프로그래머의 의도를 표현한다.
코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수가 용이하다. 의도를 잘 표현하기 위해서는 좋은 이름을 선택하고, 함수와 클래스 크기를 가능한 줄이고, 팀 내에서 합의한 규칙 혹은 표준 명칭을 사용하자.
4. 클래스와 매서드 수를 최소로 줄인다.
함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하기 위해 함수와 클래스 수를 가능한 줄이는 것이 좋다. 그러나 이 규칙은 우선순위가 가장 낮다. 테스트 케이스를 만들고, 중복을 제거하고, 의도를 표현하는 작업이 더 중요하다는 뜻이다.
마지막으로 클린 코드에서 가장 중요한 것은 코드를 읽을 동료 혹은 미래의 나를 위한다는 마음이라고 생각한다. 나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만드려고 노력하자!
사실, 나중에 코드를 읽을 사람은 바로 미래의 나 자신일 가능성이 높다. 아무렇게나 짠 코드, 리팩토링하지 않고 방치된 코드들은 결국 다시 나에게 재앙으로 돌아온다. 조금만 더 주의를 기울이고 고민하면 더 좋은 코드, 클린 코드를 실천할 수 있을 것이다.
Clean Code(클린 코드)
/ 로버트 C. 마틴 / 2013.12.24.