241218 프로젝트 마무리 회고 TIL

2차 프로젝트가 마무리되었다!

https://github.com/Sparta-Phoenix/logistics-platform

GitHub - Sparta-Phoenix/logistics-platform

 

프로젝트 마무리 기념으로 개인적으로 아쉬웠던 점들을 간단히 기록해보고자 한다.

 

1) 캐싱을 더 잘 활용할 수 있었는데 아쉬웠다.

시간관계상 필수 요구사항인 허브 단건 조회에만 캐싱을 적용했는데, 생각해보니 업체 관리자들도 정보를 빈번하게 조회할 것 같았고 목록 조회도 자주 일어날 것 같아서 업체 단건 조회와 페이징에도 캐싱을 적용하면 좋았을 것 같다.

 

2) 내가 맡은 부분에서, 다른 팀원처럼 비동기처리로 성능 개선 처리를 하지 못한게 아쉬웠다.

MSA에서 FeignClient 호출을 할 때, 생각보다 시간이 오래 걸렸다. 2.6초쯤? 아마 생성 로직에 호출까지 있어서 더 오래 걸렸던 것 같다.

그래서 개발하면서 조금 불편함을 느꼈지만, 기능 구현에 급급해 성능을 개선해야겠다는 생각까지 이어지지 못했다..

그런데 개발 마지막 날쯤 다른 팀원분이 비동기처리를 구현해 성능을 0.6초로 끌어올리셨다.

불편함만 인지하고 넘어간 나와 달리 비동기처리까지 구현해 문제를 해결한 모습이 멋있었고, 본받고 싶다고 생각했다.

나도 다음부턴 비동기처리를 잘 활용해보고, 문제 해결 능력을 높이자고 다짐했다. 꼭꼭!

 

3) 요구사항에 대한 꼼꼼한 분석과 사전 협의가 부족했다.

내가 맡은 건 허브 배송 예상 경로(거리, 시간)를 구해 허브 배송 예상 경로 테이블에 저장하는 거였고, 이 배송 예상 경로 데이터를 배송 개발을 맡으신 분이 가져다 써야 했다.

이때 내가 개발한 response와 팀원 분이 원하시는 response가 서로 달라 개발 완료 후에도 코드를 여러 번 수정하는 일이 있었다.

요구사항을 함께 더 꼼꼼히 분석하고, 사전에 반환값에 대한 충분한 협의를 미리 진행했다면 더 원활하게 진행됐을 것 같다.

 

그 외에도 개인적으로 맡은 로직의 개발을 들어가기전에 전체적인 구조와 흐름을 먼저 그려보고, 필요한 예외 처리나 세부적인 기능을 생각해본 후 개발을 시작하면 더 깔끔한 개발이 가능해질 것 같다.

다음 프로젝트 땐 꼭 더 꼼꼼하게 요구사항을 분석하고 더 꼼꼼하게 개발하도록 하자! 

 

최종 프로젝트 목표

- Zipkin이나 모니터링 시스템을 적극적으로 활용하기, 개발만 하는 것이 아니라 실제 성능에 대한 고민도 함께하기.