코드 검토를 하지 말고 대신 Mob을 사용해 보십시오.

https://medium.com/verotel/dont-do-code-review-try-mob-instead-82149ef035df

코드 검토를 하지 말고 대신 Mob을 사용해 보십시오.

코드 리뷰 단점

• 긴 피드백 루프
• 대기 중
• 완료되지 않은 여러 작업
• 서면 의사 소통에는 시간이 많이 걸립니다.

"코드 작성 -> 검토를 위해 보내기"를 의미하는 전형적인 프로그래밍의 날입니다. 지금은? 어… 또 다른 작업. 작업은 쉬웠습니다. 세 번째 작업을 시작하겠습니다. 그리곤 리뷰의 필요성을 재촉하고, 잠시 기다렸다가 혼자 리뷰를...
마지막으로 두 번째 과제 리뷰! 아니요, 동의하지 않습니다. 제대로 대답해야합니다… 한 시간 후에 나는 논증 요약을 마치고 다음 날 동료가 OK라고 대답합니다. 뭐? 그냥 OK?!

코드 리뷰의 가장 중요한 문제는 상당히 어려운 질문/답변의 비동기식 핑퐁입니다. 이는 비효율적일 뿐만 아니라 사람들을 좌절하게 만듭니다.

또 다른 접근 방식은 가능한 한 빨리 코드 검토를 수행하는 것입니다. 이 접근 방식을 적용하면 결국 일주일 내내 코드 검토를 하게 됩니다. 그리고 그것은 과장이 아닙니다. 코드 리뷰를 많이 할수록 더 많은 요청을 받습니다. 이것은 다시 좌절로 이어집니다.

코드 리뷰의 목표

코드 리뷰의 이점은 무엇입니까?

• 지식 공유
• 책임 공유
• 코드 구조 개선
• 학습

좋은 코드 리뷰는 이러한 모든 측면을 다룹니다. 그러나 코드 검토는 도구일 뿐이며 더 나은 도구를 찾을 수 있다면 코드 검토를 버릴 수 있습니다.

마피아 프로그래밍

모브 프로그래밍 은 모든 팀원이 한 화면 앞에 동시에 존재한다는 것을 의미합니다. 또는 공유 화면에서 원격으로 작업할 수도 있습니다. 제 경우입니다.

저는 4명으로 구성된 팀에서 일하며 Mob 스타일로 하루에 5~6시간 정도 일합니다. 처음에 우리는 작업을 결정하고 가능한 경우 운전 세션에서 회전합니다.

세션이란 한 명의 드라이버(타이핑/클릭하는 드라이버)와 네비게이터(네비게이터)가 드라이버에게 무엇을 해야 하는지 알려준다는 의미입니다. 다른 팀원 2명은 계속 주의를 기울이다가 네비게이터가 잘못된 방향으로 갈 때만 끼어듭니다. 내비게이터는 3분 동안 탐색합니다. 실제로는 3분만 탐색한 다음 회전합니다.

회전은 운전자가 이제 탐색한다는 것을 의미합니다. 다음 단계를 알아야 하고, 내비게이터는 휴식을 취하고, 2마리의 몹 드라이브 중 하나가 필요합니다. 그리고 3분 후 또 다른 회전, 그리고 다시, …

이 회전 스타일은 강렬합니다. 항상 주의를 기울여야 합니다. 그렇지 않으면 몇 분 안에 탐색해야 하고 어떻게 탐색해야 할지 모를 것입니다.

몸매를 유지하기 위해 우리는 화장실/커피를 위한 규칙적인 휴식을 취하고 물론 점심을 위한 긴 휴식을 취합니다.

코드 보기의 목표가 달성됨

지식 공유 는 즉각적입니다. 모든 팀원은 정신적 과정을 따르고 수행한 이유를 알고 있습니다.

내 의견에 책임을 완전히 공유 합니다. 저는 언제든지 "동의하지 않습니다" 또는 "더 나은 아이디어가 있습니다"라고 말할 수 있으므로 우리가 생산하는 모든 것에 대해 책임을 집니다.

코드 구조 는 모든 팀원이 동의하므로 일관성이 있으며 최고의 팀원이 할 수 있습니다.

학습 은 다시 즉각적이고 강렬합니다. 네비게이터가 좋으면 무엇을 해야할지 뿐만 아니라 어떻게 하면 효율적으로 할 수 있는지도 불러줍니다. 나는 날마다 더 나은 소프트웨어 아키텍처, 더 나은 테스트 전략, IDE를 효율적으로 사용하는 방법을 배웁니다. 내비게이터가 내가 놓친 부분을 알고(및 공유) 하기 때문입니다.

대체로 Mob은 모든 측면에서 코드 검토보다 우수합니다. 그리고 코드 검토 탁구 좌절.

몹은 비효율적이어야 합니다.

처음 몇 주 동안 나는 Mob이 비효율적이라고 생각했습니다.

팀이 정착 중이거나 팀 구성원이 아직 언어와 도구에 대한 경험이 없을 때는 확실히 그렇습니다. 그 기간 동안 Mob은 학습에 대해 매우 중요합니다.

그러나 팀이 초기 몇 주를 지나면 매우 달라집니다.

거의 매일 나는 혼자 있을 때 해결하는 데 적어도 한 시간(또는 몇 시간)이 걸리는 문제를 경험합니다. 하지만 우리는 4명이 있고 보통 다른 사람이 몇 분 안에 문제를 해결하는 방법을 알고 있습니다. 내 동료들은 그들도 같은 경험을 하고 있다고 확인합니다. 그들은 무엇을 해야 할지 모르고 다른 누군가는 즉시 그것을 압니다.

모든 팀원은 또한 다른 분야에서 더 우수하거나 전문가입니다. 하나는 DB에 좋고, 하나는 우리가 사용하는 프레임워크에 있고, 하나는 예입니다. 의사결정을 잘함. 따라서 내비게이터가 막혔을 때 이 "전문가" 한 명이 장애물을 극복하는 데 도움을 줍니다. 그리고 그것은 즉시 발생합니다.

몹 요구 사항

모브 프로그래밍은 모두를 위한 것이 아닙니다.

처음에는 같은 시간에 함께 있을 수 없으면(원격은 괜찮음) 작동하지 않습니다.

폭도는 좋은 의사 소통 기술이 필요합니다. 수동적 공격성을 위한 공간이 없습니다. 또는 오만함. 당신이 당신의 동료보다 낫다는 것을 보여주고 싶다면 당신은 Mob의 후보가 아닙니다..

폭도는 인내와 존중이 필요합니다. 모든 사람이 항상 최상의 모습과 상태를 유지하는 것은 아닙니다. 당신이 해결책을 서두르는 것을 좋아하고 동료를 지도/가르치는 데 관심이 없다면 마피아는 작동하지 않을 것입니다. 당신의 동료는 나아지지 않을 것이고 팀은 나아지지 않을 것입니다.

그게 다야. 같은 시간(멀리 떨어져 있어도) 함께 있을 수 있고, 참을성이 있고, 새로운 접근 방식에 관심이 있고, 동료가 비슷한 관점을 가지고 있다면 그렇게 하세요. 몹이 길이다!

Mob 대 코드 검토

Mob과 코드 리뷰를 비교하면 웃을 수 밖에 없습니다.

코드 검토 스타일에서는 몇 시간 동안 문제를 해결하기 위해 고군분투한 다음 코드 검토에 솔루션을 보낸 다음 기다렸다가 검토자가 변경 사항을 제안하고 내 솔루션에 대해 논쟁하거나 코드를 변경합니다. 2-5일 후에 병합할 코드가 준비되지만 병합 충돌을 해결해야 합니다!

Mob 프로그래밍에는 그런 것이 없습니다.

• 투쟁은 팀원의 경험에 의해 제한됩니다.
• 대기 없음
• 즉각적인 인수/코드 변경
• 병합 충돌 감소

Mob은 훨씬 더 많은 이점을 가지고 있으며 저에게 가장 중요한 것은 나와 동료 간의 관계를 개선하는 것입니다. 프로그래머도 사회적인 생물이고 Mob은 많은 도움을 줍니다.

Mob 프로그래밍이 피드백 루프를 극적으로 단축하고 놀라운 결과를 가져온다는 점을 요약하고 싶습니다.