📃구현 CheckList!!
- 유저이름 입력 기능
- 메시지 입력
- 메시지 삭제
- 답글 달기
| 유저네임 입력/ 대화창 메시지 표시 | 메시지 입력 |
|---|---|
 |  |
| 메시지 답장 | 메시지 삭제 |
 |  |
📖회고 내용
Swit으로 협업하기
지금까지 3번의 과제를 진행하면서 가장 많이 했던 말이 우리 이제 뭐 남았죠?였다. 그래서 나는 팀원들과 협업을 위해 TodoList를 적용하자고 제안했다. TodoList의 장점은 우리가 무슨 일을 하고 있는지 확인하고 공유하는 점이다. 단점으로는 일정을 동기화하지 않는다면 무용지물이다.
효율적으로 개발시간을 관리하기 위해 “뭐 남았죠” 시간을 줄인다면 TodoList는 성공했다고 생각한다. 그래서 Swit의 ProjectBox를 활용해서 나의 일정이나 팀원들의 일정을 공유하며 이번 협업에서 “뭐 남았죠” 시간을 줄이게 됐다.
디렉터리 구조 개편
과제를 하면서 잘 지켜지지 않았던 부분이 디렉터리였다. 그래서 과제 킥오프 때 모두가 디렉터리 구조를 다시 인지하는 것이 필요하다고 생각했다. 다들 익숙한 방식이 있고 작업을 하면서 정신없기에 시작 전에 다시 한번 리마인드했다. 그리고 이번에는 나도 정한 방식에 맞춰 진행하려고 커밋을 하기 전에 한 번 더 확인하여 작업을 수행했다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 이전 components 디렉토리
+---atoms
|
+---containers
|
+---domains
|
\---filter //domains로 들어가야됨
// 이후 components 디렉토리
+---BackButton
| index.tsx
| styled.ts
| types.ts
... components...
|
\---shared //공통 컴포넌트
+---CategoryItem
|
+---CategoryList
|
\---ConItem
이번에 디렉터리 구조는 컴포넌트 단위로 나누고 컴포넌트 내에 index.tsx(컴포넌트 함수), types.ts(현재 컴포넌트에서 사용하는 타입), styled.ts(컴포넌트에서 사용할 style)로 나누어 작업을 하니 통일성도 있었고 디렉터리 구조 파악하기 편했다.
데이터 만들기
과제에서 데이터모델이 예시로만 주어져서 팀원들과 많이 고민했다. 기존의 메시지를 남기는 거는 상관이 없지만, 답글을 작성하게 되면 데이터의 깊이가 1단계가 증가하게 되어 이를 표기해 주는 고민을 했다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 초기에 고민한 데이터 모델
message: {
id: number,
date: string,
user: {
userId: number,
userName: string,
profileImage: string
},
content: string,
isReply: boolean,
}
// 결과
User {
userId?: number,
userName: string,
profileImage: string,
}
ReplyUser extends User {
replyContent: string,
}
Message {
id: number,
date: string,
user: User,
content: string,
replyUser?: ReplyUser,
}
초기에는 답장하는 글인지 아닌지를 확인하기 위한 boolean값의 유무에 따라 답글인지 아닌지를 판별했지만, 이렇게 하면 어떤 사용자가 글을 썼는지 확인할 수 없게 되어 답장한 사용자 객체를 만들어 해결했다.
기존 자바스크립트를 사용했다면 명시적이지 않았을 텐데 타입스크립트를 도입하여 데이터가 어떤 형태인지를 명시해 주면서 과제를 진행하니 팀원들과 의사소통도 잘되고 효울적이었다.
🌝느낀점
팀원들과 협업하면서 처음 정했던 방식이 불편할 수 있고, 지켜지지 않을 수 있다는 것을 경험했다. 그래서 문제 되는 부분이 있다면 제안을 해보는 것이 좋다고 생각했다. 이번에 제안할 팀원들에게 선택지를 준비해서 선택하고 지켰다. 이렇게 팀 문화를 만들어가니 처음 과제했을 때보다 의견 조율이 시간이 단축되고, 효율적이었다. (이전에 1시간 30분씩 대화했지만, 현재는 30분에 회의를 마치고 작업에 들어가니 과제 질이 좋아지는 것을 느꼈다.)
또한 회의를 길게 한번 하는 것보다 짧게 2~3번 하면 좋을 거 같다. 개발하면서 생긴 이슈를 정리해야 되며, 왜 안되는지 파악하려면 시간도 필요하므로 그것을 정리하고 회의에서 말하고 해결하는 게 나에겐 편했다.
과제를 진행할수록 팀원들과 손발이 맞아가는 과정이 너무 뿌듯했다😊