일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- R
- coding test
- s
- 윤성우 열혈자료구조
- Selection Sorting
- 이것이 자바다
- 이스케이프 문자
- buffer
- JSON
- Graph
- list 컬렉션
- C programming
- 메모리구조
- C 언어 코딩 도장
- 윤성우의 열혈 자료구조
- 혼자 공부하는 C언어
- stream
- insertion sort
- Serialization
- 알기쉬운 알고리즘
- Algorithm
- Stack
- datastructure
- Today
- Total
목록SW Engineering (20)
Engineering Note
상황 설명OrderDto주문을 위해 상품 id와 상품 주문 수량 count값을 담는 DTO 클래스@Getter @Setter@AllArgsConstructor@NoArgsConstructorpublic class OrderDto { @NotNull(message = "상품 아이디는 필수 입력 값입니다.") private Long itemId; @Min(value = 1 ,message = "최소 주문 수량은 1개입니다.") @Max(value = 999, message = "최대 주문 수량은 999개입니다.") private int count;} OrderItem Entity- Order Entity와 Item Entity의 릴레이션 테이블이면서 주문 상품 정보를 담는 Ent..
들어가며장바구니에 담긴 OrderItem을 주문으로 처리하는 코드를 리팩토링하면서 겪은 여정을 공유합니다. 단순히 코드를 깔끔하게 만들려던 시도가 N+1 문제 발견과 성능 개선으로 이어진 과정을 담았습니다. 문제의 시작: forEach의 한계초기 코드는 stream().forEach()를 사용해 주문 정보를 처리했습니다. 문제의 시작: forEach의 한계초기 코드는 stream().forEach()를 사용해 주문 정보를 처리했습니다.public Long orders(List orderDtoList, String email) { // 1. 회원 조회 (1st Query) Member member = memberRepository.findByEmail(email); ..
이 글은 게시판의 댓글 좋아요 기능의 DB를 설계하면서 UNIQUE 제약조건을 알게 된 과정을 정리한 글입니다. 요구사항댓글 좋아요 기능에 필요한 요구사항은 다음과 같았습니다.로그인한 유저만 좋아요 가능중복 좋아요 방지 (한 댓글에 한 번만 좋아요 가능)특정 댓글의 좋아요 수 조회특정 유저의 좋아요 목록 조회 테이블 설계 과정기존 테이블 구조Member (회원)Board (게시글)Comment (댓글)고민: 좋아요 데이터를 어디에 저장할까?처음엔 Comment 테이블에 like_count 같은 컬럼만 추가하면 되지 않을까 생각했습니다.하지만 문제가 있었습니다:누가 좋아요를 눌렀는지 알 수 없음로그인 후 "내가 좋아요 누른 댓글"을 표시할 수 없음좋아요 취소 기능을 만들 수 없음 해결: Like 테이블 분..
이커머스 쇼핑몰 서비스 프로젝트를 하면서 도메인 모델을 설계한 경험을 공유합니다. 단순히 "이렇게 만들었다"가 아닌, 왜 이런 선택을 했는지에 초점을 맞춰 설명합니다. 전체 도메인 모델 개요 Member (회원) ↓ 1:1Cart (장바구니) ← N:1 → CartItem (장바구니상품) → N:1 → Item (상품) Member (회원) ↓ 1:NOrder (주문) ← N:1 → OrderItem (주문상품) → N:1 → Item (상품) 핵심 엔티티:Member: 회원 정보Item: 상품 정보Cart / CartItem: 장바구니 (주문 전 임시 보관)Order / OrderItem: 주문 (구매 확정) 1. Item 엔티티: 기본 설계 결정설계 의도상품은 쇼핑몰의 핵심 엔티티로, 독..
Spring Boot 프로젝트에서 수동 배포의 번거로움을 해결하고 개발 생산성을 높이기 위한 완전 자동화 CI/CD 파이프라인을 구축하는 실용적 가이드이자 개발 과정에서 실제 적용한 방법을 기록하고 공유하기 위한 글입니다. 수동 배포의 한계점반복적인 수작업: SSH 접속 → 코드 pull → 빌드 → 실행의 반복배포 시간 소요: 매번 7분 이상의 수동 작업 필요휴먼 에러: 수동 과정에서 발생하는 실수개발 집중도 저하: 배포 과정에 신경 써야 하는 부담 목표 설정PR 병합 시 자동 배포 실현배포 시간 대폭 단축100% 자동화로 휴먼 에러 제거개발자가 기능 개발에만 집중할 수 있는 환경 구축 전체 아키텍처 플로우:개발자가 PR 생성 및 병합GitHub Actions가 자동 빌드 시작Docker 이미지 생..
프로젝트를 하면서 발생한 에러를 중심으로 JavaScript(이하 JS) Stack Trace 읽는 법을 정리하려고 한다. JS뿐만 아니라 모든 언어에도 적용 가능하다. 발생한 에러Uncaught TypeError: Cannot read properties of undefined (reading 'message') at Object.error (cart:163:50) at c (jquery-3.5.1.min.js:2:28294) at Object.fireWith [as rejectWith] (jquery-3.5.1.min.js:2:29039) at l (jquery-3.5.1.min.js:2:79825) at XMLHttpRequest. (jquery-3.5.1.min.js:2..
이어 지는 글구체적인 사례로 보는 JS 에러 메세지 읽는 법(https://techbook11.tistory.com/713)장바구니 주문 기능을 개발하던 중 발생한 흔한 실수와 그 해결 과정을 공유합니다. 프론트엔드와 백엔드 간의 데이터 타입 불일치로 인해 발생한 문제로, 많은 개발자가 겪을 수 있는 사례입니다. 문제 상황사용자가 장바구니에서 주문 버튼을 클릭했을 때 다음과 같은 현상이 발생했습니다. 사용자 관점의 문제:- 주문버튼을 눌렀지만 아무런 반응이 없음- 에러메세지가 표시되지 않아 무엇이 잘못되었는지 알 수 없음 시스템 관점의 문제:- HTTP 400 Bad Request 응답- Javascript TypeError 발생 에러 분석1단계 : 프론트엔드 에러 확인브라우저 개발자 도구에서 다음 에러..
이커머스 프로젝트에서 장바구니 조회 기능을 구현하면서, 여러 테이블에 분산된 데이터를 효율적으로 조회하는 방법을 고민했습니다. N+1문제를 피하고 성능을 최적화하면서도 필요한 모든 정보를 한 번에 가져오는 과정을 공유합니다. 요구사항 분석 사용자 스토리:로그인한 사용자가 장바구니 페이지에 접속하면, 담아둔 상품들의 이름, 가격, 수량, 대표 이미지를 확인할 수 있어야 한다. 기숙적 요구사항한 번의 쿼리로 모든 필요한 정보 조회 (N+1 문제 방지)상품의 대표 이미지만 표시 (상품당 여러 이미지 중 하나만 표시)장바구니가 비어있는 경우 예외 처리 데이터 모델 설계프로젝트의 핵심 Entity들과 연관관계입니다. // 장바구니 (회원당 1개)@Entity@Table(name = "cart")@Getter @..