8월에 진행했던 프로젝트의 소스 코드를 읽고
클린 코드와 리팩토링을 공부하고
사실 아직이다. 앞서 저번 시간엔 Clean Code에 대해 알아 보던 중,
리팩토링이라는 단어가 포착됐다! 오늘은 현업에서 자주 언급되고 있는 이 단어에 대해 알아보겠다.
C++ 과제 코드 리팩토링하고 왔어요
어제 클린코드에 대해 알아보고, 오늘 리팩토링을 조금 알아보고 글을 쓰다 말고 과제를 재제출하러 다녀왔다. 프로그램은 정상적으로 돌아가지만 더티 코드들의 향연이었다. 코드 수정한 내역들 중 기억에 남는 포인트들을 적어보겠다.
- 잘못됐거나, 의미가 불분명한 함수명들을 수정했다.
- 함수명의 위계를 동일하게 수정했다.
- 함수명 수정과 동시에, 함수가 두 가지 이상의 작업을 수행한다면 함수를 분리했다.
- bool 타입 변수를 받아 if-else문으로 처리한 함수를 분리했다.
- 함수 파악에 있어 핵심적인 코드를 중점적으로 남기도록 재작성했다.
- 각 함수 내의 추상화 수준을 동일하게 수정했다.
- 전체적으로 함수형 프로그래밍 방식으로 리팩토링한 것 같다.
필자가 작성했던 코드가 얼마나 가독성이 떨어졌었는지 알 수 있는 대목이다. 또한, (1) 필자는 이러한 과정을 리팩토링이라고 표현했고 (2) 위의 각 과정은 앞서 공부했던 Clean Code의 기준이다. 음, 이정도면 리팩토링이 의미하는 바가 무엇인지 유추할 수 있겠다.
Refactoring
"코드 재구성"그냥 재구성하는 것이 아니라!
가독성이 떨어지던 코드를 이해하고 수정하기 쉽도록 "클린 코드로 재구성"하는 것이다
따라서 리팩토링을 하기 위해선 Clean Code의 기준들에 대해서 공부해두면 되겠다.
쉽지 않은가! 서로 다른 것인줄 알았는데, 거의 같은 맥락에 존재하는 개념들이었다.
그럼 클린 코드와 리팩토링에 대해 감이 잡혔으니 리팩토링에 대한 여담 정도을 얘기하고 글을 마무리하겠다.
리팩토링, 무조건 해야 해?
상당히 궁금할 만한 주제다. 회사에 들어가서 기존의 코드를 파악하니 클린 코드가 아니라면? 무조건 리팩토링을 실행해야 하는가? 개인 프로젝트이며, 시간적 여유가 어느정도 있다면 시도해보는 것이 좋겠으나..
정답은 무조건은 NO! 다.
리팩토링을 하면
- 프로그램의 성능은 좋아질 수도, 나빠질 수도 있다.
- 기본적으로 비용과 시간이 든다.
어느 회사건 간, 고객들에게 안정적인 서비스를 제공하는 것은 최우선시 되는 포인트일 것이다. 따라서
리팩토링을 해야하는 상황
리팩토링의 효용이 해당 리팩토링의 비용, 시간, 리스크보다 클 때
위의 상황에 리팩토링을 진행하는 것이 바람직할 것이며
기본적으로 프로젝트의 코드는 팀의 코드는 팀원들 모두가 공유하고 있는 코드다.
"팀원의 코드"이니 섣불리 리팩토링을 시도하는 것보다 팀원들과 리팩토링에 대한 충분한 협의도 필요하겠다.또한 리팩토링은 기존의 코드를 수정하여 새로운 코드로 만드는 것인데,
기능 추가의 반복으로, 리팩토링 코드가 순식간에 다시 더티 코드화될 갈 가능성 또한 높다.
아니 그럼 대체 언제 하라는 거야!
팀원들과 충분한 협의를 통해 리팩토링을 진행해나가야 한다는 뜻이다!
각자의 코드 스타일도 모두 다르니, 조율 및 합의점을 찾는 것도 중요할 것이며
이러한 과정들을 통해 프로덕트를 리팩토링해나가 보자
처음 코드를 쓰는 첫 순간에 추후 리팩토링이 발생하지 않도록 코드를 써보는 것도 좋겠다.
쉽진 않겠지만..리팩토링을 줄이려면
새로운 기능을 구현하는 첫 순간에 큰 그림을 그려보는 자세가 필요하다.
나중에 해당 기능에서 "공통적으로 발생할만한 코드가 있는지"에 대한 고민을 하며 기능 추가를 진행하면 좋겠다.
