3주차 회고

[JiinSeok]

codeit-bootcamp-frontend/7-Sprint-Mission#293

3주차 Team-Final을 돌아보며, Keep, Problem, Try를 적어주세요!

[JiinSeok]

KEEP

[JiinSeok]

디스커션이 잘 활용되고 있다.

[JiinSeok]

PROBLEM

[JuhyeokC]

• 상의없이 PR 머지 룰이 변경됨.
  • 기존: 모두가 code owner 이고 2명 이상 approval 시 merge 가능
  • 변경: 1인의 code owner 의 리뷰가 있어야하며 2명 이상 approval 시 merge 가능
• PR 리뷰에 request change 로 승인을 요청해두고 수정된 사항에 대해 승인이 굉장히 늦음.
  • 위 문제로 해당 브랜치의 내용이 필요한 추가 개발을 위한 브랜치 생성이 제한됨. -> 개발 속도 저하
  • 치명적인 문제가 아니면 지양, PR 리뷰가 저항이 되어서는 안된다.

[JiinSeok]

@JuhyeokC 님 처음부터 제가 1인의 코드오너였습니다...! 이 부분은 멘토링 시간에 같이 브랜치 룰 보면서 얘기하고 결정한 것으로 기억합니다. 코드리뷰 기준을 전원에서 2인으로 축소하면서 일관성을 유지할 방법으로서 나온 얘기였어요.

코드오너를 자처한 이후 모든 PR을 리뷰하고 있습니다. change requests 후 approve 처리가 늦었던 것은 안타깝지만 재리뷰를 하지 않았던 이유는 해당 브랜치에 커밋이 여전히 추가되고 있어 작업 중인 PR로 생각했기 때문입니다.

더불어 dev에 머지되지 않은 상태여도 해당 브랜치를 리베이스 하거나, 이 브랜치에서 새 브랜치를 생성하는 등의 작업이 가능하기 때문에 코드오너 어프로브를 머지 조건에서 빼는 건 필수는 아닌 것 같습니다. 지금까지 PR 머지가 늦어졌던 상황은 다양했으며 주요 원인이 코드오너의 늦은 리뷰라고 하긴 어렵다고 생각합니다.

[JuhyeokC]

@JiinSeok 님
이 회고에 대해 팀미팅 때 이야기가 완료된 내용이지만 다른 내용이 있고,
이에 대해 앞으로 어떻게 하기로 정리된 내용이 누락됐네요.

처음엔 코드오너가 1인이었지만 특정 시기부터 최근까지 모두가 코드오너로 되어있는 걸로 확인했습니다.

request change 를 지양하자고 말씀드린건 프로젝트 시작 때 서로의 "나 사용법"을 톺아보며
"코드 리뷰는 강제하지않고 충분히 설득하는 리뷰를 하자"라는 취지와는 맞지않는 것 같아서 말씀드렸습니다.
request change 는 리뷰 작성자의 내용을 적용해야 승인하겠다는 것이니까요.

이에 치명적인 경우 request change 를 생성하고 생성자도 책임감을 갖고 확인과 재요청이 필요한 것 같다는 것이고

1. request change 에 대해 적용이 완료되었을 경우
2. 리뷰 생성자에게 적용이 완료되었다는 멘션보내기
3. 적용완료 멘션 이후 늦지 않게 해당 내용 확인 후 승인
   으로 정리했습니다.

프로젝트 시작을 다시 기억해보면 특별한 경우가 아닌 이상 PR이 자정을 넘기는 건 지양하자고 했는데
이슈가 된 해당 PR은 2주가 넘었죠.
해당 브랜치에서 추가 작업을 한 영향도 있었지만 빠른 승인 후 머지가 되었다면 발생하지 않았을 이슈라고 생각되요.

처음부터 다 완벽할 수 없습니다.
그렇기에 지인님과 저도 깃허브 사용에 미숙하지만 아주 약간 더 경험해봤기에 나서서
다른 팀원들이 익숙해지고 나아질 수 있도록 도와주기로 약속했습니다.
하지만 이렇게 일방적으로 강제하고 설정을 바꾸는 것은 긍정보다 부정적인 영향이 큰 것 같습니다.
모든 PR에 대해 1인의 리뷰가 무조건 필요하다면 그 1인에게 많은 부하가 발생할 것입니다. 부하에 대해서는 따로 말씀을 드렸던 걸로 기억합니다.
극단적인 경우로 그 1인과 장시간 상호작용이 되지않는 상황이 생긴다면 더더욱 부정적인 경험을 하겠죠.

회고를 회고한 내용에 대해서 대화는 휘발되지만 글은 각인됩니다
글로 적을 땐 모든 내용을 다 적어주셨으면 좋겠습니다.

[JiinSeok]

TRY

[JuhyeokC]

• 모각코 때 본인 작업화면 송출하기