본문 바로가기

분류 전체보기

 (104)
2024-01-18 오늘은 프로젝트 15일 차이다. 이제 곧 중간발표가 얼마 남지 않아서 하루종일 프런트만 매진하면서 하루를 보냈다. 백오피스의 6개의 페이지 중에서 2개의 페이지를 구현했고 잘 동작하는 것까지 확인했다. 2개의 페이지를 구성하고 마지막으로 팀원과의 의견 조율을 통해 공연 조회 페이지 구현을 담당했다. 여기서부터 시작이었다. 프런트 간접체험기.. 지옥 그 자체였다. 백엔드 관점에서 프런트 관점으로 넘어가니 디자인에 거의 대부분의 시간을 소비한 것 같다.. 그리고 데이터를 다음 페이지에 어떤 방식으로 넘겨주고 초기에 어떻게 데이터를 받아서 올 것이며 이것저것 고민도 하니 소비되는 시간은 배가 됐다. 기본적으로 localStorage에 다음페이지에 넘겨줄 데이터를 저장하는 방식으로 진행했지만 더 좋은 개선 방향..
2024-01-17 오늘은 프로젝트 14일 차이다. 오늘 진행한 내용은 어제 진행하던 방식에서 Admin 부분을 완성하고 오늘 본격적으로 도메인 별 조회에 대한 기능 구현을 진행했다. 기존에 작성 돼있었던 공연 정보 페이징 전체 조회와 공연 정보 단건 조회를 공연 페이징 전체 조회와 공연 정보 단건 조회로 구성을 변경하여 작성했다. 공연 정보에서 공연으로 메인 페이지와 공연을 클릭하면 넘어갈 공연 조회 페이지를 모두 정보를 줘야 할 때 문제가 생겼다. 공연 정보에서 사용하던 제목을 공연 Entity에는 가지고 있지 않았기 때문에 다른 공연이지만 제목은 모두 공연 정보에서 제목을 가져와 제목이 같은 현상이 발생했다. 이럴 경우 페이지를 들어가도 사실 공연장에 대한 정보를 확인해야 다른 공연인지 확인이 가능해서 문제가 됐다. ..
2024-01-16 오늘은 최종프로젝트 13일 차이다. 오늘 진행한 내용은 프로젝트에 필요한 조회 기능을 구현했으며 공연장 조회 API, 공연 정보 단건 조회 API, 공연 정보 카테고리별 페이징 조회 API, 공연장 구역 조회 API, 회차 전체 조회API를 구현했다. 어제 새벽까지 진행하면서 구현하고 오늘 공연장 생성 페이지를 구현하고 와이어 프레임에 따라 다음페이지에서 클라이언트가 어떤 방식으로 요청을 보낼지까지 계산하면서 만들어야되기 때문에 여러 수정을 진행했었다. 진행하다보니 치명적인 오류를 발견했다. 와이어프레임을 기준으로 공연 정보를 생성하면 공연을 같이 생성하는데 이렇게 되면 공연과 공연장은 1:1 관계가 된다. 하지만 프로젝트의 구조에서는 즉 ERD를 기준으로는 공연 정보를 생성하고 공연을 1:M으로 설계가..
2024-01-15 오늘은 팀프로젝트 12일 차이다. 주말 및 오늘 진행한 내용은 다음과 같다. 주말동안 기존에 Entity 수정으로 인해 대부분의 코드가 리펙토링해야 하는 상황이었다. 따라서 주말 동안 리펙토링을 진행하면서 백오피스의 기능을 전부 구현했다. 백오피스의 기능은 다음과 같다. 공연장 생성 API, 공연생성 API, 등급 생성 API, 구역 등급 생성 API 기능을 구현했다. 각각 생성 API가 서로 연관되는 Entity가 많다 보니 뭐를 생성하는지 복잡하기 때문에 정리를 하려고 한다. 정리한 내용은 다음과 같다. 1. 공연장 생성 API 에서는 공연장 및 구역 Entity를 생성 및 저장한다. 공연장은 이름 및 주소와 총 좌석 개수를 가지고 있고, 구역은 공연장의 정보 및 공연장의 각 구역 정보와 좌석의 개수..
2024-01-12 오늘은 프로젝트 9일 차이다. 진행한 내용은 다음과 같다. 1. 진행 중이었던 회의를 마무리하고 새로운 ERD 편성 및 Entity 조정, 공연 생성 API 구성 1. 기존에 진행중이였던 공연 생성 시 좌석을 생성하고 이후 회차와 좌석의 정보를 통해 공연 회차별 좌석을 생성하던 방식은 데이터 베이스에 부하를 너무 많이 걸어서 DB가 다운되는 현상이 우려됐었다. 따라서 기존의 방식을 변경하고 새로운 방식으로 변경했다. 변경한 방식은 좌석을 생성하지말고 구역의 정보와 구역에 대한 등급의 정보를 통해 예매 및 경매를 할 때 요청이 들어오면 경매를 생성해 주는 방식으로 변경했다. 이러한 방식으로 진행을 하면 기존에 생성하는 것이 아닌 예매가 들어오거나 경매 요청이 오면 좌석을 생성하는 방식이기 때문에 Inser..
2024-01-11 오늘은 프로젝트 8일 차이다. 오늘 진행한 내용은 다음과 같다. 1. 공연 회차별 좌석 코드 및 테스트 코드 작성 1. 오늘은 공연 회차별 좌석 코드를 마무리하고 태스크 코드까지 완료하고, 중간에 공연 회차별 좌석 코드를 리펙토링 중에 튜터님의 멘토링을 받았다. 기존에 사용했던 방식은 기존에 입력해 놨던 좌석정보와 회차정보를 넣어주고 Request 받은 경매 좌석 번호를 통해서 경매좌석과 일반좌석을 생성하는 구조를 가지고 있었는데 튜터님이 이렇게 저장하면 나중에 DB에 데이터를 저장할 때마다 수백 개에서 수만 개의 데이터가 생성이 될 텐데 공연이 추가될수록 데이터가 누적되면서 나중에 Join을 하려면 수만 개의 데이터를 조회해야 하기 때문에 나중에 DB가 작동을 멈추는 즉 뻗어버리는 현상이 발생할 수 있..
2024-01-10 오늘은 프로젝트 7일 차이다. 오늘 진행한 내용은 다음과 같다. 1. 공연 추가 API Test 코드 작성 및 공연 회차별 좌석 기능 구현 진행 공연 추가 API TEST 코드를 작성하다 보니 테스트 코드 자체에서 문제가 있었는데 GoodsEntity를 생성할 때 연관 관계가 맺어 있는 Entity를 추가하고 보니 공연 추가 API에서는 Respone에 대한 응답값이 없어서 테스트를 할 때 어떤 방식으로 진행해야 되는지 고민이 됐다. 여러 찾아보니 API자체 안에 있는 각 메서드의 기능들을 더 쪼개서 단위테스트를 진행하면 된다고 해서 여러 설정을 마치고 단위테스트를 진행했다. Service 단위 테스트를 진행하면서 제일 문제가 됐던 부분은 공연을 생성할 때 공연만 생성하는 것이 아니라 여러 연관관계에 있..
2024-01-09 오늘은 프로젝트 6일 차이다. 오늘 진행한 내용은 다음과 같다. 1. Admin 공연장 추가 API Test, Admin 공연 추가 API 기능 구현 오늘 코드를 작성하면서 문제가 됐던 부분은 Request를 받을 때 List 부분에서 @NotNull를 사용하여 검증을 하고 있었는데 List는 생각해 보니 Request에서 List에 대한 값이 없는 상태로 요청이 올 때는 Null이 아니라 비어있는 객체로 들어오기 때문에 @NotEmpty 어노테이션을 사용해서 빈 객체인지를 체크해야 된다. 또한 테스트 코드를 작성하면서 Validation에 대해서 테스트 코드를 작성할때 테스트 하는 방식에 대해서 배웠다. private static ValidatorFactory factory; private static..

티스토리툴바