Table
Search
Github
1. 프로젝트
•
프로젝트 명 : We-Make-Play
•
소개
◦
한 줄 정리 : 함께 운동하고 싶은 인원 모으기
◦
내용 : 인원이 많이 필요한 운동을 하고 싶지만 사람모으기가 어려울 때! 그런 사람끼리 모여 축구, 야구 등 인원을 찾을 수 있습니다.
개발환경
2. 기획(2분)
•
기획
1.
목표: 개개인이 자유롭게 참여할 수 있는 온라인 운동 커뮤니티 구축
2.
주요 기능:
a.
모집 게시글,팀 생성 및 참여:
i.
사용자는 원하는 운동 종목 및 일정의 글을 생성하고, 다른 사용자들은 이에 참여할 수 있음.
ii.
참여한 사용자들은 함께 운동 일정을 계획하고 진행할 수 있음.
b.
유저 팔로우 및 좋아요 기능:
i.
사용자는 다른 사용자와의 활동이 유익했다면 좋아요 및 팔로우를 할 수 있음.
ii.
좋아요 수치는 프로필에서 조회가 가능하여 모집을 할 때 참고할 수 있음.
3.
MVP (Minimum Viable Product):
a.
계정 및 프로필 설정: 사용자는 회원가입시 프로필을 설정할 수 있음. 이는 향후 수정 가능함.
b.
게시글 작성: 사용자는 게시글을 작성하여 해당 게시글에 대한 다른 사용자의 참여를 받을 수 있음.
c.
팀 생성: 사용자는 팀을 생성하여 해당 팀에 다른 사용자의 신청을 받아 수락 및 거절을 할 수 있음.
d.
팔로우 및 좋아요: 사용자가 다른 사용자에게 할 수 있으며, 좋아요의 경우 많이 받은 순서대로 보여주는 게시판이 존재함.
4.
기술 스택:
a.
프론트엔드: bootstrap, thymeleaf
b.
백엔드: springboot
c.
데이터베이스: MySQL
d.
보안 및 인증: JSON Web Token (JWT)
e.
배포 및 CI/CD: Github Action, AWS
•
서비스 아키텍처
(아키텍처 그림)
3. MVP 주요 작업물(1분)
서비스의 핵심이 되는 기능 시연
1.
보드/팀 가입 및 수락
2.
유저 팔로잉, 팔로워 확인 기능
시연 영상
4. 기술적 의사 결정(2분30초)
1.
에러코드 처리 클래스
•
도입 이유:
◦
기능 구현 중 여러 문제가 발생 할 수 있는 상황이 정리가 되어야 함
•
문제 상황:
◦
자바에서 제공하는 IllegalArgumentException 을 사용하여 에러를 처리하면 코드 가독성도 좋지 않고 유지보수성 측면에서도 좋은 방법이 아님
•
해결 방안:
◦
ServiceException 을 사용하여 ErrorCode Enum 클래스에 정리
•
의견 조율:
◦
서로의 의견을 듣고 장단점을 얘기하여 조율을 하도록 노력했습니다.
•
의견 결정:
◦
결정은 지금의 기술 스택과 유지보수성을 판단하여 결정을 하였습니다.
public Board findBoard(Long boardId) { return boardRepository.findById(boardId).orElseThrow( () -> new ServiceException(ErrorCode.NOT_EXIST_BOARD) );}
2.
게시글 및 팀 참여 구현
•
도입 이유:
◦
함께 운동할 인원을 모집하여 해당 인원들과 소통할 수 있는 공간이 필요함
•
문제 상황:
◦
참여 신청 상태를 수락/거절 두 가지로만 분류하니 거절당한 사용자가 신청자 목록에 남아 있게 되어 처리하기 곤란했음
•
해결 방안:
◦
참여 신청 상태에 ‘대기’를 추가하여 신청자 목록을 조회할 때 거절당한 사용자는 나타나지 않도록 했음
5. 추후 개발 및 기술적인 도전 계획(1분30초)
•
MVP에서 개선할 기능과 이에 대한 개발 순서
◦
카카오톡 등의 소셜 로그인 기능
◦
웹소켓을 활용한 채팅 기능 도입
◦
회원가입시 유저 프로필 사진 설정
◦
게시글의 경기장과 지도 API 연동
•
예상되는 개발 난제와 이에 대한 해결 방안
◦
채팅
▪
개발 난제 : 개발 스택과 DB 관리의 문제
▪
해결 방안 :
•
댓글 형식으로 의견을 주고 받을 수 있는 공간 마련
•
가입 승인된 사용자에게 방장이 생성해둔 오픈톡 초대 코드 등 발송하기
6. 튜터님 질문 10항(3분)
1.
ERD 상으로 프로필 사진에 대한 정보를 충분히 저장하지 못할 것으로 보이는데 업데이트된 내용이 있나 재확인 부탁드립니다.
•
업로드할 파일에 대한 정보를 가지는 새로운 클래스를 추가하였습니다.
2.
ERD 중 TB_LIKE에 라이킹ID 컬럼, TB_FOLLOW에 팔로잉ID 컬럼이 의미하는 바가 무엇인가요? (현재 상태로는 table pk와 동일한 개념으로 보이는 듯 합니다.)
•
TB_LIKE
◦
user_id : 좋아요를 누르는 사용자의 id 값
◦
liking_id : 좋아요를 받는 사용자의 id 값
•
TB_FOLLOW
◦
user_id : 팔로우를 누르는 사용자의 id 값 (=following_id)
◦
following_id : 팔로우를 받는 사용자의 id 값 (=follower_id)
3.
채팅메세지를 저장할 때 MySQL VARCHAR를 이용한다면 얼마나 저장할 수 있을까요? 그리고 최대치를 넘어간다면 어떻게 해결할 수 있을까요?
•
VARCHAR의 최대 저장 용량은 65,535 바이트인데 UTF-8문자 인코딩을 사용하는 경우 한 문자당 4바이트가 소요되어 최대 문자 수는 65,535 / 4 = 16,383입니다. 최대치를 넘어갈 경우를 고려하여 4GB 까지 용량이 확장되는 TEXT 타입의 사용을 고려해볼 수 있습니다.
•
또는 MySQL대신 Redis나 Kafka 같은 NOSQL DB를 사용하는 것을 고려해볼 수 있습니다.
4.
API Request 중 시간을 직접 Request에 보내는 API들이 있는데 특별히 의도하신 내용이 있나요?
•
게시글의 경우 운동을 원하는 일자를 Request로 보내주어 일자가 지나면 스케줄러를 통해 해당 게시글이 삭제 되도록 하였습니다.
5.
API 설계 중 admin과 관련된 Context가 도메인하고 일부 섞여있는데 특별히 의도하신건가요? 아니라면 다시 정리 부탁드립니다.
•
이전 프로젝트를 참고 하였는데 수정하도록 하겠습니다.
6.
테스트 코드가 전혀 작성되어 있지 않은데 어떤 계획을 갖고있으신가요?
•
테스트 코드 관련 강의를 참고해서 단위 테스트부터 진행해볼 계획입니다.
7.
일부 중요한 프로퍼티가 github에서 조회되는데 어떻게 개선할 수 있을까요? (실제로 유효한 value인지는 논외로 치겠습니다.)
•
민감 정보가 포함된 파일에 대해서는 gitignore를 활용하여 처리할 예정입니다.
8.
Entity 연관관계를 설정 시 JsonIgnore를 같이 선언한 부분이 여럿 보이는데 어떤 상황에서 왜 필요하셨나요?
•
@ManyToOne의 Fetch 타입을 Lazy로 사용했을 때, 비어있는 객체를 Serialize 하려다 에러가 발생하였습니다. 이를 해결하기 위해 직렬화시 해당 필드를 포함하지 않도록 @JsonIgnore 어노테이션을 사용하였습니다.
9.
Repository를 접근함에도 불구하고 일부 메소드에는 Transactional 처리가 안되어 있는데 특별히 이유가 있나요?
•
단순히 조회만 하여 데이터 값에 변동이 생기지 않는 경우에는 Transactional 처리를 하지 않아도 될것이라 판단했습니다.
10.
Java Exception 종류와 의미에 대해 아는대로 설명해주세요. (ErrorCode.java에 BAD_REQUEST만 잔뜩 작성되어 있어서, 답변에 따라 꼬리질문이 가능한 문항입니다.)
•
HttpStatus에 대한 이해도가 부족하였습니다. 튜터님 질문에 여러가지 상수가 있다는걸 알게되었습니다.
•
차후 에러 상황에 따라 `NOT_FOUND` 등의 Exception으로 수정하려고 합니다.
