프로젝트 회고 [티러버TLOVER]

프로젝트 회고 [티러버TLOVER]

구분: 앱 런칭 프로젝트

구성: Backend 6명, Android 4명

맡은 역할: Backend-Architect

 

이번 앱런칭 프로젝트는 22-1 명지대학교 팀프로젝트1에서 진행하였다. 이번에는 온전하게 코드의 전반적인 구성과 깊이를 탐구하기 위해 Architect를 지원하였다.

역할이 Architect인 만큼 코드의 전체적인 구성, 패키지 구조, 클래스의 상속과 관련해서 깊은 고민을 했다.

 

1.     Exception 클래스 구성

처음에 Exception은 단순히 메시지로만 구성된 Exception을 터트렸는데 이는 협업에서 큰 오류를 범할 수 있다고 생각했고 실제로 같은 Architect를 맡은 팀원에게 의견을 물어 관련 코드 구성을 찾아보고 가장 나은 방안을 몰색하였다.

 

프로젝트 초기 카톡 내용

불편함을 느끼는 것은 쉽다. 그 불편함을 통해서 Develop하는 것이 어렵다. 엔지니어에게 가장 중요한 덕목은 불편함에서 Develop하는 것이라 생각한다. 나는 불편함을 크게 느끼고 바꾸는 것이 익숙해져야한다.

 

2.     과인력

서버 개발자가 6명으로 인력이 예상보다 많아졌고, 자연스럽게 내가 해야할 일이 줄어들었다. 일이 줄어들어 좋을 수도 있지만, 성장이 그 만큼 덜 되어서 아쉬운 부분이었다.

그렇기에 비효율적이라도 주요기술(ex. CICD 구축)은 다 같이 진행을 하고 주요기술에 대한 경험을 쌓을 수 있었다. 다음에는 인원에 대한 규정을 하고 과인력으로 인한 성장이 더디지 않도록 해야겠다.

 

3.   Refactoring

프로젝트 초기 코드에 대한 명확한 규정이 있지않아 리턴 객체에 대한 것이 개인에 맞추어져 있었다. 그렇기에 누구는 서비스에서 하는 실행하는 로직을 컨트롤러에서 하는 경우도 있었다. 그렇기에 다른 사람이 작성한 코드를 참고하고 개선사항을 찾는 것에 어려움을 겪었다. 그렇기에 전체적인 코드 리팩토링을 통해 리턴값에 대한 global DTO 패키지에서 규정을 하고 각 도메인의 DTO를 감싸서 반환 값을 통해 팀원들은 전체적인 코드의 이해도를 높였다.

 

4.     직교성의 부족

여행 다이어리 어플이었기에 기획과 개발을 동시에 진행하기에 시스템 내부에서 독립성과 결합도를 낮추는 것은 매우 어려운 부분이었다. 모든 서버 개발자가 좀 더 어플에 대한 이해도가 높은 상태에서 진행했더라면 직교성이 상승했을 거라 생각한다. 또한, 패키지에서 분산 개념을 도입해서 필요 이상의 import가 찍히게 되었다. 코드의 구성을 본다면 나누는 것과 합칠 것을 더 깊은 고민을 통해 나은 선택을 해야한다.

 

 

GitHub: https://github.com/TLOVERcp/tlover-server

PlayStore: https://play.google.com/store/apps/details?id=com.cookandroid.teamproject1