07.18 ~ 07.22

😠 훈수 미팅

최종 플젝 이후 느낀점

프로젝트때 이건 챙겼으면 하는 것

• CI/CD
• 무중단 배포

• 부하 테스트

• 코드 리뷰

• 웹 서버, 캐시

• API 문서 자동화

• 기술 선택하는 과정에서 고민을 해봤냐??

• 일관적인 코드를 짜라 ( 5명이 짜도 1사람이 짠 것처럼 )

• 비즈니스쪽으로 정책이 있는 것이 좋다.
• 신고 기능
• 조회수 어뷰징
• 외부에서 for문으로 요청을 보낸다면 어떻게 막을것인가?
• 이미지 저장

해주고 싶은 말

• 자소서에 쓴 내용은 다 알아야 한다.
• 나의 프로젝트는 다 알아야 한다.

• 자신감을 가져라
• 모르겠으면 당당히 말해라

• 현실과 타협할 줄 알아야 한다.
• 조금 준비가 되었다고 생각하면 면접을 봐라

• 매일 스터디 최대한 자주
• 이론 돌리기
• 주제 선정 → 공유 → 피드백
• 정하고 만나서 질문

• 자신감을 가져라

🚀 주제 관련 미팅

• 지금 기능은 거의 CRUD 복붙과 같은 느낌이다.
• 기술게시판과 질문게시판 동일하다.

• 하나의 게시판을 조금 더 딥하게 가져가는 게 좋을 것 같다.

• 지도 써보는 것도 좋다.

• 간단한 채팅은 아니더라도 쪽지 기능
• 단방향 전송
• 채팅과 쪽지의 창
• 서로 주고 받을 수 있도록 하던가?
• 비동기적 쪽지로 보낸다
• API 해결할 수 있다.

• 모집 게시판을 가져갈 거면 복잡도를 올려서 처리해보도록 한다.
• 신청을 한다
• 주최자가 수락 및 거절한다.
• 신청자가 수락 및 거절에 대한 쪽지를 보낸다.
• 혹은 거절 및 수락에 대한 알람을 보내도록 한다.

• 하나의 서비스를 가지고 깊게 파고 들어가라~
• 신고하기
• 신고에 당한 자는 그 안의 정책을 가져갔으면 좋겠다
• ex) 신고당한 자는 한달동안 신청할 수 없다.
• 블랙리스트 등록

• 스터디를 하면서 했던 것들을 기술블로그로 확장할 수 있도록?

• 벌금 정책

• 강퇴 기능
• 쫒겨난 사람은 스터디 지원 및 개설을 못하도록 한다.

• 쪽지, 모집, 지도

• 회의록 생성, 주차별 회의 출석 비율

• 출석 조회

• 내부게시판 같은 기능
• 스터디 내에서 해봐라

총 정리

• 게시판 갯수를 처리한다
• 기술 블로그 하나만 남도록 한다.
• 조회수
• 좋아요

• 모집 서비스에 대한 기능을 강화한다
• 게시판이 아닌 신청으로 수락 및 거절할 수 있도록한다.
• 수락 및 거절에 대한 알람/쪽지가 가도록 한다.
• 출석, 출석 조회

• 지도
• 스터디 장소

• 정책까지도 정하면 좋을듯

• 스트레스 테스트 하면 좋다.

❓ 비동기 질문과 답변 모음

질문

1. 예전부터 질문해왔던 서비스가 서비스를 의존하는 것에 대한 질문입니다!! 만약 예약 도메인쪽에서 User에 대한 객체가 필요할 때 서비스를 통해 받아오게 된다면 User 자체를 넘겨주는 메서드를 구현해야할 것 같은 데 UserService에 User를 넘겨주는 UserProvider라는 인터페이스를 구현하여 넘겨주는 것이 더 좋을 까요?

2. User 객체로 연관관계를 잡는 것이 아닌 userId로만 연관관계를 잡는다고 하면 UserService에게 존재하는 지에 대한 메시지만 보내도 충분할까요?

3. 프로젝트를 시작할때 기능 명세를 쭉 뽑고 객체를 먼저 설계한 후 디비를 설계하시나요? 아니면 반대로 하시나요?

4. 프론트와의 협업을 위해 더미데이터를 넘겨주는 컨트롤러단을 먼저 구현한 뒤 이후 서비스나 도메인을 구현하고 싶은데 이런 식으로도 협업을 진행하나요??

답변

1. UserService에서 직접 User를 넘겨줘도 될 것같은데.. UserProvider엔 어떤게 들어가게 되는거죠?
1. UserProvier는 User 객체 자체를 넘겨주고 UserService는 Dto만 넘겨주는 식으로 될 것 같습니다. 그냥 UserService가 다 책임지고 controller에서 entity -> dto로 변환하는 것이 맞을까요?
2. 좀 더 객체를 쪼갠다면 그렇게 해도 될것 같긴한데.. 저는 controller에서 entity-> dto 변환도 괜찮다고 생각합니다.

2. 넵넵, userId만 필요하면 userId가 유효한지 여부만 체크해도 될것 같아요!

3. 기능명세를 만든 후, 디비를 설계하고, 그걸 바탕으로 객체를 만드는데 어떻게 보면 둘이 거의 동시에 이뤄지는 작업인 것 같아요! 그래서 어떤걸 먼저해도 상관없을것 같습니다.

4. api spec을 미리 정해서 넘겨주고, 그걸로 프론트에서 모킹을 할 수 있도록 하기도 하고, 만약 실 api를 원하면 controller를 먼저 구현할 수 도 있을것 같아요. 보통은 api가 전체 완성되고 프론트에게 제공해주는데 controller를 먼저 제공해주는 것도 하나의 방식인것 같습니다.

5. 추가적으로 MSA에서 User에 대한 정보가 필요하면 API로 통신하는 것으로 아는 데 이때 받는 값은 User 객체 자체인가요 아니면 Dto인가요??
1. 1. MSA로 변환시 하나의 api이기 때문에 (물론 내부적으로 사용할 api를 따로 만들수도 있지만) 언제 어디서 호출될지 모르기 때문에  User객체보다는 Dto로 넘겨줍니다!

질문

답변

질문

답변