오늘 한 일
Trello 프로그램 팀 프로젝트를 팀원들과 함께 설계함
과제 요구사항
- 필수 구현 기능
- 사용자 관리 기능
- [ ] 로그인 / 회원가입 기능
- [ ] 사용자 정보 수정 및 삭제 기능
- 보드 관리 기능
- [ ] 보드 생성
- [ ] 보드 수정
- 보드 이름
- 배경 색상
- 설명
- [ ] 보드 삭제
- 생성한 사용자만 삭제를 할 수 있습니다.
- [ ] 보드 초대
- 특정 사용자들을 해당 보드에 초대시켜 협업을 할 수 있어야 합니다.
- 컬럼 관리 기능 → 카테고리
- [ ] 컬럼 생성
- 보드 내부에 컬럼을 생성할 수 있어야 합니다.
- 컬럼이란 위 사진에서 Backlog, In Progress와 같은 것을 의미해요.
- [ ] 컬럼 이름 수정
- [ ] 컬럼 삭제
- [ ] 컬럼 순서 이동
- 컬럼 순서는 자유롭게 변경될 수 있어야 합니다.
- e.g. Backlog, In Progress, Done → Backlog, Done, In Progress
- 컬럼 순서는 자유롭게 변경될 수 있어야 합니다.
- [ ] 컬럼 생성
- 카드 관리 기능
- [ ] 카드 생성 → create
- 컬럼 내부에 카드를 생성할 수 있어야 합니다.
- [ ] 카드 수정 → update
- 카드 이름
- 카드 설명
- 카드 색상
- 작업자 할당
- 작업자 변경
- [ ] 카드 삭제 → delete
- [ ] 카드 이동 → update
- 같은 컬럼 내에서 카드의 위치를 변경할 수 있어야 합니다.
- 카드를 다른 컬럼으로 이동할 수 있어야 합니다.
- [ ] 카드 생성 → create
- 카드 상세 기능
- [ ] 댓글 달기
- 협업하는 사람들끼리 카드에 대한 토론이 이루어질 수 있어야 합니다.
- [ ] 날짜 지정
- 카드에 마감일을 설정하고 관리할 수 있어야 합니다.
- [ ] 댓글 달기
- 사용자 관리 기능
ERD
와이어프레임
Api 명세
User | 로그인 | POST | /api/v1/users/signup |
User | 로그아웃 | PUT | /api/v1/users/logout |
User | 회원가입 | POST | /api/v1/users/login |
User | 마이페이지 | GET | /api/v1/users/me |
User | 회원정보 수정 | PUT | /api/v1/users/edit |
User | 회원탈퇴 | DELETE | /api/v1/users/withdraw |
Board | 메인페이지 | GET | /api/v1/boards |
Board | 보드 생성 | POST | /api/v1/boards |
Board | 보드 수정 | PUT | /api/v1/boards/{boardId} |
Board | 보드 삭제 | DELETE | /api/v1/boards/{boardId} |
Column | 컬럼 생성 | POST | /api/v1/column |
Column | 컬럼 이름 수정 | PUT | /api/v1/column/{columnId} |
Column | 컬럼 삭제 | DELETE | /api/v1/column/{columnId} |
Column | 컬럼 순서 이동 | PUT | /api/v1/column/{columnId} |
Card | 카드 단일 조회 | GET | /api/v1/cards/{cardId} |
Card | 보드 안에서 카드 전체 조회 | GET | /api/v1/boards/{boardId} |
Card | 카드 생성 | POST | /api/v1/boards/{boardId}/cards |
Card | 카드 내용 수정 | PUT | /api/v1/cards/{cardId} |
Card | 카드 칼럼 이동(왼쪽 오른쪽) | PUT | /api/v1/columns/{columnId}/cards/{cardId} |
Card | 카드 순서 변경(위 아래) | PUT | /api/v1/columns/{columnId}/cards/{cardId} |
Card | 카드 삭제 | DELETE | /api/v1/cards/{cardId} |
Card | 카드 작업자 추가 | POST | /api/v1/cards/{cardId}/worker |
Card | 카드 작업자 삭제 | DELETE | /api/v1/cards/{cardId}/worker |
CheckList | 체크리스트 생성 | POST | /api/v1/cards/{cardId}/checklist |
CheckList | 체크리스트 수정 | PUT | /api/v1/cards/{cardId}/checklist |
CheckList | 체크리스트 삭제 | DELETE | /api/v1/cards/{cardId}/checklist |
CheckList | 체크리스트 완료/취소 | PUT | /api/v1/cards/{cardId}/checklist/check |
File | 첨부파일 생성 | POST | /api/v1/cards/{cardId} |
File | 첨부파일 수정 | PUT | /api/v1/cards/{cardId} |
File | 첨부파일 삭제 | DELETE | /api/v1/cards/{cardId} |
Invitation | 보드에 초대 | POST | /api/v1/boards/{boardId}/invitations/{userId} |
Invitation | 초대 목록 조회 | GET | /api/v1/invitations |
Invitation | 초대 거절 | PUT | /api/v1/invitations/{invitationId} |
Invitation | 초대 수락 | PUT | /api/v1/invitations/{invitationId} |
Comment | 댓글 작성 | POST | /api/v1/cards/{cardId}/comments |
Comment | 댓글 수정 | PUT | /api/v1/comments/{commentId} |
Comment | 댓글 삭제 | DELETE | /api/v1/comments/{commentId} |
Event | 이벤트 조회 | GET | /api/v1/events |
설계하면서 팀원들과 얘기하는데 생각해볼 점이 좀 있었다
보드에 사용자를 초대하는 기능을 빠트렸다는것을 깨닫고 ERD를 수정하러 갔다
원래 사용자_보드 에 역할 필드로 보드 생성자인지/사용자인지를 구분하고 있었음(생성자만 보드를 삭제할 수 있음)
1. 사용자_보드에 역할 말고 상태 필드를 추가해서 대기자를 구분함
2. 보드 초대 테이블을 따로 빼봄
3. 필드가 상당히 유사하니까 사용자 보드의 역할 필드에 대기자를 추가해봄
기능에 따라 테이블을 다 분리하는게 좋은지 공통된 필드가 있다면 합치는게 좋은지도 고민해봤다
역할이 대기자인 사용자가 다 보드 초대 테이블로 빠지면 돼서 저장공간은 둘이 똑같은데
역할을 대기자에서 참여자로 바꾸는게 보드초대테이블에서 엔티티를 삭제하고 참여자 엔티티를 사용자_보드 테이블에 만드는게 로직이 더 복잡하고 시간이 오래 걸릴 거 같았다
그리고 유지보수도 생각해보면 초대 테이블에 필드가 추가되어야 한다면 분리되어있는게 나중에 기능확장/변경시에 훨씬 수정사항과 영향을 미치는 범위가 줄어들 거 같긴 했다
하지만 이번 프로젝트에서는 그냥 테이블을 하나만 쓰기로 했다
드래그해서 카드의 순서를 바꾸는 기능이 있는데
그걸 어떻게 구현할지도 고민해봄
처음에는 카드에다가 sequence라는 필드를 넣고 그거에 순서를 줘서 정렬하게 하는 방법을 생각했다
카드가 이동한다면 sequence필드의 값을 변경해준다
근데 이동이 일어날때 카드가 3개의 카드를 제친다면 그 사이에 있는 카드들의 sequence를 모두 변경해줘야 한다 ㅋㅋ...
카드 삭제시에도 sequence 1씩 다 줄여줘야 하는 등의 문제점들이 있는 것에까지 생각이 미쳐서
그 후에는 자가참조로 이전노드와 다음노드로 card_id를 가지는 구조를 생각해봄
처음에는 다음노드만 가지게 했었는데 그러면 삽입할 때 가장 마지막에 있는 노드에는 접근이 되지만
출력할때는 가장 이전에 있는 노드부터 출력해야 하는데 역방향으로 접근이 안 된다면 출력을 순서대로 할 수가 없어서
이전 노드도 저장하고 가장 이전에 있는 노드를 찾아서 그거부터 출력하는 방식으로 하기로 했다
근데 또 그러고나니 조회할때마다 저렇게 첫 노드를 찾는것도 좀 비효율적이란 생각을 하게 됐다
이전노드가 null인지 아닌지 더 빨리 찾을 수 있는 방법은 없을까도 고민해봤는데
딱히 방법이 없는 거 같아서 저렇게만 하기로 했다
'개발일지' 카테고리의 다른 글
2023-12-28, Today I Learned (1) | 2023.12.28 |
---|---|
2023-12-27, Today I Learned (0) | 2023.12.27 |
2023-12-21, Today I Learned (1) | 2023.12.21 |
2023-12-18, Today I Leanred (0) | 2023.12.18 |
2023-12-15, Today I Learned (0) | 2023.12.15 |