안녕하세요. 지난 글에 이어 지적 덕후생활 공동체(지덕체)개발기를 연재하고 있는 ryukim입니다.
저번 글에서는 스켈레톤을 제작하기까지의 과정을 써봤는데요.
이번에는 첫번째 리팩토링 과정과 그 피드백에 대해 써보겠습니다.

그래서 이걸 왜 하는거지…?

이렇게 하는게 맞을까?

처음 리팩토링을 시작하고 얼마 안가 들었던 생각은 ‘이걸 도대체 왜 하지’였습니다.
아무리 생각해봐도 원래 있던 코드를 라이브러리로 옮기는 것 말고는 기능적으로 달라지는 것이 없어보였기 때문입니다.
멘토님이 설명할 때 그려주셨던 그림도 그려가며 나름대로 이해해보려고 했지만 딱히 답을 얻을 수 없었습니다.

사실은 정답이었던 것

결국 답답했던 저는 호준 멘토님께 다시 찾아갔습니다. 아무리 생각해도 여기있던 코드를 저기로 옮기는 것 말고는 달라지는 것이 없는 것 같은데 과연 이게 정답이 맞는지 질문했죠.
멘토님의 대답은 ‘YES’였습니다. 리팩토링이란 초기 개발 이후 유지 보수를 위해 가독성을 높이는 작업이었던 것입니다.
이렇게 제가 시도하고 있던 방법이 맞다는 확신을 얻을 수 있었습니다.

확신을 얻었으니 일단 내 생각대로

기능별로 나눠보자

가독성을 높이는 것이 리팩토링의 핵심이라는 것을 알아냈지만 라이브러리를 어떤 식으로 나눠야할지는 여전히 의문이었습니다.
나름대로 가장 가독성이 좋다고 생각해 내린 결론은 기능별로(지금 생각해보면 CRUD로)나누는 것이었습니다.
그렇게 저는 CRUD로 각각 라이브러리를 나눠 기존에 controller 부분에 있던 코드들을 라이브러리로 옮기는 작업을 시작했습니다.

일단 완성은 했다

단순 노동이 반복돼 조금 힘들기는 했지만 새로 어떤 기능을 구현하는 것보다는 훨씬 쉽고 빠르게 작업이 끝났습니다.
하지만 여전히 ‘이게 맞을까?’라는 의문이 마음 한 편에 자리잡고 있었고, 그러나 더 이상 붙잡고 있는다고 달라지는 것은 없다고 생각해 피드백을 받으러 멘토님을 찾아갔습니다.

여전히 높은 결합도

첫 번째 리팩토링을 마친 코드(saveLibrary.js) – 겹치는 코드도 많고 여전히 결합도가 너무 높습니다.

칭찬과 동시에 얻은 반려

그 동안 리팩토링을 하며 어떤 고민을 했고, 기능별로 라이브러리를 나눈 이유는 무엇인지 설명하며 다시 한 번 코드리뷰를 받았습니다.
물론 리팩토링에 정답이 있는 것은 아니지만 저의 방식대로 기능별로 라이브러리를 나눴을 때 하나의 새로운 모델이 추가되거나, 기능이 추가될 때 모든 라이브러리 파일을 하나하나 열어 수정하고 고칠 부분이 없는지 확인해야하는 문제점이 있다는 피드백을 받았습니다.
또한 결합도 역시 여전히 높으니, 이런 부분들을 신경써서 새로운 브랜치를 파서 다시 리팩토링을 해보고 지금의 코드와 비교해보라는 과제를 내주셨습니다. 특히, 클래스를 이용해 갈아끼울 수 있는 코드를 만들어 보라고 조언해 주셨는데 이 표현이 저의 다음 리팩토링에 큰 도움이 되었습니다. (저는 이것을 마법 지팡이에 원소석을 갈아끼우는 것으로 이해했습니다.) 피드백이 끝난 후 멘토님께서 나름의 결론을 내려오고, 내준 과제를 꾸준히 해오는 것에 대해서 칭찬을 해주셨고 이것이 다시 한 번 달려갈 수 있는 큰 힘이 되었습니다.

공부를 더 해야겠다

피드백이 끝난 후 가장 크게 느꼈던 것은 클래스, 결합도, 객체지향 등 아직 모르는 개념이 너무 많다는 것이었습니다.
하지만 이 곳이 어디입니까? 42의 가장 큰 자산인 동료들에게 질문하고 제가 이해한 개념들이 맞는지에 대해 이야기를 나누며 객체 지향에 대해 조금씩 이해할 수 있었습니다.

다음 글에서는 두 번째 리팩토링 과정과 본격적인 기능 확장에 대해 글을 써보려고 합니다. 긴 글 읽어주셔서 감사합니다!