기술적 의사결정 어떻게 할 것인가
1.
우리 프로젝트에 부합하는 기술을 선택
2.
장단이 적절하다면 설명할 이유가 많은 걸로 고르고 이걸 설명할 수 있을만큼 고민해본다.
3.
일부러 처음에 별로인 코드 → 리팩토링하면서 성능 개선도 고려
2024.01.05
초반 엔티티를 CodeWithMe로 미리 다 잡은 다음 로컬에서 진행하는 것이 좋은가?
합칠 때 서로 안 막힌다. 코드 짜면서도 참조할 일이 많으니까..
네명이서 코드위드미 모이니까 발열이 장난이 아니고 아예 타이핑이 안되는 팀원도 있다.
다른 방법을 고안해보자!!
→ 각자의 도메인 브랜치를 만들고. 엔티티 각자 완전히 만들고/ 컨트롤러, 서비스, 레포지토일 파일만 만들고 병합하기
중간 패키지 HHive가 꼭 필요한 것인가.
com.회사 이름.플랫폼(있다면).프로젝트 이런 구존데 그냥 우리는 com.HHive.hhive로 두기로
code formatting 맞추기 위해 intellij 설정 동기화
디비 관련 yml에 선언된 변수들 환경변수 설정했음
git pull 받았을 때 Module Entity with name 오류 발생
git zip 파일로 받으니 해결!!
다대다 관계에서 중간테이블 어떻게 구성할 것이냐?
복합키를 쓰라고 피드백은 많이 오는데 과연 장단이 뭘까?
→ 복합키 사용하는 게 더 적절하다.
대체키 자체가 의미없는 컬럼이기도 하고 두 엔티티가 얽힌 중간 테이블이기 때문에 레코드 개수가 아주 많아질 가능성이 있어 Long 자료형으로는 한계가 올 수도 있다.
DTO 네이밍 어떻게 할 것인지
GetCardDTO(record 클래스로 선언) → 내부에서 response, response 나눔
GetCardReqeustDTO, GetCardResponseDTO - 너무 기본.
CardDto 안에 다 넣기 - 파일이 너무 많아지는 것을 방지할 수 있고, 도메인에 필요한 DTO를 한눈에 볼 수 있다.
→ 장단점이 그렇게 뚜렷하지 않고 회사 내규에 따라 다른 선택의 문제인데 우리 팀은 1번옵션 선택
DTO로 엔티티 생성할 때?
DTO 내부에 메소드 선언하여 toEntity 느낌으로 생성. → 말도 안된다. DTO는 데이터 전달 역할만 해야한다.
엔티티 클래스 안에 DTO를 받는 생성자를 만들어라 → 이것도 안 좋음
그러면 서비스 단에서 직접 빌더쓰거나 따로 메소드로 빼라..
중간 테이블을 위한 클래스는 어떻게 선언할 것인가.
이 중간 테이블은 두 중요 엔티티를 이어주기만 하는 역할이니 어떤 한 도메인에 속한다고 볼 수 없다.
relationship이란 패키지를 하나 만들어서 PartyUser, UserNotification과 같은 중간 엔티티들을 관리하기로 했다.
github 브랜치 전략 브랜치 머지 후 삭제하는 것이 맞는가. → 고민을 해보자
global > config에 security 만들까? → security패키지 따로 만들자
하이브게시판 주최자 id가 있는데 왜 필요한가요?
1.
주최자만 할 수 있는 기능 권한 부여
2.
모임 이름 보여주기.
카테고리 테이블을 Enum으로 두는 것에 대한 고려
만약에 안 둔다면 카테고리 테이블과 하이브의 연관관계는 어떻게 되는가 → 주말동안 고민해보자.
2024.01.08
유저 프로필 조회 url 설정 논란
api/user/profile/{user_id} 원래 이건데 restful API에 위배된다고 한다.
user/{user_id} vs user/{user_id}/profile
이건 전자가 승리했다. 프로필과 유저 정보를 분리하여 주는 경우가 없을 것이라고 생각.
카테고리를 테이블로 뺴면 추후에 확장성에는 좋겠지만 지금 당장 필요도 없고
카테고리는 런타임 환경에서 변하지 않는다.
필수기능, 부가기능이 구분이 모호하다.
부가기능 실시간 채팅, 알림, 위치기반 세 개인데 이거 해본 사람이 없는 거 치고 너무 벌려놨다.
필수기능 유저 인증/인가, 하이브, 파티, 프론트, CI/CD 이걸 우선시 하고
시원님은 부가기능 알림 위주, 동하님은 프론트 연결 우선시. 채팅방은 ERD에 있지만 좀 나중으로 미루자.
카테고리를 enum으로 하기로 했는데 이걸 계층형으로 하려면?
Category.Game.LOL 이래도 잘 저장되나? 후에 게임들에 대한 하이브를 보여주려면?
이게 테이블이 없으면
1.
모든 하이브 긁어온 다음에 카테고리 컬럼 비교하면서 게임 enum 리스트에 있는지 보여주기
2.
게임 enum 리스트에 있는 enum 개수만큼 같은 테이블을 조회
3.
혹은 or을 사용한다? 1,2,3 성능 똑같은 것 같은데
→ 테이블 하나에서 self relation, self join 써도 좋지만 일단은 구현이 우선이고 나중에 개선을 하든가 해라. 일단 그냥 enum으로
enum으로 대주제→소주제 선언해서 유저 카테고리 테이블에 쫘르르 넣자.
셀프 relation self join
중간 테이블에 생성시간, 수정시간?
넣어야하는 이유:
1.
일관성 유지:
•
이미 다른 테이블들이 생성시간과 수정시간을 가지고 있다면, 중간 테이블도 이에 부합하여 일관성을 유지하는 것이 좋습니다.
2.
쿼리 및 분석의 편의성:
•
만약 중간 테이블에 시간 정보가 있으면, 특히 특정 시간 범위 내의 관계를 쿼리하거나 통계를 내는 등의 작업이 더 편리해질 수 있습니다.
3.
히스토리 추적:
•
만약 중간 테이블에 생성시간과 수정시간을 추가하면, 특정 관계의 변화를 추적하거나 히스토리를 기록하는 데 도움이 됩니다.
4.
프로젝트의 미래적 확장성:
•
현재는 중간 테이블에 생성시간과 수정시간이 필요 없다고 하더라도, 나중에 프로젝트가 발전하면서 이 정보가 필요해질 수 있습니다. 미리 중간 테이블에 추가해 두면 미래의 요구사항에 대비할 수 있습니다.
넣지 말아야하는 이유:
1.
불필요한 데이터 저장:
•
중간 테이블에 생성시간과 수정시간을 추가하면 해당 정보가 불필요하게 중복 저장될 수 있습니다. 특히 중간 테이블이 단순한 관계 정보만을 나타내는 용도라면, 이러한 시간 정보는 중복 저장으로 인한 데이터 불필요성을 초래할 수 있습니다.
2.
설계의 간소화:
•
중간 테이블이 주로 관계를 나타내는 역할만 수행한다면, 시간 정보는 해당 테이블에 불필요한 추가 복잡성을 초래할 수 있습니다. 테이블의 설계를 간소화하고 읽기/유지보수의 편의성을 높이기 위해 시간 정보를 생략하는 경우도 있습니다.
3.
데이터 일관성 유지:
•
중간 테이블이 관계 정보만을 담고 있다면, 이 테이블의 데이터는 일반적으로 매우 유동적입니다. 따라서 해당 관계의 생성 및 수정 시간을 따로 관리하는 것이 필요하지 않을 수 있습니다.
4.
프로젝트의 특수한 요구사항:
•
몇몇 프로젝트나 비즈니스 상황에서는 중간 테이블에 생성시간과 수정시간을 추가할 필요성이 없을 수 있습니다. 예를 들어, 특정 관계의 변화를 추적할 필요가 없는 경우 등이 있을 수 있습니다.
회의록도 좋지만 같이 고민할 거리를 기록하는 페이지가 따로 있으면 좋겠다
→ 깃허브 이슈와 팀 노션 페이지 내 “같이 고민해봐요^^” 페이지 개설
2024.01.09
1.
프론트
a.
Vue
b.
바닐라JS
2.
할 일 정리
a.
전체
i.
흘러가는 구조 정리
ii.
전체적인 노션 정리
1.
특히 코드 컨벤션 정리
a.
예를 들면 1기능 1커밋?
iii.
API 수정
1.
response 성공 메시지 필요 없다
2.
비고에 상태코드가 바뀌는 것만 작성 ← 에러는 그대로 유지
3.
있는 API 고치는게 아니라 Request, Response 유의해서 누락된 기능 없나 확인!
b.
시원님 - 알림 연구
i.
프론트에서 갱신하는 방식을 생각하고 적용하겠다!
ii.
기간 . . 전혀 모르겠다 → 일단 목요일(10일)까지!
c.
다은님 - 파티 CRUD 완성
i.
내일(수)까지 완성!
d.
은채님 - 소셜 로그인
i.
내일(수)까지 완성!
ii.
목(10)까지 완성!
e.
대영님 - 하이브 CRUD 완성
i.
내일(수)까지 완성
2024.01.10
a.
API 대청소
i.
실패 케이스 추가
ii.
response, request 유의
iii.
우선도 설정
b.
할 일 정리
i.
은채님
1.
AWS 강의
2.
CI/CD 강의
3.
CI/CD 시작,,,?
ii.
다은님
1.
파티 가입
2.
파티 탈퇴
iii.
동하님
1.
채팅 완성
2.
개발 환경 정리 → 선택 이유……
3.
CI/CD 찍먹
iv.
대영님
1.
하이브 작업자 초대
v.
시원님
1.
알림 기능 완성
2.
백엔드 설계확인
프론트, 백엔드 MVP, CI/CD 이렇게 있는데 분업을 잘 해보자
프론트나 CI/CD는 모두 다 같이 경험해보는 것도 좋겠지만 우리에겐 시간이 부족하다.
동하 - CI/CD와 프론트 총괄
시원 - 백엔드 총괄
은채 - CI/CD 대표주자
대영 - 프론트 대표주자
다은 - 백엔드 대표주자
이제 프론트 라이브러리는 프론트 사람들끼리 알아서 정하자 타임리프든 js든 리액트는 vue.js든
→ react에 모노리식 아키텍처를 적용하기로 일단 결정
2024.01.23
Q: 권한 검사같은건 프론트에서 어떻게,,?
A: 질문ㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱ
2024.01.25
•
프론트에서 구현해야할 기능
1.
하이브 생성 기능 - 필수
2.
가입 중복? - 부가
3.
하이브 조회 / 이름, 카테고리 별로 조회했을때 나오도록
4.
파티 생성, 가입, 탈퇴 / 우측 게시판에 이전 파티목록 조회
5.
하이브내에 파티조회하는 검색창 구현
6.
유저 프로필에 카테고리 선택 기능
7.
하이브 가입 시 왼쪽에 하이브 리스트, 우측에 하이브 지도 → 먼저
a.
마커는 부가기능으로…..
