[레벨 3 회고] 하루스터디 6주차 회고
6주차는 리팩토링에 집중했던 한 주였습니다 🥲 마찬가지로 회고해보고자 합니다!
슈퍼타입 - 서브타입 제거
한 주가 시작되자마자 가장 먼저 했던 일은 테이블 상속구조를 제거하는 일이었습니다. ERD 설계를 할 때, 확장성을 고려해 슈퍼타입 - 서브타입 관계를 자주 사용했으나, 이에 따른 문제가 많이 발생했기 때문입니다.
우선 테이블 구조를 한 눈에 파악하기가 어려웠습니다. 어떤 정보가 어디에 들어가는지 알기 위해서는 자주 ERD를 확인해야 했던 것 같습니다. 또한, 코드 레벨에서도 상속 구조를 사용하니 캡슐화, 다형성 등 이것저것 신경쓸게 많았습니다.
확장에 유연하게 대응하기 위해서 추상화를 했지만, 추상화를 관리하는 비용이 생각보다 컸던 것 같습니다. 따라서 테이블 상속구조, 코드 상속구조를 모두 제거하고 새로운 ERD 및 코드 구조로 변경했습니다.
해당 경험을 통해 '추상화는 필요한 순간에' 라는 생각이 많이 들었던 것 같습니다. 추상화를 해두었음에도 확장이 일어나지 않을 수도 있고 이런 경우 추상화 자체가 족쇄가 되기 때문입니다.
API 재설계
하루스터디는 이번주에 API 재설계를 진행했습니다. 재설계를 진행한 이유는 다음과 같습니다.
- 리소스가 올바른 계층 구조로 이루어져 있지 않다.
- 뷰에 맞춘 API가 여럿 존재한다.
이렇게 API가 모호하다보니 백엔드 설계도 모호해졌습니다. 서비스까지 뷰를 의존하는 상황이 왔고(뷰의 변경이 서비스까지 도달한다는 의미입니다) 코드 자체가 상당히 이해하기 어려워졌습니다. 또한, 어떤 기능이 어느 서비스에 있는지 한번에 찾기도 어려웠습니다.
따라서 새로운 API는 계층 구조를 명확하게 준수하고, 리소스 단위로 나누어지도록 재설계했습니다. 현재 백엔드의 경우에는 API 설계 변경에 의한 파급효과가 그렇게 크지는 않아서 금방 작업을 마칠 수 있었지만, 프론트엔드의 경우 파급효과가 커서 아직까지 작업이 끝나지 않은 상태입니다.
이번 경험을 통해 느낀 점은, API가 백엔드 설계에 있어 생각보다 더 많이 중요하다는 것입니다. 백엔드 관점에서 보았을 때 API는 '기능 목록'과 거의 같다고 봐도 되고, API에 따라 비즈니스 로직의 흐름도 정해집니다. 따라서 뷰에 맞춘 API, 올바른 계층으로 구성되지 않은 API로는 좋은 백엔드 코드 구조를 유지할 수 없다는 것을 느꼈습니다.
리팩토링은 언제 해야할까?
협업을 하다보면 리팩토링 시기를 잡기가 애매해지는 것 같습니다. 코드 품질보다는 기능 개발, 버그 수정이 우선인 경우가 많기 때문입니다. 다른 개발자들은 협업을 하면서 언제 리팩토링을 하는지 궁금해져 찾아보았는데, 마틴 파울러의 <리팩토링> 에서는 다음과 같은 상황에서 리팩토링을 하라고 권장하고 있었습니다.
- 3번 중복되면 리팩토링을 하라
- 기능을 추가할 때 리팩토링을 하라
- 버그를 수정할 때 리팩토링을 하라
- 코드검토(code review)를 할 때 리팩토링을 하라
디자인-스태미너 가설 에 따르면, 리팩토링이 좋은 설계를 유도하고 결론적으로는 개발 생산성을 증대시킨다고 합니다. 앞으로는 '리팩토링 데이' 와 같은 방법은 지양하고 개발을 하면서 자연스럽게 리팩토링을 할 수 있도록 연습해야겠습니다.
기타
- OAuth2에 대해 팀원들과 함께 학습했습니다.