1. 오늘 학습한 내용
1.1. 뉴스피드 팀 프로젝트
1.1.1. 팀 프로젝트 진행을 위해 미리 설정하면 좋은 Github 기능들
프로젝트를 진행할 때 온전히 미리 설정해두면 프로젝트를 진행하는데 도움이 되는 Github 요소들을 많이 챙기지는 못했습니다. 그래서 다음에 프로젝트를 한다면, 적용해보기 위해 간단히 정리해보려고 합니다. 별도의 협업 도구들을 사용할수도 있지만, 협업 도구들이 구성되어 있지 않거나 경험이 없는 경우 별다른 설정 없이 바로 이용할 수 있는 장점이 있습니다.
- .gitignore
- 프로젝트 생성 후 버전 관리에 불필요한 요소들을 의논하여 미리 제거한다.
- 브랜치 보호 규칙
- 여러 가지 보호 규칙을 이용해서 통합을 위한 branch에 직접 push를 막거나, PR 시 최소 review 승인 횟수 등을 지정할 수 있다.
- Issue 템플릿
- 이슈 종류에 따라 사용될 템플릿을 미리 저장해놓을 수 있다. 템플릿을 통해 간편하면서도 표준화된 내용으로 의사소통할 수 있다.
- PR 템플릿
- PR 역시 미리 템플릿을 작성할 수 있다. 코드 리뷰시 필요한 내용들을 지정해둘 수도 있기 때문에 역시 표준화된 내용으로 의사소통할 수 있도록 도와준다.
- 마일스톤
- 목표를 만들어두고 이슈들을 등록하여, 목표 대비 진행률을 확인해볼 수 있다.
- 위키
- 별도의 도구를 사용할 수도 있지만, Github에서 제공하는 Wiki를 통해서도 컨벤션, 회의록, 참고 자료 등 공동으로 관리하면서 사용할 자료를 저장할 수 있다.
- 프로젝트
- 이슈를 칸반보드를 이용해서 관리하여, 프로젝트 진행률을 짐작해볼 수 있다.
다른 것들도 계속 생기면 지속적으로 추가해보려고 합니다.
1.1.2. 다른 도메인의 개발자와 협업 간 느낀 점
두 기능 모두 단일키로 구현하니 거의 유사한 구조를 갖고 있었습니다. 다만, 혼자 개발하는 것이 아니라 도메인별로 나눠서 개발하다 보니 다른 도메인과의 상호 작용을 어떻게 해야할지 고민이 있었습니다. 저는 Profile과 Post 도메인과 상호작용이 필요했습니다.
다만, 각 도메인의 캡슐화를 최대한 지키기 위해서 서로 다른 도메인끼리는 최대한 서비스 계층의 메서드와 dto를 통해 상호 작용을 하기로 했습니다. 그래서, 필요한 것들이 있다면 서비스 레벨의 필요한 메서드를 개발하기 위해 다른 팀원에게 요청해야 했습니다.
이 과정에서 의사소통의 방식과 규칙을 명확히 규정하는 것이 필수적이라고 느꼈습니다. 다른 팀원분이 서비스에 대한 인터페이스를 이용하여 필요한 메소드 구현을 요청했는데, 좋은 방법이라는 생각이 들었습니다. 이렇게 하면, 코드상에서도 다른 서비스의 구현체가 아니라 인터페이스를 이용해 의존성을 주입받을 수 있습니다. 다만, 이러한 방법의 목적과 의미를 먼저 설명해주고, 요청할 메소드의 명세에 대해 서로 간의 명확한 이해와 합의하는 과정이 필요할 것 같습니다.
따라서 결국 협업이란, 각 도메인의 경계를 명확히 설정하고 서로의 역할을 존중하는 것에서 시작되는 것 같습니다. 존중이라는 것이 무조건 배려를 뜻하는 것은 아닙니다. 필요한 기능은 주저 없이 요청하되, 그 요청이 동료의 시간을 낭비하지 않도록 명확한 명세를 제공해야 합니다. 반대로, 개발 편의를 위해 요청을 주저하거나 본래의 생각을 버리면서 개발에 대해 타협하는 것은 장기적으로 프로젝트 전체의 품질에 안 좋은 영향을 끼칠 수 있다는 생각을 했습니다. 이 점을 가장 주의하면서, 잘 요청하고 잘 알아듣고, 마지막으로 잘 개발할 수 있도록 노력하려고 합니다.
2. 더 알아볼 내용 / 다음에 할 내용
- 특정 사용자의 팔로잉 목록 API 구현
- 프로젝트 통합 및 테스트