정말 오랜만에 쓰는 글이다.
그동안 있었던 스터디에 대해서 글을 쓸까한다.
시퀀스 다이어그램은 보통 프로젝트를 설계할 때 필수적으로 작성하는 다이어그램 중 하나이다.
굳이 이것을 하나하나 작성을 해야할까? 라는 의문이 들었다..
위와 같은 의문을 가지고 시퀀스 다이어그램을 팀원들이랑 다같이 그리기 시작했다. 시퀀스 다이어그램을 학부생 때, 살짝 그린게 끝이라서 잘 기억이 안났다. 팀원들 또한 마찬가지였다. 그래서 구글링을 통해 다같이 공부를 하고 시퀀스 다이어그램을 그렸다.
그리하여 나온 시퀀스 다이어그램은 다음과 같다.
시퀀스 다이어그램을 그려나가면서 의문은 사라졌다. 팀원 간에 모호한 개념과 기능단위 시퀀스를 더 상세히 이야기할 수 있었고, 정의할 수 있었다.
DB 스키마 부분은 백엔드 2명이서 진행을 하였다. 이전에 썼던 글을 참고해나가면서 DB 네이밍 규칙을 지키려고 노력했다. 네이밍 글
좋은 글들을 찾아가며 하나씩 차근차근 이야기하며 설계를 해나갔고, 그렇게 완성한 내용은 다음과 같다.
구현을 하면서 많은 내용이 바뀔 것이다.
솔직히 말해서 API 명세서를 작성하기 위해 모든 작업을 해왔던 것 같다.
API 명세서를 작성해보니 좀 더 확실하게 와닿았다.
먼저 http 통신을 하게 되는 모든 request, response 과정을 나누었다.
그리고 해당하는 요청과 응답을 모두 명세하였다.
Git을 시작하면서 많은 어려움이 있었다. 무엇보다 팀원 4명 모두 Git을 협업을 위하여 사용한 적이 없기 때문이었다. 그래서 공부를 좀 많이했다.. 그리고 공유했다.
Git Flow를 브랜치 전략으로 잡고 시작했다. 브랜치에 대한 공부를 설명해드리고, 좋은 자료같은 것을 공유하면서 Git Flow를 익혔다.
feature명은 다음과 같이 약속했다.
feature/"position"/"name"/기능 이름
Git Issue는 구현하면서 Issue라 할만한 것은 모두 쓰기로 약속했다. 현재는 초기 단계라서 자신의 Issue를 자신이 쓸 것으로 예상이 된다.
구현하다 보면 상대방 Issue를 쓰게 되겠지!
또한 Git Issue 템플릿도 생성했다. 템플릿 내용은 "제목","이슈에 대한 설명" 으로 이루어져있다.
풀리퀘가 가장 힘들었다. 나 또한 명확히 개념이 잡혀있지 않고, 우리가 생각하는대로 동작하지않았고, 동작했는지도 제대로 파악하기 어려웠다.
기능단위로 매일매일 구현을 하고 develop으로 풀리퀘를 보내기로 했다.
모든 내용을 문서로 명세하고 하기에는 시간이 너무 걸린다. 그래서 회원 도메인만 먼저 시작하기로 했다. 회원 도메인은 다음과 같다.
다음 게시글 부터는 구현부분을 올릴 예정이다.