본문 바로가기

분류 전체보기192

112일차: Main_Project Day 19 (문서 작성, 최종 제출, 배포링크) 프로젝트 관련 최종 배포 링크와 산출물들을 제출하는 날이었다. 제출해야 하는 자료는 아래와 같았다. 사용자 요구사항 정의서, API 명세서, 화면 정의서, ERD는 초기 기획 단계에서 작성 완료하고 이후 작업하면서 수정되는 부분은 바로바로 적용해 두었기 때문에 추가로 수정할 부분이 없었다. 개발자 테스트 체크리스트 역시 프론트엔드, 백엔드 같이 모여서 기능테스트가 완료되면 완료 처리를 하고 있었다. 프로젝트 매뉴얼 문서는 오늘 점심 이후부터 저녁 전까지 작성했다. 사용자가 되었다고 생각하고 사이트를 직접 사용해 보면서 각 페이지 및 설명이 필요한 부분을 캡처하고 부가 설명을 작성했다. 내용을 작성하다 보니 약 20페이지 정도가 나왔다. 프로젝트에 대한 애정 많다 보니 설명하고 싶은.. 2023. 7. 24.
111일차: Main-Project Day 18 (데이터 추가, 프로젝트 매뉴얼 구상) 총 825개의 제품 데이터를 입력 완료했다. MySQL Workbench를 사용해 등록했는데 한번 사용법이 익숙해지고나니 생각보다 금방 끝낼 수 있었다. (제품 사진을 모으고 제품 이름과 설명을 지어내는게 오래걸렸다. 그렇지만 즐거운 창작의 시간😋) 그리고 프로젝트를 마무리하며 마무리 기술 발표, 매뉴얼 자료를 구상하고있다. 먼저 기술 발표의 경우 자신이 구현한 기능, 도구, 기술 스택 등에 관한 주제를 선정하고 2분 내외로 발표 영상을 제작하도록 되어있었다. 팀원들 각자 맡은 부분에서 주제를 선정해서 발표 자료와 영상을 제작하기로 했다. 내가 담당했던 부분은 회원 CRUD(회원가입, 회원정보조회, 회원정보수정, 회원탈퇴)와 Security(로그인, 로그아웃, 토큰재발급, CORS 설정 등), 그리고 마.. 2023. 7. 21.
110일차: Main-Project Day 17 (주문내역 조회 수정, DB 데이터 삽입) 큰 작업은 끝나서 필요한 경우 코드 수정을 하고 DB에 초기 데이터 넣는 작업을 하고있다. 1. 주문 내역 데이터 전달시 개인별 몇번째 주문인지 표시 Order 엔티티에서 식별자로 orderId를 쓰고 있다. 주문 내역을 전달할때 orderId 내림차순으로 데이터를 정렬해서 전달하므로 orderId를 응답 필드로 보내주고 있었다. 그런데 프론트쪽에서 주문에 순번을 붙이려면 몇번째 주문인지 연속된 숫자로 오는것이 작업하기 편하다고 한다. 아무래도 페이지네이션까지 적용되어있다보니 백엔드서버에서 관련 데이터를 정리해서 보내주는게 간편할것같기는 하다. OrderInfo에 orderCount 필드를 추가하고 페이지 번호에 맞춰서 몇번째 주문인지 순번을 추가해서 전달하는것으로 코드를 추가했다. @Builder @G.. 2023. 7. 20.
109일차: Main-Project Day 16 (CSV파일 Import, 0 records imported, 데이터 넣기) 이제 정말정말 코드 구현이 마무리되어가고있다. 배포 환경도 어느정도 안정화가 돼서 실제로 데이터가 필요한 시점이 왔다. 지금까지는 가게 1개, 제품 10개만 등록되어있는 아주 작은 사이트였다. 실제 서비스처럼 여러가지 선택지도 주고, 데모데이때 실감나는 사용자 경험을 제공하기 위해서는 많은 데이터가 들어있어야한다. 실제 서비스라면 사업자 회원이 직접 가게정보, 제품 정보를 등록하겠지만 현재 사업자쪽 기능은 구현되어있지 않아 직접 넣어주어야한다. 오늘 아침 주문조회쪽 테스트를 위해 데이터를 수동으로 입력했는데 Orders테이블, Orders_Product 테이블에도 같이 내용을 넣어야하다보니 해당 과정도 생각보다 손이 많이갔다. 팀원들이랑 대략적으로 얘기를 한게 가게 정보 약 55개, 가게별로 약 12개씩.. 2023. 7. 19.
108일차: Main-Project Day 15 (주문 정보 조회, FetchType, LazyInitializationException) 마이페이지 주문 내역은 조회만 하면 되는 부분이라 비교적 간단할거라고 생각했는데 어김없이 에러를 만났다. 현재 우리팀의 ERD 구조는 다음과 같다. Member-Order는 1:N 관계로 구성되어있다. Order-Product는 N:N 관계로 중간 테이블인 order_product 테이블이 연결해주고있다. 이렇게 테이블간의 연관관계가 있을 경우 특정 데이터를 조회할때마다 연관관계가 있는 다른 테이블까지 같이 조회하게되면 불필요한 과정을 거치고 효율이 떨어질 수 있다. ex. 회원 정보에서 닉네임만 조회하면 되는데 Orders, Cart까지 모두 조회하는 경우 이때 적용 가능한 것이 FetchType이다. 크게 두가지로 구분된다. 1. FetchType.EAGER 즉시 로딩을 의미한다. 연관된 엔티티를 즉.. 2023. 7. 18.
107일차: Main-Project Day 14 (마이페이지 API 설계) 프론트엔드쪽 코드도 어느정도 마무리가 되어가서 드디어 마이페이지 작업에 들어갔다. 마이페이지 구조는 아래와 같이 상단(회원 정보 조회, 회원 정보 수정 기능)과 하단(주문 내역 조회 기능)으로 나눌 수 있다. 상단에서 필요한 기능은 회원 정보를 표시하고, 정보를 수정하면 변경된 정보를 띄워주는 기능이다. 하단에서 필요한 기능은 해당 사용자의 주문 내역을 띄워주고 각 주문 내역을 누르면 세부 내용이 표시된다. 처음 프론트 담당자분이랑 데이터 형태를 정할때 한 페이지니까 아래와 같이 한번에 데이터를 보내는 방향으로 정했었는데 { “memberId”: 3, “memberName”: “닉네임”, orderInfos: [ { “orderId” : 1, “createdAt” : 2023-07-16 08:16:57,.. 2023. 7. 17.

티스토리툴바