몹프로그래밍을 아시나요?

⭐️ 몹프로그래밍을 아시나요? 모든 사람이 같은 일을 동시에 하는 것을 몹프로그래밍이라고 합니다. 링크의 글에서는 비동기로 진행되는 코드리뷰대신 몹프로그래밍을 하는 것을 제안하고 있습니다. 🔥코드리뷰의 단점에 대해서 먼저 이야기하고 있는데 다음과 같습니다. - 긴 피드백 루프 - 대기 - 끝나지 않은 여러작업들 - 문서로 하는 의사소통은 시간이 많이 걸림 코드 리뷰를 하게 되면 리뷰어가 굉장히 난해한 질문을 던지고, 코드 작성자는 또 어려운 답변을 비동기로 해야하는 단점이 있습니다. 오픈소스처럼 완전히 비동기로 작업해야하는 경우에는 어쩔 수 없지만, 매일 같은 시간에 일하고 있는 동료들 끼리도 완전히 비동기로 할 필요는 없습니다. ❓그렇다면 코드리뷰 대신에 어떻게 할 수 있을까요? 글의 저자는 몹프로그래밍을 대안으로 제시합니다. 몹프로그래밍 (https://en.wikipedia.org/wiki/Mob_programming)은 소프트웨어 개발 방법론의 한가지로 모든 팀원이 같은일을, 같은 시간에, 같은 공간에서, 같은 컴퓨터로 하는 것을 의미합니다. 원격으로 하는 경우는 화면을 공유할 수 있으므로 공유화면을 사용하면 됩니다. 저자도 공유화면을 사용한다고 합니다. 4명으로 된 팀이라면, 한명의 프로그래머가 돌아가며 운전수 역할을 합니다. 다른 한명은 네비게이터(안내자)역할을 합니다. 나머지 2명은 네비게이터가 잘못된 길로 갈때 알려줍니다. 한번의 사이클은 3분이며, 돌아가면서 드라이버와 네비게이터 역할을 합니다. 이러한 개발 방법은 항상 주의를 기울여야 하므로 많은 에너지를 소모합니다. 그러므로 휴식이 필수입니다. 주기적으로 휴식하고 점심때는 긴휴식을 갖습니다. 코드리뷰는 지식을 공유하고, 책임을 분담하고, 코드의 구조를 개편하고, 학습을 할 수 있게합니다. 저자는 대체적으로 몹프로그래밍이 코드리뷰보다 우수하다고 말합니다. 🔆 몹은 과연 효율적일까요? 저자는 몹프로그래밍은 비효율적일 것이라고 생각했습니다. 안정화가 되기전인 몇주동안은 비효율적이라고 합니다. 초기 몇 주를 지나면 상황이 달라집니다. 혼자서 몇시간이 걸리는 문제를 다른 어떤 사람은 몇분만에 해결할 수 있기 때문에 더 빠르게 개발 할 수 있습니다. ✅ 몹의 요구사항 몹 프로그래밍은 모든 사람을 위한것은 아닙니다. 몹 프로그래밍은 좋은 커뮤니케이션 기술이 필요합니다. 수동공격, 오만, 잘난척하는 사람이 있다면 그 사람은 적절한 사람이 아니라고 합니다. 몹 프로그래밍은 인내와 존중이 필요하며 팀워크가 무엇보다 중요합니다. 몹 🆚 코드리뷰 코드리뷰는 몇 시간 동안 혼자서 코드와 씨름하고 PR을 올리고 리뷰어의 리뷰를 기다리고, 리뷰어의 변경 요청에 따른 부분을 고치거나 의견을 나누어야합니다. 코드는 보통 2-5일후에 병합되며 충돌도 해결해야합니다. 몹프로그래밍에는 코드리뷰의 단점이 거의 없습니다. 즉 함께 문제를 해결해나가며, 함께 코드를 작성했으므로 코드리뷰의 대기가 없으며, 바로 코드를 병합할 수 있습니다. 💡 어떤 방법이든 만능은 없겠지만, 몹 프로그래밍을 사용해서 함께 작업하는 것도 재미있을 것 같다는 생각을 해봤습니다. 저희팀은 코드리뷰를 하는 방법을 사용하지만, 설계를 할 때에는 같이 모여서 의견을 주고 받으면서 하고 있습니다. 이것도 일종의 몹프로그래밍이 아닐까 생각해봅니다.