01.09 10:00 박성원튜터님 두두등쟝
JavaScript
복사
10:13
튜터님 : 업무 분담을 어떻게 하였는가
→ TASK 참고
10:15
Https 적용은 어떻게 할 것인가.
→ 어디에 적용할 지를 생각해볼 것
10:17
redis 같은 DB를 사용할 것인가
→ 속도를 보고 사용할 것. MYSQL을 먼저 사용하겠습니다.
튜터님 : 아직 기술 관련해서는 크게 정해진 게 없군요.
10:19
팀 인바이트랑 유저팀 인바이트를 나눈 의미가 있나요?
→ 인바이트 이력관리를 위해 빼긴 했습니다.
튜터님 : 없다면 합치는 것은 어떨까요?
주환 : 거절했을 때는 생성이 안되고, 수락 시 생성인가요?
튜터님 : 역할이랑 수락 여부, 거절 날짜, 생성, 수정만 가지고 가도 전부 가지고 갈 수 있지 않을까요? 수락 여부도 컬럼상태로 넣어놔도 불리언 상태라 부담은 없을 거 같습니다. 같은 목적을 가지고 있어보여서 합치는 게 좋지 않을까요?
지선 : 데이터가 쌓이게 되는데..
튜터님 : 5번을 초대를 보냈다는 것은 의미가 없다고 보고, 업데이트로 하되, 로그를 쌓는 것을 추천드립니다.
10: 21
튜터님 : 상신님이 포인트와 스코어를 가져오신 거 같은데, 유저 퀴즈 맵핑 테이블로 가져가는 게 좋다고 보는데,
지선 : 사용하는 경우가 있습니다. 스코어는 랭킹, 포인트는 돈 같은 개념이라서..
API를 봤을 때 팀 단위 스코어가 나오던데 이건 뭘까요?
지선 : 팀 단위 스코어를 보기 위해..
튜터님 : 리더보드 산출 기준인가요? 스코어라는 게 애매하게 보이긴 합니다. 유저 팀 맵핑 테이블에 녹이는 게 나아보이는데,
유저 퀴즈 쪽에 녹이는 것도 좋아보입니다. 나눠놓은 이유가 있다면 좋을 거 같아요.
팀 내 경쟁이라면 유저-팀 쪽에 넣는 게 나아보이고..
주환 : 유저 퀴즈 쪽으로 넣는게 어떨까요?
지선 : 퀴즈를 오늘 몇 개 풀었냐, 첫 문제냐에 따라 스코어가 결정되니까 맞는 거 같아요.
주환 : 소속 된 랭킹을 보여주거나 팀 간 총 스코어를 가지고 싶어서 개인이 가지는 스코어이기에, 유저 퀴즈에 녹이는 게 맞는 거 같습니다.
10:25
튜터님 : 스킬이 퀴즈랑 연관이 되어있는 건가요? 아니면 뭘까요?
주환 : 문제 카테고리랑 기술 스택간 차이가 있을 수 있습니다. 퀴즈 카테고리와 기술스택(스킬)
튜터님 : 이넘으로 관리하던데 유저가 관리를 할 수 있을까요?
지선 : 선택만 가능합니다.
튜터님 : 퀴즈의 카테고리도 따로 따고, 유저스킬과 맵핑을 하는 게 좋지 않을까요? 이넘으로 만들면 코드 수정을 하지 않는 이상 변경이 안되는데, 말씀을 들어보면 자주 바뀌어야 되는 컬럼인 거 같은데..
지선 : 개인적인 경험인데, Spring과 spring, SPRING 등 중복이 많던데, 이름이 명확하게 잡혀있더라도 무작위로 사용자들이 넣었을 때 단점으로는 피곤하지 않을까 생각해서 고려하지 않은 거 같습니다.
튜터님 : 이 스킬들과 퀴즈 카테고리 자체는 유기적으로 늘어난다고 생각하는데, 운영자 입장에서는 이걸 넣고 빼고 하는게 좋다고 보는데, 이걸 개발자가 해야된다는 게 문제인 거 같습니다. 운영자가 있어도 개발자가 해줘야 된다고 보는데, 이걸 권한 처리를 하고 맵핑을 하는게 좋아보입니다.
→ 운영자 권한에서 처리하는 것과 개발자가 재배포하는 것은 다르니, 참고하기
ERD 이야기 끝. 10:32
10:32
API 작성에 관하여
튜터님 : 초대 수락을 패치로 받으시던데 왜인가요?
지선 : 수락 날짜, 거절 날짜가 바뀌는데 결국에는 안에 테이블에 일부만 바뀌기에 패치로 작성하기로 했습니다.
튜터님 : ERD기준으로 보면 인비테이션을 바꾸고 유저팀에 크리에이트가 들어가야 된다고 봤는데 맞나요?
지선 : 맞습니다.
튜터님 : 패치로 진행을 해도 되는데, 액셉트랑 리젝트를 받는 것 보다 API를 하나로 해서 받는 게 낫지않나봅니다. 그게 아니라면 포스트 딜리트가 낫지 않나 봅니다. 1:1 맵핑으로 역등성이 보장되면 PUT을 사용하고, 유저가 무언가 행동을 했다 등 역등성이 보장되지 않기에 url쪽에서 의도를 표현하기보다 바디에서 표현하는 쪽이 좋다고 봅니다.
지선 : url딴에서 accept 등으로 나누는 건 괜찮은가요? 나눈 것과 안 나눈 것 중 무얼 선호하시나요?
튜터님 : 저는 나눈 걸 추천합니다. 역등성이 보장되기 떄문에.
10:36
지선 : 좋아요의 경우 나누는 게 낫나요?
튜터님 : 저는 나누는 걸 선호합니다. 저는 역등성을 중요하게 보기 떄문에 UI상에서 딱 딱 버튼이 바뀌고 하는 걸 선호합니다. 저는 패치를 선호하지 않아요.
지선 : 패치는 내용 수정에만 사용하시나요?
튜터님 : 넹.
10:40
질문타임
01:09 회의록 관련해서
지선 ; 테이블을 복수명으로 했는데, 중간 테이블만은 복수명으로 안해도 될까요? 복수명을 권장을 하는 건지 어렵습니다.
튜터님 : 상관 안해도 괜찮다고 봅니다. 회사 내규가 다 다르기 때문에 우리끼리의 약속이지 요새는 이게 좋네 이런 건 의미가 없다고 봅니다.
지선 : 피드백을 받은 적이 있어서 권장인지 선호인지를 모르겠어요.
튜터님 : 저는 복수명으로 한다면 url쪽만 하는 편입니다. 전체 개시, 아이디 개시 등 url에는 복수형이 낫다고 하는데, onetomany 등 리스크 뒤에 보여주기 떄문에 테이블에는 복수명을 굳이 써야 되나 싶습니다. 테이블에 복수명을 쓰면 변수명도 이상하게 써야 되어서 선호하지 않아요.
지선 : 예약어 같은 경우 복수여야 들어가고 해서..
튜터님 :맞아용
지선 : 서비스에서 메소드를 가져오거나 레포에서 가져오거나 하는 경우 어떤 게 좋은가요?
튜터님 : 서비스간의 계층 관계를 볼 수 있기 때문에 서비스에서 메소드를 가져오는 게 좋습니다.
개념적으로 볼 때 유저에서 포인트를 가지고 온다고 가정할 때, 더 중요한 건 뭘까요?
유저에서 포인트 서비스를 써야될까요? 포인트에서 유저 서비스를 가져와야할까요?
일대다 의 경우 다 쪽을 사용하게 되는데 서비스 간에 순환 충돌이 나는데 다른 도메인의 레포는 사용하면 안댕
코어 서비스를 만들어서 서비스 간 계층관계를 보는 걸 만들기도 합니다. 특정 서비스를 합친 새로운 도메인이 나오기도 합니다.
코어서비스(어플리케이션 서비스)
→ 서비스 간의 관계도 설명하면 좋습니다.
지선 : 서비스의 아래단에 같이 쓸 수 있는 메소드를 만들기도 했었는데, 새 클래스에 다 같이 쓰는 걸 묶어놓는 것도 좋은가요?
튜터님 : 괜찮은 구성은 아니긴 합니다. 서비스 단에 넣어두는 게 낫다고 봅니다.
지선 : 이유가 있을까요?
튜터님 : 이유라기보다는 코드의 파편화를 할 거면 인터페이스를 보고 가져가라고 할 것 같습니다. impl
어쨋든 개발자들은 리펙토링이 숙명이기 때문에, 개발을 하다보면 중복코드가 생기기 마련인데 보일 때마다 리펙토링 해주는 것이 낫다고 봅니다.
코드 리뷰 때 서로 합의하는 게 어떨까요?
지선 : 네넹띰 . 요청하겠습니다.
튜터님 : 함수명에 모든 의도를 담아주는 게 팁입니다. 보드 개발 시에 코멘트까지 가져오거나 좋아요까지 가져오게 되면 펑션을 만들게 될텐데… 의도 파악, 범위 파악, 역할 등을 펑션명으로 올려주시는 게 좋을 겁니다.
10:53 종료.
