뉴스피드 프로젝트 KPT 회고

스프링 부트를 활용한 뉴스피드 프로젝트를 하면서 느낀 점 정리

 

KEEP : 현재 만족하고 있는 부분

 

dev 브랜치에 병합할 때 Pull Request를 이용해서 한 번 검토를 하고 합치기 때문에 코드의 품질을 더 높일 수 있고, 본인이 짠 코드가 아닌 다른 코드도 볼 수 있어서 일관된 코드 작성하는데 도움이 되는 것 같습니다.

 

지금까지 개인 과제 하거나 개인 개발할 때는 일단 기능을 다 완성시켜두고 API 명세서를 작성했는데, 이번에 API 명세서를 작성하고 개발을 하다보니 가이드라인이 되는 것 같아서 더 편하게 개발할 수 있었던 부분이 좋았습니다.

 

예외처리를 할 때 try{} catch() {} 를 사용해야만 하는 줄 알고있었는데, @RestControllerAdvice를 활용해서 예외처리를 한 곳에 모아서 관리하고, 서비스 로직에서 더 가독성 있는 코드를 짤 수 있을 거 같아서 앞으로는 그런 식으로 처리해야겠다고 생각했습니다.

 

정규화, 레디스 기술스택 사용 등 혼자 개발할 때는 생각하지 못했던 부분들을 다른 팀원이 짠 코드를 보면서 배울 수 있는 부분이 마음에 들어서 앞으로도 종종 다른 사람이 쓴 코드를 분석해보면서 더 실력을 늘릴 수 없을지 고민해봐야겠습니다.

 

다른 도메인에서도 사용할만한 유틸리티 메서드들을 따로 유틸리티 메서드로 빼주셨어서 개발할 때 비슷한 로직을 개발하지 않아도 돼서 편했습니다. 다음 프로젝트를 할 때 다른 팀원분들이 쓸만한 기능이 없을지 생각해보고 유틸리티 클래스를 따로 만들어서 더 프로젝트 개발 효율을 높여야겠다고 느꼈습니다.

 

Problem : 불편하게 느끼는 부분

 

API 명세서를 처음에 작성할 때 응답 형식을 일관된 방식으로 정할 수 있다는 사실을 모르고 시작했기 때문에, 어떤 API는 String을 반환하고, 어떤 API는 void로 어떠한 반환도 하지 않았던 것이 클라이언트가 해당 API를 사용하는데 진입장벽을 높이는 부분이라고 생각합니다.

 

기능이 완전하게 동작하게 구현이 되기 이전에도 서로 연관된 기능을 개발할 때 소통을 하면서 어떤 식으로 변수명을 쓸 건지, 어떤 타입으로 메서드가 반환되는지, 공통되는 로직이 없는지 확인하면서 한다면 더 빠르고 효율적으로 개발을 할 수 있었을 거 같은데, 기능이 완전하게 돌아가는 걸 확인하고 나서야 서로의 코드를 확인했기 때문에 시간적으로 더 걸렸다고 생각합니다.

 

예외를 사용할 때 NullPointerException, IllegalArgumentException으로 모든 것을 해결하려 했던 경향이 있어서, 클라이언트가 API를 사용하다가 오류가 났을 때 정확히 어떤 것이 문제인지 확인하기 어려울 것이라는 피드백을 받았습니다. 더 명확하게 예외를 던져서, 정확이 어떤 문제인지 파악하기 좋게 예외처리를 해야겠다고 생각합니다.

 

시간관리를 잘 하지 못해서 이번 프로젝트는 코드 완성도 뿐만 아니라 발표 자료 준비, 시연 영상 촬영을 거의 신경쓰지 못했습니다. 팀원분들과 개발 진행상황을 더 자주 보고해서, 시간에 쫓기지 않도록 항상 신경써야겠다고 느꼈습니다.

 

 

 

Try : Problem에 대한 해결책, 당장 실행 가능한 것

 

API 응답에 대해 더 일관적인 포맷으로 수정해볼 수 있을 것 같습니다.

 

기능 전반에 대한 응답들이 정보를 너무 적게 담고 있어서(로그인을 성공했을 경우 “로그인 완료” 메시지만 띄우는 등) 더 상세한 응답을 반환하게 수정할 수 있을 것 같습니다.