-
Notifications
You must be signed in to change notification settings - Fork 4
06 ‐ 04 ‐ Team Wiki
perman0519 edited this page Nov 21, 2023
·
4 revisions
- 각 기능을 주관하는 모듈, 모듈의 형태나 로직은 변할 수 있고 수정이 될 수도 있다.
- 하지만 기본적인 형태에 대한 확정은 개발에 있어서 아주 핵심적인 역할을 한다.
- 개발의 확신을 만들어준다. 담당이 된 사람들이 그 설계에 대해 주도권을 쥐는 만큼 개발 과정의 불확실함보단 확실함으로 진행이 가능하다.
- 타인의 개입이 가능해진다. 구조를 다른사람이 알 수 없다면, 피드백, 검토 하는 면에 있어서 개발의 주도권을 가진 당사자의 공개 여부에 따라 진행할 수 밖에 없다. 하지만 확정된 로직이 어느정도 밖에 나와 있다면, 동료들의 적극적인 리뷰와 개입으로 오류를 최소화 할 수 있다.
- 버스팩터(Bus Factor)를 줄여준다. 개발 과정에서 부득불 생기는 문제로 현재 개발자가 개발을 이어가지 못할 때, 인수인계의 준비조차 어려운 상황이라면 이를 통해 단편적으로나마 현재의 코드를 이해하고 개발을 이어갈 수 있다.
- 개발자 스스로 머릿속에서만 정리된 구조가 현실화가 될 수 있는지 점검이 가능하다. 머릿속, 사고적으로 구성된 구조는 모순이나 오류가 많다. 특히 오류가 발생하는 순간이 언제인지 설명하는 순간이 아닌 이상 논리적 오류나, 구성 면에서의 오류는 발견하기 어렵다.
- 위 처럼, 모듈 설계에 대한 문서화는 개발의 핵심 요소이므로, 담당으로 맡은 사람이 구현을 위해 이해하는 것이 중요하다.
- 비즈니스 요구사항
- 모듈의 근본적인 목적, 요구사항 등을 기재하여 요구되는데로 설계가 되었는지를 명확히 한다.
- 아키텍처 설계
- 모듈의 아키텍처 설계의 명확성을 높이고, 담당 개발자가 구체적인 지침으로써 이를 활용할 수 있다.
- API 엔드 포인트 설계
- 필요한 기능을 수행하기 위한 엔드포인트로 프론트엔드 개발자들과의 협업을 개선한다.
- 다른 모듈과 상호작용 포인트
- 의존성 관리에 포함되는 영역이지만, 설계 및 요구사항의 맞춰 기능 구현을 하려고 보면 개발자들끼리의 협의 내지는 논의가 필요할 수 있다. 이를 사전에 논의할 주제로 띄워 놓는 역할을 하며 상호 소통 전에 이를 인지하고 상호 모듈을 고려한 설계를 할 수 있게 만들어 준다.
- 명확성 : 설계 문서는 여러 사람이 봐야 하니, 사용되는 용어나 개념의 명확한 정의를 분명히 해야 한다. 특히 기능정의서 사용된 단어들은 '바꾸지 말고 그대로' 사용할 것! 기획이 바뀌어 용어가 바뀌지 않는 이상 바꾸면 안되며, 기술적 용어들도 가능하면 풀어 쓰거나, 배제하면 좋다.
- 유지보수성 : 문서의 버전관리가 용이한게 중요하다. 본인이 설계한 내용이 변경이 필요할 때는 반드시 기존 내용은 백업을 해두고, 새로운 버전으로 만들어 문서를 관리함이 핵심이다.
- 협업을 고려한 구성 : 해당 문서는 기본적으로 협업을 고려해야 한다. 문장이 깔끔한지, 명확하게 정리가 되어있는지, 상대방이 읽기 쉬운 구조로 짰는지 한번 씩 체크할것!
- 비즈니스 요구사항
- 아키텍처 설계
- API 엔드포인트 설계
- 다른 모듈과 상호작용 포인트
- 팀에 관련된 페이지의 api 설계
- DnD를 통한 팀 페이지 기능시 백엔드에서 필요한 것
- 각 설정별로 필요한 api구현
- 팀관련 3개 페이지의 기능 및 DnD 파트 모듈 설계
- 팀 선택 페이지
- 팀 페이지
- 팀 설정 페이지
- 팀명을 누르면 원하는 팀 페이지로 이동이 가능하다
- 지정한 목표기한, 진행중으로 변경된 날을 기점으로 목표 년-월을 표시
- 모집중 / 진행중 / 종료
- 팀장 / 스탭 / 팀원
- 팀장 / 스탭인 경우 보이는 설정 아이콘
- 팀관련 정보를 요소별로 배열하여 볼 수 있다.
- 팀 관련 설정을 할 수 있다.
-
예시: 동접속자 수 XX 명 가능케 하기??
-
팀페이지에서 동시 수정시에 발생하는 문제 해결하기
- TeamController : HTTP 요청을 처리한다.
- TeamService : 비즈니스 로직 수행
- TeamRepository & TeamUserRepository: 데이터 저장소와 상호작용을 담당한다.
ERD (참고할 것)
- 특정 상황이나 기능 상 발생 가능한 것들이 있다면 자유롭게 적어주세요~
- 모집게시글에서 팀이 확정되면 팀 페이지가 만들어진다
- 팀 페이지 설정 변경시 알람
- 팀별 결산을 할 수 있어야 한다.
- 유저는 모집 게시글을 작성하여 팀을 만들 수 있다
- 유저는 모집 게시글에서 팀에 소속하고 싶다고 ‘지원하기’를 표현할 수 있다
- 모집게시글에서 지원버튼을 클릭한 유저는 답변을 작성하고 제출한다.
- 유저가 제출하면 Applicant List에 저장된다. 이 리스트의 size는 현재 모집게시글의 지원한 사람의 수가 된다.
- 유저는 일정한 사람이 해당 게시글을 지원했다면 유저는 모집자중 인원을 선택하여 팀을 구성할 수 있다.
- 유저가 팀을 구성했다면 모집게시글 상태는 "모집완료"로 자동으로 수정된다. 또한 해당 정보를 바탕으로 팀을 만들 수 있다.
- 유저가 팀을 만들때 작성자를 팀리더로 만들고 그 외 유저들은 정보에 맞게 TeamUser에 넣는다. 또한 유저가 작성했던 모집게시글 정보를 바탕으로 Team을 생성한다. teamMemberStatus는 "확정"으로 한다.
- 모집게시판에 넣었던 정보를 게시글에 담아 "공지사항" 게시판 리스트에 저장한다.
- 그리고 썼던 모집게시판은 숨김처리 (상태가 모집완료인 게시판은 숨김처리)하면 될 것이다.
- 유저는 팀 선택 페이지에서 자신이 소속된 팀의 리스트 목록을 볼 수 있다.
- 유저는 각각의 팀마다 팀이름, 목표 기간, 팀 상태(모집중/진행/종료), 나의 역할, 팀설정가능아이콘을 볼 수 있다.
- 유저는 팀을 선택해 팀 페이지로 넘어갈 수 있다.
- 팀에 소속된 유저는 팀 페이지에 들어올 수 있다.
- 리더 DnD로 팀페이지를 변경할 수 있다.
- 게시판
- 공지 게시판
- text 박스
- image 박스
- 팀의 리더인 유저는 팀 설정 페이지로 들어와 팀 설정을 할 수 있다.
- 팀에 관한 정보를 변경할 수 있다.
- 팀 멤버에 관한 권한을 설정할 수 있다.
- 팀원을 추방할 수 있다.
- 팀에 들어오고 싶은 유저를 팀에 추가할 수 있다.
- 모집인원에 대해서 인터뷰를 볼 수 있다.
- 모집인원에 대해서 팀원으로 추가할 지 거부할 지 결정 할 수 있다.