[과제] Spring e-Commerce back office Task Day 4

https://github.com/Hyeonseok-Homies/Spring_e-commerce-back-office

GitHub - Hyeonseok-Homies/Spring_e-commerce-back-office

 

개발완료되었고,

 

발표 자료를 준비하는 날이다.

 

사실오늘 주말간 각자 개발한 내용을 깃에 합치는 과정에 오류해결과 수정사항 반영에 많은 시간이 허비되었지만,

완성도 있는 프로젝트를 만들기위해 어쩔수 없는 결정이였다고 생각한다.

 

나는 과제 발표를 담당하게 되었고, 시연영상을 준비하기로 하였다.

 

우선, 튜터님의 피드백부터 정리를 해보자

1. 코드 품질 및 클린 코드 (Clean Code)

• 리소스 최적화: adminInitializer나 사용하지 않는 코드/주석은 최종 제출 전 반드시 정리 (IDE의 Optimize Imports 기능을 적극 활용)
• 로깅 (Logging): @Slf4j를 사용해 로그를 남기는 습관을 들이기 당장의 기능 구현보다 어느 위치에 어떤 로그를 찍어야 흐름 파악이 쉬울까? 를 고민하는 것이 선행 학습의 핵심
• 리팩토링 팁: 메서드 추출 단축키(Cmd + Opt + M)를 활용해 코드 가독성을 높여라

 2. 아키텍처 및 설계 (Design)

• 비즈니스 로직: "묻지 말고 명령하라(Tell, Don't Ask)" 원칙을 지켜라. 객체의 상태를 가져와서 판단하지 말고, 객체에게 일을 시키는 구조가 객체지향적
• 비밀번호 변경: 자원의 일부 수정(PATCH)보다는 보안과 인증의 중요성을 고려해 POST를 주로 사용
• 예외 처리: CustomException은 네이밍을 직관적으로 하고, 도메인별로 묶어 관리. 설계보다 예외가 왜 필요한지가 더 중요
• CQRS 패턴: 데이터 조회(Read)와 명령(Write)을 분리하는 패턴을 참고하여 성능과 복잡도를 제어해 보아라

 3. 데이터베이스 및 JPA (DB & Persistence)

• 삭제 전략 (Soft vs Hard Delete):
  • 실무에서는 법적 근거 및 복구 가능성을 위해 del_yn 같은 상태값을 사용하는 Soft Delete를 자주 사용한다
  • JPA에서 모든 조회 쿼리에 where del_yn = 'N'을 자동으로 붙여주는 기능을 찾아 학습하자
• 성능 최적화:
  • OneToMany 관계는 성능 이슈(N+1 등)가 발생할 확률이 매우 높으니 주의
  • 통계 데이터(총 주문 수 등) 조회 시 전체를 불러오면 서버가 터질 수 있으므로, JPQL을 통해 필요한 데이터만 한 번에 조회하도록 쿼리를 짜야 한다
  • LIKE 검색 시 앞뒤에 %를 붙이는 방식은 인덱스를 타지 않아 비효율적일 수 있음을 인지
• 컨벤션: DB는 snake_case, Java는 camelCase, 클래스는 PascalCase를 준수하고, JoinColumn 네이밍은 주로 소문자를 사용

@Transactional(readOnly = true): 클래스 상단에 기본으로 선언하고, 쓰기 작업이 필요한 메서드에만 @Transactional을 오버라이딩하는 것이 성능과 실수 방지에 유리
@Builder: 클래스보다는 생성자 위에 붙여 필요한 필드만 빌더에 노출하는 것이 안전 상속 관계라면 @SuperBuilder를 고려
실무의 유연성: 실무라고 무조건 FK를 거는 것은 아니다. 시스템의 확장성과 성능을 고려해 선택

 

튜터님의 피드백을 정리해보니, 단순히 학습한 지식으로 코드를 작성하는게 아니라 왜 이걸 사용하는지 코어 개념을 이해하고, 그것을 바탕으로 나은 기술이 있는지 어떤 상황에서 어떤 기술을 사용해야 하는지 활용할수 있는 유연한 개발자가 되기를 바라시는것같다. 

그리고, 간간히 알려주시는 실무에 대한 이야기들이 학습하는 나의 입장에서 앞으로 나아가야하는 길라잡이가 되는 좋은 피드백이였다!

 

 

그다음 시연 영상을 만들어보자

1.시연영상은 포스트맨으로 녹화를 진행

2.발표시간은 팀당 7분 제한됨으로 영상이 길다면 배속을 돌려 해결하는것으로!

 

 

 

 

빠르게 녹화를 할려고 보니, API ID값 혼동으로 시간이 생각보다 많이 지체 되었다.ㅠㅠ

소비자 삭제시 500에러가 나는 부분은 내일 팀원들과 상의하여 수정해야겠다!