| -- | -- |
|---|---|
| 팀 인원 | 3 |
| 사용 언어 | Kotlin |
| 프레임 워크 | Spring Boot 3.2.1 |
| 기한 | 1월8일 - 1월12일 |
| IDE | IntelliJ |
| DB | Postgresql 15 |
이번 주는 팀 프로젝트를 시작하게 되어 협업 과정에서 팀장을 하게 되었고 프로젝트 설계를 먼저 진행하게 되었는데 그 과정에서 있었던 일에 대해 말해보려 한다.
프로젝트 구조
우선 DDD 구조를 가지고 가도록 하였는데 왜 이것을 채택하였는가에 대해 말해보려 한다.
- 협업에 좋은 구조라고 판단되어서.
어째서 협업에 좋은 구조라 판단하였는가에 대해 이야기를 하자면 우선, 각자 Domain Service와 Repository를 작업한 후, Application Service에서 논의를 통하여 개발을 진행할 수 있다고 판단되었기 때문이다.
- 같은 계층에 대한 참조가 필요한 상황일 경우 순환참조를 일으키지 않기 위해서.
사실 이전 개인 프로젝트의 경우 Controller단에서 처리해주는 형태를 가졌는데 좋지 않다고 판단되었기 때문이다.
설계 진행
사실 이 과정에서 큰 실수를 범하였다.
ERD와 API 명세서 설계 단계부터 개별적으로 구현을 하도록 이야기를 하였다.
이렇게 진행할 경우 결국 table구조를 각자 잡고 추가 리펙토링 작업이 또 들어가고 또 논의를 거쳐야 하는 매우 번거러운 작업이 진행 되었고, 나의 경우 Comment단에서 연관관계를 짓지 않아 데이터의 정합성과 일관성이 틀어지는 형태를 만들게 되었다.
실제 이 부분으로 인하여 오늘 하루를 회의를 하는데 소비하였다.
나의 경우 매번 개인 프로젝트를 진행하다 보니 나에게 편하고 효율 좋은 구조를 만들고 하는 스타일이였기에 논의를 통하여 정하는 부분에서 내가 생각치 못하는 부분을 짚어주어 더욱 좋은 구조에 다가설 수 있다는 것이 아주 좋게 다가왔다.
우선 API명세서를 각자 작성한 후 ERD를 만드는 순서로 진행하였다.
프로젝트의 목적
나는 개인적으로 이 과제에서 얻고자 하는 것은 개인의 학습능력 향상과 경험이라 판단하여 프로젝트의 여러 기능 구현보다도 여러 에러를 만나고, 추가 요구사항에 대한 리펙토링과 협업에 대한 경험을 쌓고자 하여 기능 구현보다도 경험에 중점을 두고 진행하기로 건의하였고, 그것을 받아들여 주었다.
그리하여 우선 정했던 것은 Git의 Branch 전략과 Commit전략에 대하여 이야기를 하였다.
우선 코드리뷰를 통하여 Branch 전략에 대하여 피드백을 받았던 경험을 통하여 그 전략을 여기에 녹여내기로 결정하였고, Commit전략의 경우 내가 사용하던 전략을 가지고 가기로 결정하였다.
Branch의 경우 GitHubFlow 전략을 따르기로 하였고, Commit의 경우 대문자로 어떤 작업을 하였는지 적고, 그 뒤는 내용에 대해 적는 방식을 사용하기로 하였다.
이 Commit방식은 예전에 본 글에서 알게된 방식인데 이름에 대하여 알게 된다면 수정하도록 한다.
기술 공유, 에러사항 공유, 코드 피드백
그리고 위 3가지를 중점으로 회의를 진행하게 될 것 같다.
또한 필수 구현사항에서도 생각이 들어간 코드가 좋을 것 같아 코드 피드백을 통하여 어떤 생각을 가지고 설계를 하였는가에 질문을 던져볼 예정이다.
다행히도 내일 부터는 코드 작업에 들어갈 수 있을 것 같아서 참 다행이라고 생각한다.
내일 작업 예정 사항
README 작성
