-
Notifications
You must be signed in to change notification settings - Fork 7
2022.07.18
Forky edited this page Jul 19, 2022
·
1 revision
마스터: 우정민
- 필즈: 일요일 하루 쉼
- 썬: 이브 생파 후 숙취 이슈, CICD 완료 후 개발 좀 하다가 또 쉬었음
- 나머지: 우디가 봤기 때문에 생략
- BE (개발 중)
- 시작 전 Spring의 흐름과 Layered Architecture를 알려주었다
- Web 요청 → DB 접근까지 Spring에서 어떤 과정을 거치는지
- 밧드가 Controller Test 짜봤는데, FE의 TDD와 유사하다고 느꼈음
- FE
- 명세 정리 후 시작할 예정
- 현재는 한 사람의 상태 변경을 위해 참가자 모두의 리스트가 날아오고, 서버는 해당 목록에서 누가 바뀐 것인지 모르기 때문에 그 것을 판별하는 과정이 필요해보임
- 만약 변경해야 할 사람의 정보만 request body에 담아준다면, 서버 측에서 별도의 판별 없이 바로 update 처리 할 수 있다
-
필즈: 요청이 누락되었을 경우가 있을 수 있어, 현재 영속된 출석 목록 값의 유효성을 체크하는 방법을 고안해야 함
- 그 것을 고안하느니 네트워크 비용을 들여서라도 전체 목록을 받자
-
우디:
그러나서버측은 누락을 걱정할 필요가 없다. 클라이언트 측에서 상태코드를 통해 요청 성패를 판별한 후 원복시키는 방식
-
우디: 서비스 확장 측면에서 장점이 있다
- 지난번 쿤이 제안했던 것 처럼 각자가 직접 출결을 체크하도록 바꾼다고 하면, 변경이 쉽다
- 사용자 마다의 출결 정보를 저장하기 쉬워진다
-
그러나출결 정보 update를 POST/DELETE로 나누면 api가 추가되어야 하지 않을까..?
-
쿤: 직접 목록 받는걸 구현하려고 하니 로직이 너무 길어지더라
- 밧드와 논의 도중, 서버에서 업데이트된 데이터만 응답으로 보내주는게 어떻겠냐는 이야기가 나왔다
- 요청으로는 수정할 사람만, 응답으로는 수정된 출석부 전체를 보내주는 것은 어떨까?
- 서버에 현재 영속된 출석부 상태를 클라이언트 측에서 view로 보여주면 누락에 대한 걱정을 덜 수 있지 않을까
-
우디:
그러나상태코드를 통해 성공했을 때에만 UI상에서 밑으로 내려주면 굳이 응답 body가 필요할까?
-
밧드: 체크하고, 서버에서 응답으로 처리된 후의 출석부 목록을 보여줄 때 까지는 로딩 화면을 띄우고, 서버에서 보내준 목록을 사용자에게 보여준다는 시나리오
-
우디:
그러나optimistic UI는…? 그런 로직은 당연히 추가되어야 하는 것 아닌가-
optimistic UI: 사용자에게는 성공된 것 처럼 긍정적으로 보여준 후, 실패 응답이 돌아온 경우 원복하는 UI (카톡에서 메세지를 일단 전송된 것 처럼 보여준 후에 전송 실패를 알려주듯)
-
-
우디:
BE는 개꿀이다. 그렇게 가자.
FE에서는.. optimistic 구현 힘들지만 그렇게 가자.
- Swipe는 모바일에서는 해볼 수 있겠으나 데스크톱 환경에서는 별로일 것 같다
-
썬 아이디어: 클릭을 하면 해당 사용자 영역 전체가 초록색으로
띵
POST / DELETE가 맞지 않나
-
아스피: 우리는 지각자, 결석자의 데이터를 찾을 일이 더 많을텐데 출석 데이터를 쌓는 것이 맞나
- 지각자 테이블에 데이터를 쌓는다면 출석 → DELETE, 지각 → POST라서 헷갈릴 것 같다
- Attendance Table에 출석 체크한 시간의 timestamp를 저장해두고 추후에 출석 시간 통계를 보여주면 좋을 것 같다
- 일동: 유의미한 데이터이다 끄덕끄덕
- 썬: “아스피님! 평균 7분정도 지각하고 계세요. 오늘은 7분 일찍 출발해볼까요?”
- 우디: 지각/결석을 구분하게 될 것이라 상정한다면, 지금의 서버 마감 시스템도 문제가 있다 (팟칭)
체크된 사람의 아이디와 체크한 시간 받아서 데이터 생성
- 썬: 지각/출석자를 구분해서 긁어오는 게 빡셀듯 하긴 하나, 그건 도메인으로 충분히 가능하다고 생각
column의 boolean 수정
-
필즈: 누가 출석하고 지각했는지 바로 조회해서 파악하는 것이 좋을 것 같다
- 우디: column이 하나 필요할 것 같긴 한게, 추후 데일리 출근 시간이 바뀐다거나.. 하면?
- boolean 해석하는게 헷갈리는 문제라면 지금 그냥 Enum으로 바꾸자
- default는
TARDY, 왔다고 출결 체크하는 순간 client측에서PRESENT를 쏘고, 서버에서는 시간 확인 후 출결 가능한 시간이면 요청 처리 - 결석 개념이 추가되었을 때의 확장성 + 가독성 개선
enum으로 바꾸고, api 수정
- 아스피 & 포키
- 머지된 코드 pull해서 새로 구현한 코드 짜집기
- Argument Resolver 테스트 코드에 반영
- 아스피 & 포키 & 우디
- user 검색 기능 QA 테스트 → 저녁먹고?
- 쿤 & 밧드
- 변경된 출석 제출 명세 반영
- 마저 구현
- 쿤
- (빨리 끝나면) 이메일 중복검사
- 필즈 & 썬 & 프론트
- 프론트 배포
- 썬
- 전체 미팅 조회
BE - 별도 회의
- Spring Data JPA 이관
- DTO rename
- UserResponse → ParticipantResponse
- SearchedResponse → UserResponse
ALL - 이브톡 때
- Issue와 PR이 중복되어 칸반에 올라가는 문제
- 우디가 그러던데 근로에서는 Issue만 Projects 할당한다더라
- 아스피 & 포키
- 유저 검색 기능 PR 제출 완료
- 이후 Argument Resolver mocking 한 번 시도해볼 예정
- 아스피 & 포키 & 우디
- user 검색 기능 QA 테스트 → 저녁먹고
- 쿤 & 밧드
- BE 정상케이스 구현 완료
- 저녁 이후 BE 예외 + FE 구현 할 예정
- 쿤
- 이메일 중복검사 구현 할 예정
- 필즈 & 썬 & 프론트 (배포 TF)
- 필즈 - mysql setup 진행중
- 썬 - BE 서버 배포중
- 우디 - 블로그 글 통해 FE 배포 환경 설정 학습 완료, 하나씩 적용할 예정
- 썬
- 전체 미팅 조회 시작 못함, 오늘은 힘들듯
- 현재 회원 단일 조회 API 없음
- 로그인 후 main page 조회 시 회원 정보에 따라 닉네임 등을 출력할 필요가 있음
- id, email, nickname 달라
-
사실은,단일 회원 정보 GETAPI 필요하다 → BE: 해줄게 (멋짐)
- Label은 빼면 안됨, 자동 배포 빌드가 Label 기준으로 돌아감
- assignee는 자유롭게 활용
Project 할당은 Issue에만
- 로그인을 하면 해당 User가 속한 Meeting 목록 조회
-
썬( ~ 주말) - 출석 가능 시간인지 확인하는 필드 추가 (출석 마감 or 출석 중)
- 3 시간
-
- user 단일 조회 API 만들기 (로그인한 사람 회원 정보)
포키-
/users/me→ token parsing - 이건 me가 맞을 것 같음! 왜냐 → 항상 본인거만 조회할 수 있어야 하기 때문
- DTO renaming하는거만 백엔드끼리 공유되면 바로 시작해서 30분컷 (오늘안)
- 회원 검색 시 로그인한 자신을 목록에서 필터링
-
우디가 5초만에 끝내주기로 함 - BE측에서 FE에게 login된 회원의 id(고유값)을 주고, FE에서 필터링
-
- 커피스택 (option)
- API 명세 회의부터 필요
- 매 날짜마다 개인 지각을 표시하는 테이블이 필요함
- (FE) 로그인한 유저정보 전역 상태관리
-
밧드,우디 - 2시간
-
- 내일 밧드 예비군
- 완료되는 대로 기능 QA 빨리 진행해서 데모 발표 준비하자
- 내일 모닝톡때 기능 개발 진행 상황 공유
- 내일중 BE끼리 회의 필요
- 늦어도 수요일 3~4까지는 발표 관련 논의 끝내자
token secret key github에 올라가버렸다
- 근데 어차피 장바구니꺼 긁은거라 새로 만들어야됨~~ (휴다행)
새로 만들면 그거는 절대 github에 push하지 말기 약속~~