38일차
발표
팀장님께서 발표를 해주셨다.
성공적, 발표시간도 딱맞추고 깔끔하게 잘 얘기해주셨다.
피드백
- readme에 프로젝트에 대한 개요, 설계, 설계문 등 간판의 역할을 할 수 있는 내용이 정리되면 좋습니다.
- git 사용간에 커밋 컨벤션이 통일되면 더욱 좋을것 같습니다.
- users 뒤에는 email이 아닌 users/{userId} 와 같이 식별자가 오도록하며, id가 아닌 email이 파라미터로 필요한 경우 request param으로 처리하면 됩니다.
- 단건 조회, 수정, 조회간에는 requestparam이 아닌 pathvariable로 받고, 이때는 Long이 아닌 long의 primitive type으로 받아서 NPE에 안전하도록 처리하면 좋습니다.
- 각각의 서비스와 연결된 repository 외에는 service를 Di 받는게 좋습니다. 예를들어 AlarmService는 AlarmRepository만 갖고, 나머지는 도메인은 Service를 DI 받습니다.
- 바로 위 코멘트와 마찬가지로 알림 서비스에서는 User entity를 직접 조회하는 메소드가 있으면 도메인의 경계를 넘는 메소드가 됩니다. 이는 UserService에 구현된 메소드를 호출하는 형태로 사용해야 합니다.
- 댓글 수정, 삭제간에 중복되는 검증 로직은 validation 을 위한 메소드 또는 서비스를 만들어서 관리하면 더욱 가독성 있고 유지보수 좋은 코드가 될것 같습니다.
- enum은 entity 패키지에서 관리되는 영역이 아닙니다. 3레이어드 아키텍쳐 설계간에 도메인이 많아지면 도메인별로 3레이어드 아키텍처를 구성하고, enums 패키지를 해당 도메인에 만들어주는 형태로 개발하면 좋습니다.
- 각자 자신의 properties 파일을 관리해서 환경을 분리한점은 잘했으나, 전부 공통적으로 db 패스워드가 포함되고 있습니다. 이는 환경변수로 분리할 수 있도록 해주세요.
짧은 시간이지만 기획부터 설계까지 프로젝트를 완성하느라 고생 많았습니다!
회고
- 충분히 고려할 수 있는 부분인데 놓쳐서 자꾸 오류가 난다.
-> 기능구현을 하면 바로바로 test를 해봐야 겠다. - 내가 짜놓고 계속 이게 좋아요를 누른 유저 고유식별자인지.. 좋아요를 받은 유저의 고유식별자인지 헷갈려하며 작업 속도가 더뎠다.
-> 칼럼명을 받는유저/받은유저 로 확실하게 시각적으로 구분 할 수 있게 정해둬야겠다. - repository들을 연결한게 너무 아쉽다
-> 다음부턴 Service로 연결해서 해봐야할것같다.
