레시피 저장소 토이 프로젝트의 리팩토링을 시작하기에 앞서 결심 이유들을 정리해 보고자 합니다.
🍅 레시피 저장소 🥕 토이 프로젝트 배경
레시피 저장소는 취업 전 들었던 부트캠프에서 알게 된 사람들과 팀을 구성하여 취업 포트폴리오를 위해 진행한 토이 프로젝트였습니다.
UX/UI 디자이너 1명, 안드로이드 개발자 2명, 백엔드 개발자 2명으로 구성된 팀 프로젝트에서 간단한 기획을 바탕으로 어플리케이션 출시까지 진행했습니다.
그러고 사실 각자 취업 후에는 따로 더 관리를 하지 않고 오류가 생기거나 하면 들여다보는 정도로 방치에 가깝게 뒀었습니다.. ㅎㅎ 😅
그런데 어쩌다보니 이용자 수가 급격히 많아지면서 트래픽으로 인해 오류가 발생하면서 캐캐묵은 코드를 갑작스레 들여다볼 일이 생기게 됐습니다.
리팩토링을 결심하게 된 배경 🤔
이 토이 프로젝트를 시작할 쯤에는 백엔드로 진로를 정한지 얼마되지 않았습니다.
거기다 스프링부트는 거의 독학으로 부트캠프 프로젝트를 쳐내기 위해서 대충 어떻게 돌아가는지 정도의 지식만 익힌 상태였습니다.
그러다보니 스프링부트도 부트캠프에서 제공된 템플릿을 사용했고 기본 설정에 대한 이해가 부족한 상황이었습니다. (물론 지금은 이해를 잘 하고 있냐하면 그것도 아니지만.. ㅎㅎ)
어쨌든 이제와서 코드를 다시 들여다보니 머리가 그래도 좀 컸는지 작성했던 코드들이 진짜 개판이라고 느껴졌습니다...
나중에 포트폴리오로도 써야되는데 이래서는 안되겠다는 생각이 들더라구요. (심지어 공개 레포지토리라 ㅎㅎ..)
다시 오랜만에 들여다 볼 계기가 생겨서 보니까 프로젝트를 같이 진행했던 팀원분들도 비슷한 감상이라 아예 전체 개편을 하기로 이야기가 됐습니다.
이 김에 새로운 기능을 넣자는 의견도 있어서 해당 부분도 진행하면서 기존 코드들을 리팩토링을 하기로 결심했습니다.
리팩토링 시 적용하고 싶은 내용 ✨
1. 도메인 주도 설계 적용, DTO 분리하여 적용
기존에는 주어진 템플릿으로 작업했었는데 폴더 구조를 DB 엔티티 기준으로 분리되어 있었습니다.
그리고 엔티티 연결한 도메인은 JPA와 비즈니스 로직 처리는 서비스 내에서 하고 도메인에서는 따로 처리하지 않고 있었습니다.
그래서 이번 작업을 할 때는 도메인 주도 설계를 적용해 보고 싶습니다. 도메인에서 비즈니스 로직을 주로 처리할 수 있게 하고 폴더 구분도 도메인에 맞춰서 적용해 보고 싶습니다.
그리고 요청값과 응답값을 API별로 각각 클래스를 나누어 놓았는데, 이너 클래스로 공통 항목을 관리하고 싶습니다.
2. swagger 를 통한 문서화
기존에는 백엔드 API 명세서를 부트 캠프 때 받은 템플릿으로 받은 엑셀을 사용하여 작성했습니다.
엑셀은 매번 수정 시에 수정한다고 하는데도 빼먹을 때가 있어서 더 나은 방법이 없을까 생각하다가 swagger로 문서화를 해봐야 겠다고 생각했습니다.
사실 원래 swagger 는 사용하지 않으려고 했습니다.
예전에 swagger에 대해서 알아볼 때, swagger는 실제 실행 코드 위에 어노테이션 형식으로 적었던 걸로 기억하고 있었습니다. 그래서 실행하는 코드에 영향이 생기고 어노테이션이 길게 작성된 것이 보기에 별로 좋지 않다고 느꼈습니다.
그래서 다른 방법이 없을까 찾아보다가 Spring REST docs를 사용해 보려고 했습니다. Spring REST docs는 테스트코드 내부에서 설정할 수 있어서 실행 코드와 분리되는 점이 큰 장점으로 느껴졌기 때문입니다. swagger처럼 실행할 수 있는 ui가 주어지는 건 아니지만 POSTMAN도 있는데 굳이 그 기능이 크게 필요하다고 느끼지 않았습니다.
그런데 다른 개발자분께서 swagger가 현업에서 많이 쓰니까 사용해보는 걸 더 추천한다고 하셨습니다. 그 분은 클라이언트 개발자셨는데 swagger codegen을 요새 많이 사용한다고 하시며 추천했습니다. 찾아보니 swagger로 변경한 dto를 자동 생성해줘서 작업이 좀 더 줄여줄 수 있어서 많이들 사용하는 것 같았습니다.
그래서 현업에서 많이 사용한다고도 하고 실제 협업에는 더 나을 것 같은 생각이 들어서 swagger 를 한 번 적용해볼까 합니다.
3. 테스트 코드 작성
그 당시엔 아무래도 테스트코드에 대한 중요성도 몰랐고 테스트코드를 작성해야 한다는 생각도 하지 못했습니다.
그래서 이번엔 테스트코드를 작성하면서 리팩토링을 진행하고 싶습니다.
TDD를 해보고 싶지만 시간적으로 될 지 모르겠어서 적어도 리팩토링을 한 후 테스트코드 작성하면서 커버리지를 높이는 걸 목표로 하고 싶습니다.
4. 응답서비스, 예외처리 리팩토링
기존에 제공된 템플릿을 이용하다보니 불필요하게 중복되는 부분들 제거하고 싶습니다.
예외핸들러를 활용해서 예외처리를 핸들러에서 처리할 수 있게끔하고 컨트롤러 내에 반복되는 try catch 문은 제거하고 싶습니다.
그리고 기존에는 그냥 에러코드로만 처리했었는데 사용자 예외는 예외 클래스를 만들어서 관리하고 싶습니다.
기존에는 API별로 모든 예외를 만들었는데 공통으로 처리가능한 예외는 통합하고 싶습니다.
5. stream 등을 활용한 코드 단순화
당시에는 stream에 대한 지식이 없어서 사용할 생각을 못했습니다.
stream을 활용해서 조금 더 깔끔하고 단순하고 성능이 좋은 코드를 사용하고 싶습니다.
6. 코드 리뷰, git flow 적용
그 때 당시에는 백엔드 개발자 2명이 협업을 하는데도 따로 branch를 나눠서 작업하지 않았던 것 같습니다.
둘 다 git에 익숙하지 않았던 탓도 컸던 것 같습니다..ㅎㅎ
이번부터는 git 작업 시에 branch를 따로 생성해서 관리하고 PR을 요청해서 코드 리뷰를 통해 서로 얘기 나눌 수도 있게끔 작업을 진행하고 싶습니다.
7. 성능 테스트
그 당시엔 그냥 기능 동작하는 데 의의를 뒀기 때문에 성능에 대한 고민도 없었습니다.
그러다가 이용자 수가 급격하게 늘면서 처음에 트래픽이 몰렸을 때 성능 때문에 고생을 했습니다.
이번엔 Jmeter 등 성능 테스트를 하는 프로그램 활용해서 성능을 배포 전에 확인을 하고 예상을 할 수 있게끔 하고 싶습니다.
결론
앞으로 시리즈로 어떤 생각을 가지고 기존 코드들을 어떤식으로 고쳤는지에 대해서 기록하려고 합니다.
그리고 이렇게 글로 적어서 더이상 미루지 않고 코드 리팩토링을 꾸준히 할 동기도 부여하고 싶습니다.
나자신 화이팅! 😊
