✍ 오늘 한 일

💡 오늘 진행 상황을 간단하게 정리 합니다.

3차 기획

2차 기획에서 나온 기능들을 자세하게 이야기 해보았다. git api 혹은 jira api 에 대하여, 지식이 많지 않다보니 명확하게 지금 우리 팀에서 구현이 가능한지 알 수가 없었다. 해당 부분을 우리끼리 고민하기 보다는 컨설턴트님께 피드백을 받아보자고 하였다.

피드백

우선, 현재 기획이 오픈소스 트랙에 어울리는 가에 대해 여쭤 보았다. 우리 팀의 서비스는 기존 협업툴의 어려운 점을 해결해주는 서비스이기 때문에, 웹서비스로 진행하면서 컨트리뷰터를 모집하는 것이 알맞다고 생각했다. 그렇기 때문에 코드를 작성하면서도, 해당 코드가 어떤 식으로 작동하는 지, 해당 함수는 어떻게 구현이 된 건지, 설명이 필요하다. 이러한 부분은 JSDocs 나 [readme.md](http://readme.md) 를 활용할 생각이다.

간트차트를 만들 수 있는지에 대해서는 가능하다고 판단하셨다. jira api 을 통해 JQL 을 사용하는 것이 가능한데, 나의 이슈에 대한 데이터를 받아오거나, 다른 팀원에 대한 이슈 데이터를 받아오는 것이 가능하다. 다만 걱정은, 그 데이터를 어떤 차트로 프론트엔드에서 빚어낼지 이다. 디자인의 영역이 될 텐데, 이참에 여러가지 차트 좀 봐둬야 겠다.

깃과 지라를 연결하는 이벤트에 대해서는 어려움이 있다는 이야기를 하셨다. 깃 관련 오픈소스들이 커밋 메시지나, 충돌 부분을 자동화시키지 않는 것에는 이유가 있는 것이다. 사람의 손이 필요한 작업은 과감히 버리고, 자동화 시킬 수 있는 부분, 편의를 만들 수 있는 부분만 확고히 하는 것 만으로도 충분히 브릿지 솔루션의 역할을 할 수 있다는 의견을 내셨다.

깃 전략

깃 전략을 생성하였다. 프로젝트를 2번 정도 하니, git flow 전략에 대해 다들 어느정도 파악하고 있었다.

git flow 는 master → release → dev → FE & BE 로 이어진다. hotfix 가 사라졌는데, 7주간의 프로젝트안에서 크게 쓰지 않기 때문이다.

branch 는 닉네임과 해당 기능을 작성한다. 기존의 프로젝트에서와 크게 다르지 않다.

• feat-bell/login

커밋 메시지의 경우 git commitzen 을 사용하기로 했다.

코드 리뷰 공통

• 다른 2인이 승인해야 머지를 한다.
• 리뷰가 진행이 되며, 수정이 필요한 경우, 수정 후 새롭게 머지를 요청한다. 이전 머지 요청은 취소한다.
• 머지 요청이 올 때는 최대한 바로바로 리뷰하자.
• 스크럼 종료 시에 모두 풀을 받아서 해당 FE, BE , dev 가 모두 최신상태가 되도록 하자!

📢 개선 사항

💡 오늘 하루 개선하면 좋았을 부분을 작성합니다. 없다면 생략하셔도 좋습니다.

📢 내일 진행 예정

💡 내일 할 업무를 팀원들과 함께 공유해봅시다. 글이 자세할수록, 팀원 모두가 업무 흐름을 파악하기 쉬워집니다.

기획하기

개발을 시작하기엔 아직도 정해야 할게 많다. 개인적으로 기획은 개발보다 중요한 부분이다. 최대한 많이 많이 기획하자!