경북대 BE_김동현 6주차 과제 (2-3단계) #302
Conversation
There was a problem hiding this comment.
안녕하세요 동현님! 먼저 리뷰가 조금 늦어서 죄송합니다!
이번 미션은 스펙 협의를 팀원들과 하는 부분이 상당히 중요한데요, API 스펙에 대해 협의하면서 어떠한 변경들이 생겼고, 어떠한 부분들을 새롭게 느끼셨는지 궁금하네요! 개발자라는 직군이 코딩만 하는 사람들이 아니라, 비즈니스 문제를 개발로 해결하는 사람들이다보니까요! 이를 위해 다른 사람들과 협업하는 자세와 이해가 상당히 중요한 것 같네요ㅎㅎ
변경하면 좋을 것 같은 부분들 코멘트 드렸으니, 한번 확인 부탁드리겠습니다! 🙏
There was a problem hiding this comment.
안녕하세요! 6주차의 미션까지 고생 정말 많으셨습니다! 처음 리뷰를 보았던 것이 엊그제 같은데, 벌써 6주나 지났네요ㅎㅎ 최종 리뷰 요청까지 열심히 반영하고 달려주셔서 감사합니다 🙇
마지막으로 어떻게 조금 더 많은 도움을 드릴 수 있을까 고민을 했는데, 최종적으로 프로젝트를 다시 보고 피드백을 드릴 수 있는 부분을 드리면 좋을 것 같아서 시간 내어 정리해 보았어요!
이미 충분히 잘 개발해주셨는데 보다 좋은 개발자가 되시는 데 도움을 드리고 싶어서 작성한 것이니, 이를 학습 또는 개선의 방향 등으로 잡고 봐주시면 좋을 것 같습니다ㅎㅎ
- Optional의 활용
- 프로젝트 많은 부분에서 Optional을 활용해주고 계시는데, Optional이 개발된 의도는 무엇이고 올바르게 활용하고 있는지 공부해보시면 좋을 것 같습니다
- Optional의 isPresent는 대표적인 안티 패턴으로 여겨지는데, 해당 부분이 활용되는 곳이 보이네요
- 다만 전반적으로는 잘 적용해주셔서 이미 잘 알고 계시는 것 같다고 생각은 하지만 혹시 몰라 다시 한번 적습니다
@Autowired의 사용- 스프링은 생성자가 1개인 경우, 생성자에
@Autowired를 붙이지 않아도 자동 주입을 지원해줍니다 @Autowired는 스프링 프레임워크가 제공하는 애노테이션이며, 이는 우리의 코드가 스프링이라는 프레임워크에 결합된다는 것을 의미하기도 합니다- 스프링은 POJO 기반의 애플리케이션을 지향하고자 하는 관점에서 시작된 프레임워크입니다
- 따라서 불필요하게
@Autowired를 사용하지 않음으로써, 프레임워크로부터 까지도 순수하게 만들 수 있다면 더욱 바람직하다고 볼 수 있습니다
- 스프링은 생성자가 1개인 경우, 생성자에
- 트랜잭션
CategoryService에서createCategories시에 중간에 예외가 발생하면 원자성이 깨질 수 있습니다- 이를 위해
@Transactional을 활용하여 하나의 작업으로 묶어주는 과정이 필요합니다 - 트랜잭션에 대해서 공부하여 원자성있는 처리 방법에 대해 고민해보시면 좋을 것 같습니다
- DTO의 활용
- Service 계층은 비즈니스 로직을 처리하는 계층입니다
- 그런데 현재 구조 상으로는 클라이언트로부터의 입력과 출력에 대한 데이터가 Service 계층까지 활용되는 것을 볼 수 있습니다
- 그렇다면 DTO를 격리시킬 것인지, 아니면 효율적인 개발을 위해 DTO의 침투를 허용할 것인지 등에 대해서도 고민해보시면 좋을 것 같습니다
- Filter와 Interceptor
- Filter는 서블릿 범위, Interceptor는 스프링 컨테이너 범위입니다
- 인증되지 않은 사용자라면 스프링 컨테이너 내부에 침투하기도 전에 필터에서 먼저 거르는 것이 보다 안전할 수 있습니다
- 따라서 필터와 인터셉터에 대한 차이를 이해하고, 그에 따른 선택을 하는 것이 필요합니다
- 여기서도 마찬가지로 인터셉터라서 문제가 되는 것이 아니고, 인터셉터를 선택했다면 그에 따른 마땅한 이유가 있어야 함을 의미합니다
- 또한 HTTP Status 중에서 Forbidden과 Unauthorized에 대해서도 살펴보시면 좋을 것 같네요
- 연관 관계
- 연관 관계는 객체 간의 관계를 맺어주어, 객체 간의 협력을 통해 변경에 유연한 개발을 할 수 있도록 도와줍니다
- 하지만 이로 인해 N+1 문제와 같은 예상치 못한 동작이 생기기도 하고, 이로 인해 시스템 장애가 발생하기도 합니다
- N+1과 같은 문제는 어떻게 해결할 수 있는지, 연관 관계의 장점과 단점은 무엇인지 한번 정리해보시면 좋을 것 같습니다
- 테스트 코드
- 우리는 개발을 하면서 수시로 리팩터링을 반복해야 코드를 유지보수하기 좋은 상태로 유지할 수 있습니다
- 지속적인 리팩터링에서 안정성을 보장받을 수 있는 방법은 테스트(수동이든 자동이든) 밖에 없습니다
- 테스트는 우리의 구현이 올바른지 검증해주는 훌륭한 도구인데, 현재의 테스트는 구현이 바뀌면서 함께 깨지게 됩니다
- 따라서 어떻게 하면 코드가 변경되어도 테스트는 변경없이 우리의 코드가 안전함을 보장해줄 수 있을지 고민해보면 좋을 것 같습니다
- 또한 이력서 등에는 구체화된 수치를 작성하는 것이 중요한데, 테스트 커버리지 등은 이러한 수치화를 위한 훌륭한 수단이 될 수 있습니다
리뷰 요청드린 부분이 있는데, 시간이 늦어져서 바로 머지하도록 하겠습니다!
마지막까지 정말 고생많으셨습니다! 앞으로도 좋은 일들만 가득하시길 응원합니다ㅎㅎ 화이팅하세요!
|
안녕하세요 멘토님 조금 늦게 마지막 인사드리게 되었습니다! 해당 블로그의 관리자가 멘토님이라는 것을 멘토님이 블로그 주소를 공유해 주셔서 처음 알게 되었습니다. 이렇게 뵐 줄은 생각도 못했습니다 ㅎㅎ. 공부를 하며 모르는 것을 많이 여쭤보았는데, 이 과정에서 MangKyu 멘토님께서 항상 정성을 다해 지금까지 기능에만 집중하여 구현을 하다가, 카테캠을 통해 어떻게 하면 기능과 정제된 코드, 두 마리의 토끼를 잡을 수 있을지에 현재 카테캠 말고도 다른 프로젝트를 진행하고 있는데, 이 프로젝트에도 멘토님의 조언과, 카테캠에서 배운 많은 것들을 적용할 수 있었습니다. 올 한 해 가장 많이 성장했던 6주가 아니었나 싶습니다. step3 를 진행하기 전에 멘토님께서 말씀하신 부분, 마지막 코멘트 내용, 반영하지 못한 부분들(트랜젝션 등)에 대해 공부를 한 후 다시 한번 MangKyu 님께 정말 감사하다는 말을 전하고 싶습니다. |
|
그 동안 너무 고생 많으셨습니다! 앞으로도 지금처럼 열심히 하셔서 훌륭한 개발자가 되시기를 응원합니다:) |
제출합니다. 3단계는 완성되었고, 배포 파일이 아직 완성 안되었는데 완성 후 PR 요청드리겠습니다!
배포는 ec2 로 진행했는데, 깃액션을 통한 cicd deploy.yml 파일을 작성하는데 어려움이 있습니다.
도커를 사용해야 할 것 같다는 생각이 드네요