진행중인 프로젝트는 여기서 확인하실 수 있습니다.😊
프로젝트를 진행하기에 앞서, 어떤 형태로 기능을 분할할 것이고 어떻게 할일들을 관리할지를 먼저 정하고 싶었다. 혼자하는 프로젝트이지만 프로젝트의 목적이 만들어보고 싶은 것을 학습하는 것과 현업과 비슷한 형태로 할일 관리였기 때문에, 어떤 방식으로 프로젝트를 진행할 지 작성할 예정입니다.
전체적인 프로세스
전체적인 프로젝트는 위의 그림과 같습니다. 부가적으로 설명을 붙이자면 해야 하는 일에 대해서 작업 단위를 분할하여 이슈로 등록합니다. 이후 이슈에서 분할되는 작은 작업 단위들을 추가 이슈로 분할하고, 이를 수행합니다. 수행이 완료되면 Pull request 이후 코드를 Develop 브랜치에 Merge 시키는 방식으로 진행됩니다. Pull request가 닫히면 이슈가 닫히고 작은 이슈들이 모두 해결되면 하나의 큰 이슈를 닫는 형태입니다.
이러한 방법에서 두가지 의문이 들 수 있을 것 같습니다. 그에 대한 답은 질문 아래에 작성했습니다.
- 혼자서 개발하는데 왜
Pull Request를 사용하지?- 현재는 혼자서 개발하고 있지만 구성원이 추가되거나, 누군가가 제가 짠 코드를 보려고 할 때 각 이슈에 해당하는 PR을 함께 확인할 수 있으면 좋겠다 라고 생각했습니다. 궁금한 부분이 모두 다르기 때문에 이슈를 보고 어떤 식으로 코드를 작성 했는지에 대해 궁금증이 드는 부분만 바로 링크로 연결될 수 있도록 하고 싶었습니다.
- 링크만 추가하는 방법도 있겠지만 풀리퀘스트를 보내는 방식이 번거롭지도 않으며 스스로 코드를 한 번 점검할 수 있는 시간이 될 것 같았습니다.
- Issue가 그렇게 많지도 않을텐데 왜 큰 Issue와 작은 Issue를 분할하지?
- Peloton 이라는 팀 프로젝트를 진행하면서 이슈가 너무 많아져 이슈간의 관계가 불명확해지는 문제가 있었습니다. 이러한 문제를 해결하고자 이슈끼리의 관계를 명확하게 할 수 있도록 설정하고 싶었습니다.
- 뿐만 아니라 프로젝트의 진행상황을 명확하게 보고자 도메인별로 진행사항을 기록하는 것이 좋을 것 같았습니다.
이슈
- 큰 단위의 이슈 및 할일을 먼저 작성한다.
- 큰 이슈에서 분리되는 작은 할일 목록을 다시 세부 항목으로 분리한다.
- 예시
- [회원] 회원과 관련된 인증을 처리한다. - 큰 이슈
- [회원 인증 관리] Interceptor 및 argumentResolver 등록 - 작은 이슈
- [회원 인증 관리] Jwt 토큰을 활용한 token 방식 구현 - 작은 이슈
- 예시
- 세부 항목들을 수행하고 세부 항목이 완료되면 전체 큰 이슈를 닫는다.
프로젝트 관리
아래와 같이 크게 세 분류를 통해서 전체적인 이슈를 체계적으로 관리하고자 한다.(진행사항을 명확히 하기 위해)
- 인프라
- 도메인 단위 및 추가 구현(조회 서비스 등)
- 세부 항목 관리
문서 및 추가사항
문서와 관련된 부분은 현재 글과 같이 README.md 파일에서 쉽게 접근할 수 있도록 작성하고 있습니다. 고민했던 포인트들이나 구현 관련해서 겪었던 부분들을 주로 업로드 할 예정이고, 추가적으로 이런식으로 코드를 작성한다는 것을 보여드리고자 문서로 남기고 있습니다. 이슈나 문서 등과 관련하여 관리하면서 어려운 부분이나 변경이 있으면 추가적으로 작성할 예정입니다. 부족한 부분은 댓글로 알려주시면 감사하겠습니다.
