Today I Learned
-
POST 요청으로 연관관계를 갖는 객체들의 데이터 생성하기Today I Learned 2022. 11. 1. 23:53
객체 간 연관관계가 존재하는 객체들의 데이터를 한 번에 생성해 저장해야 하는 경우가 있다. 가령 게시글을 작성한다고 할 때, 글과 함께 사진 여러 장을 첨부해 등록하는 경우가 있다. JPA 환경 하에서 이를 구현하고자 한다면 사진 객체 여럿이 게시글 하나를 참조하는 형태가 될 것이다. 나중에 언젠가는 짚고 넘어가야 할 부분이므로 미리 연습해보는 차원에서 POST 요청을 통해 연관관계를 갖는 객체들을 생성해야 하는 순서를 정리했다. 유저 객체를 생성하면서 생성된 유저 객체가 작성자인 게시글들을 동시에 생성하는 경우를 생각해보자. (예시가 이해가 가지 않는다면 유저를 게시글에, 게시글을 이미지에 매핑해보자.) 다음의 테이블들 중 PERSON 테이블에 새로운 사용자를 추가하고, 생성된 사용자 객체를 참조하는 ..
-
모델 구조 설계는 데이터베이스 설계가 아닌 객체 설계 먼저Today I Learned 2022. 10. 30. 23:57
모델 구조의 확장 시도 어제 구현한 MVP를 기반으로 기능에 보여질 내용을 확장하기 위해 최초로 작성한 모델을 확장하기 시작했다. MVP는 게시글 목록만을 확인할 수 있는 아주 단순한 모양으로, 모델 역시 최소한의 객체만으로 이루어져 있었다. '게시글' 모델, '사용자' 모델이 존재했고, 게시글 모델은 id와 글 내용, 게시글에 등록된 사용자 리스트, 사용자 모델은 id와 이름, 사용자가 등록되어 있는 게시글 리스트만으로 이루어져 있었다. MVP의 확장은 두 단계에 걸쳐서 하려 했다. 먼저 사용자, 게시글 모델 사이에 '운동 포지션' 모델을 추가할 계획이었다. 여러 포지션들이 게시글 하나에 속하는 구조를, 그리고 각 포지션에는 여러 명의 사용자가 속하고, 각 사용자도 여러 개의 포지션을 갖는 양방향으로 ..
-
양방향 @ManyToMany 관계를 갖는 모델을 정의하고 데이터 가져오기Today I Learned 2022. 10. 29. 22:51
어제 도장에서 결국 모델 정의를 마무리하지 못하고 집에 돌아왔다. 이렇게 줄이고 줄인 최소한의 모델에서도 도대체 어느 부분이 어려웠다는 말인가? 게시글 목록과 상세 게시글을 구현하기 위한 데이터를 가져오기 위해 왼쪽 사진과 같이 백엔드 서버에서 가져와야 하는 데이터들을 구성했다. 이때 게시글과 사용자의 관계는 게시글에 여러 명의 사용자가 포함이 될 수 있고, 반대로 사용자 역시 자신이 참가하는 여러 개의 게시글을 알 수 있어야 하는 다대 다로 서로를 양방향으로 알 수 있어야 하는 구조였다. 이 구조를 지금 알고 있던 내용만으로는 백엔드에서 정의하기가 쉽지 않았다. 관계형 데이터베이스에서 테이블 간의 관계를 나타내기 위한 OneToOne, OneToMany, ManyToOne, ManyToMany 관계 중..
-
너무 큰 작업은 task를 쪼개 MVP로 만들기Today I Learned 2022. 10. 28. 23:58
어제 TIL을 올린 직후 게시글 리스트 화면과 게시글 상세정보 조회 화면을 구현하기 위해 작업 설계를 시작했다. 프로토타이핑 화면을 바탕으로 구현하려면 먼저 썸네일에서 나타나는 데이터를 갖춰야 할 것 같아 먼저 모델을 정의하려 했다. 작업 Catalog를 만들 때는 모델을 계획하는 순서를 게시글, 모집 포지션, 사용자 순으로 짜는 것을 계획했었다. 작업을 설계하기 시작하면서 느낀 점은 모델을 정의하는 것은 사실상 데이터베이스 테이블들을 설계하는 것과 같다는 것이었다. 직접 모델을 설계해보니 모델이 다른 모델의 정보를 가져와야 할 때 연결성을 어떻게 부여해야 할지 설계를 하는 단계인데도 쉽지 않게 느껴졌다. 모니터 화면에 글로만 적는 것은 한계가 느껴져서 도장에 일찍 나와서 구조도를 직접 그려보기로 했다...
-
2주차 목요일 데일리 스프린트 작업 회고Today I Learned 2022. 10. 27. 23:33
오늘 진행한 Task를 정리하면서 작업 과정을 돌아보았다. 작업 예상 스토리 포인트 실제 스토리 포인트 회고 백엔드 개발 환경 세팅 2 1 기본 Security 화면을 제거하고 WelcomeController를 생성하는 작업까지 진행했다. 추후 실시간 채팅 구현 시 Spring Web이 Spring Reactive Web으로 변경될 가능성이 있을까? 헤더 생성 및 디자인 잡기 1 2.5 단순히 헤더 컴포넌트를 추가하고 요소 배치, 링크로 끝날 것이라고 생각해 스토리 포인트를 매우 작게 부여했다. 그러나 작업에 들어갔을 때 라이브러리 설치, URI 네이밍, 인수 테스트, 단위 테스트 작성 등 구현을 위해 같이 해줘야 하는 작업들을 생각하지 못했다. 설치한 라이브러리를 어떻게 사용하는지도 꽤나 자주 돌아보면..
-
첫 스프린트 티켓 끊기Today I Learned 2022. 10. 26. 23:47
어제부터 사용자 스토리를 개선하고 있던 사용자 스토리를 바탕으로 프로젝트 매니저 역할을 맡고 계신 노아님과 함께 첫 스프린트 티켓을 끊었다. 앞으로 남은 프로젝트 주간은 다음의 흐름으로 진행될 예정이다. 월요일에 노아님과 작업 우선도, 진척도 등을 바탕으로 작업 Catalog에서 한 주 동안 스프린트로 수행할 작업 목록들을 선정해 Todo로 가져온다. 작업 하나를 진행할 때마다 해당 작업을 Doing으로 올린다. 작업을 마쳤다면 Done으로 옮긴다. 작업을 마치지 못하고 다른 작업으로 전환해야 한다면 Todo로 작업을 내린 뒤 다른 작업을 Doing으로 올린다. 이 과정에서 각 작업마다 선정한 Story Point (각 작업을 수행하는 데 걸릴 것으로 예상되는 작업 단위로, 이번 프로젝트에서는 뽀모도로 ..
-
사용자 스토리와 작업 백로그로 프로젝트의 기틀 잡기Today I Learned 2022. 10. 25. 23:36
지난 일주일 동안 기획한 내용을 바탕으로 앞으로 7주 동안 작업해야 할 작업 백로그를 작성하고 있다. 작업 백로그는 초기 기획에서 작성한 사용자 스토리를 기반으로 작성하는 모든 작업을 적정 단위에 맞게 구분한 것이다. 매주 백로그에서 일주일 동안 진행할 작업 양을 TODO로 가져와 작업을 진행하는 스프린트 방식으로 일과가 진행될 예정이다. 월요일에 기획을 바탕으로 첫 작업 백로그를 작성하기 시작했을 때, 사용자 스토리 하나를 메인 화면, 운동 모집글 작성하기, 클럽 리스트 보기처럼 한 화면 전체에서 나타나는 작업을 기준으로 작성했었다. 그리고 작업 목록을 프론트엔드 화면에서 나타나는 프로세스 위주로 작성했었다. 작성한 사용자 스토리와 그 하위 작업 목록에 대해 노아님께 피드백을 받았다. 우선 사용자 스토..
-
명확하게Today I Learned 2022. 10. 24. 23:43
18주차 월요일을 보내면서 느꼈던 점을 정리했다. 기술 스택 선정에는 자기만의 기준이 필요하다 주중 며칠 동안 조사한 기술 스택 선정 이유를 바탕으로 프로젝트 기획 발표 시간에 기술 스택을 발표했다. 결과는 노아 트레이너님을 전혀 설득하지 못한 채 처참한 결과로 끝났다. 사용하려는 프레임워크의 좋은 점을 나열하고, 다른 프레임워크 몇 개의 특징을 늘어놓는 방식으로는 기술이 사용되어야 하는 이유를 듣는 사람에게 납득시킬 수 없었다. (그나마도 특징 나열도 잘 못 했다.) 내가 말하면서도 느껴졌다. 기술 스택 선정에 자기만의 기준이 있어야 한다는 노아님의 설명이 있었다. 생각해보니 며칠 전에 슬리퍼가 필요해서 쿠팡으로 슬리퍼를 찾아볼 때도 디자인이나 가격, 편의성 같은 기준을 세우고 동료들에게 물어도 보면서..