* 코드 소유자 * 시스템 : 효율적인 방법입니까? [닫은]

우리 팀에 새로운 개발자가 있습니다. 민첩한 방법은 우리의 회사에서 사용 중입니다. 그러나 개발자에게는 또 다른 경험이 있습니다. 코드의 특정 부분을 특정 개발자에게 할당해야한다고 생각합니다. 따라서 한 개발자가 프로그램 프로 시저 또는 모듈을 작성한 경우 프로 시저 / 모듈의 모든 변경 사항은 본인 만 수행하는 것이 정상으로 간주됩니다.

또한 제안 된 접근 방식을 사용하면 각 개발자가 코드의 부분을 잘 알고 신속하게 수정하기 때문에 일반적인 개발 시간을 절약 할 수 있습니다. 단점은 개발자가 시스템을 완전히 알지 못한다는 것입니다.

이 접근 방식이 중간 규모 시스템 (소셜 네트워크 사이트 개발)에 효과적이라고 생각하십니까?

이 많은 질문들과 마찬가지로, 그 대답은 다음과 같습니다.

그것은 달려있다

모든 프로그래머가 모든 코드 줄을 알아야한다는 입장을 취하는 것이 잘못 인도되었다고 믿을만한 근거가 있습니다.

코드 조각에 대해 깊이 이해 한 사람이 전혀 모르는 사람 (내 경험에 대한 큰 믿음의 도약이 아님)보다 5 배 빠르게 변경을한다고 가정하면 약 한 달이 걸립니다. 상당히 크기가 큰 모듈에 대한 이해도를 높이기 위해 코딩 경험을 쌓았을 때 (합리적이지 않은 경우도 있음) 다음과 같이 (완전히 가짜 및 가상의) 숫자를 실행할 수 있습니다.

• 프로그래머 A : 깊이 이해
• 프로그래머 B : 없음

프로그래머 A가 하루에 1 단위의 작업을 수행한다고 가정 해 봅시다. 5 근무일의 4 주 동안 20 단위의 작업을 수행 할 수 있습니다.

따라서 프로그래머 B는 하루에 0.2 단위의 작업으로 시작하여 20 일째 (프로그래머 A만큼 좋은 21 일)에 0.96 단위의 작업으로 끝나는 동일한 시간에 11.6 단위의 작업을 수행합니다. 20 일 그 달 동안 프로그래머 B는 프로그래머 A와 비교하여 58 %의 효율성을 달성했습니다. 그러나 이제 해당 모듈과 첫 번째 모듈을 알고있는 다른 프로그래머가 있습니다.

물론, 적당한 규모의 프로젝트에 50 개의 모듈이 있습니까? 따라서 이들 모두에 익숙해지는 데 약 4 년이 걸리며, 이는 학습 프로그래머가 평균적으로 프로그래머 A와 비교하여 58 %의 효율로 일한다는 것을 의미합니다.

따라서 동일한 프로그래머, 동일한 프로젝트 (A는 모두 알고 있고 B는 그 중 어느 것도 알고 있지 않습니다)라는이 시나리오를 고려하십시오. 연중 250 일 (근무일 기준)이 있다고 가정합니다. 워크로드가 50 개 모듈에 무작위로 분산되어 있다고 가정합니다. 두 프로그래머를 균등하게 분할하면 A와 B 둘 다 각 모듈에서 5 일 (근무일 기준)을 얻습니다. A는 각 모듈에서 5 단위의 작업을 수행 할 수 있지만 B는 내 작은 Excel 시뮬레이션에 따르면 각 모듈에서 1.4 단위의 작업 만 수행합니다. 총 (A + B)는 모듈 당 6.4 작업 단위입니다. B가 작업하는 모듈에 대한 기술없이 대부분의 시간을 소비하기 때문입니다.

이 상황에서 B가 더 작은 모듈의 하위 세트에 초점을 두는 것이 가장 좋습니다. B가 25 개의 모듈에만 중점을 둔 경우 각 모듈에 대해 총 3.8 개의 작업 단위로 10 일이 소요됩니다. 프로그래머 A는 B가 작동하지 않는 25 개의 모듈에서 각각 7 일, B와 같은 모듈에서 각각 3 일을 소비 할 수있었습니다. 총 생산성은 모듈 당 6.8-7 대 (평균 6.9)로 훨씬 높았습니다. A와 B가 작업을 균등하게 분산시킬 때 수행 한 모듈 당 6.4 단위보다

B가 작동하는 모듈의 범위를 좁 히면 효율성이 향상됩니다 (최대 1 점).

훈련

또한 모듈에 대해 많이 알지 못하는 사람은 더 많은 경험을 가진 사람보다 더 많은 사람을 방해 할 것이라고 주장합니다 . 따라서 위의 숫자는 B가 이해하지 못하는 코드에 더 많은 시간을 소비할수록 질문을 통해 A가 더 많은 시간을 소비하고 때로는 A가 B의 문제를 해결하거나 해결하는 데 도움이되는 시간을 고려하지 않습니다. 누군가를 훈련시키는 것은 시간이 걸리는 활동입니다.

최적의 솔루션

그래서 최적의 솔루션은 다음과 같은 질문에 기초해야한다고 생각합니다.

• 당신의 팀은 얼마나 큽니까? 모든 사람이 모든 부분에 대해 교차 훈련을받는 것이 합리적입니까, 아니면 10 명으로 구성된 팀이있는 경우 각 모듈을 최소한 3 명에게 알려줄 수 있습니까? (프로그래머 10 명과 모듈 50 개로 각각의 프로그래머는 15 배의 모듈을 알아야 3 배 범위를 얻을 수 있습니다.)
• 직원의 이직률은 어떻습니까? 평균 3 년마다 직원을 인계하고 시스템의 모든 구석을 실제로 아는 데 시간이 더 걸리는 경우 교육 비용을 상환 할만큼 오래 걸리지 않습니다.
• 실제로 문제를 진단하려면 전문가가 필요합니까? 많은 사람들이 "그 사람이 휴가를 가면 어떻게되는지"라는 변명을 사용하지만, 경험이없는 시스템에서 문제를 진단하기 위해 여러 번 부름을 받았습니다. 경험이 많은 사람이 더 빨리 찾을 수 있다는 것이 사실 일 수도 있지만, 일주일이나 2 주일 없이는 살 수 없다는 의미는 아닙니다. 미션 크리티컬 한 소프트웨어 시스템은 거의 없으므로 5 시간 대신 1 시간 내에 문제를 진단해야합니다. 그렇지 않으면 세상이 끝날 것입니다. 이러한 위험을 평가해야합니다.

그것이 "의존"이라고 생각하는 이유입니다. 유연성이 없기 때문에 두 프로그래머간에 20 개의 모듈을 중간 (각각 10 개)으로 나누고 싶지는 않지만 유연성이 없기 때문에 많은 모듈을 잃기 때문에 50 명의 모듈에서 10 명의 프로그래머를 교차 훈련하고 싶지 않습니다. 효율성이 뛰어나고 중복성이 많이 필요하지 않습니다.

끔찍한 생각 입니다. 단기간에 더 빠를 수 있지만, 코드를 작성한 코더 만이 코드를 유지해야 할 책임이 있기 때문에 이해하기 어려운 코드를 잘못 권장합니다. 누군가 회사를 떠나거나 휴가를 가면 전체 계획이 정리됩니다. 또한 워크로드를 할당하기가 매우 어렵습니다. 두 개의 긴급 버그가 하나의 코더 "소유자"와 함께 발생하면 어떻게됩니까?

팀으로 코딩해야합니다 . 사람들은 당연히 업무를 배정 받고 특정 영역에 초점을 맞출 것이지만, 업무량을 공유하고 함께 일하는 것은 권장되지 않고 장려해야합니다.

문제의 도메인이 무엇인지에 달려 있습니다.

일반적인 내용 (예 : 간단한 CRUD 작업 등)이라면 Tom Squires에 동의합니다 (모든 사람이 작업하고 편집 할 수 있어야 함).

그러나 ...

문제의 솔루션에 도메인 전문 지식이 필요한 경우 (과거에 많은 시간을 투자했거나 구현 전에 많은 연구를 수행해야합니다. 이는 전문 지식으로 직무 요구 사항에 나열한 것과 같습니다. 프로젝트에 모든 사람이), 다음 소유자가해야했다 확실히 코드의 일부에 할당 될 수있다. 사람이 그런 말로 미루어 해야 필요에 따라에 수정을 할 수 있지만,이해야 항상 프로젝트의 영역을 소유 한 사람에 의해 검토 될 수있다.

전체 팀 (또는 팀의 많은 사람들)이 동일한 주제를 연구하고 학습하게하지 않기를 원합니다 (소비되는주기). 소유자를 지정하되 학습 및 설계를 문서화하고 기술에 대한 비공식 (또는 공식적인, 실제로는 중요하지 않은) 교육 세션을 수행하게하십시오.

이것은 끔찍한 생각 입니다. 나는이 접근법을 사용하는 회사에서 일했고 기술 부채의 더미에 대한 거의 레시피입니다 . 결론은 두 헤드가 거의 항상 하나보다 낫다는 것입니다. 왜? 당신이 바보가 아니라면, 당신은 당신이 완벽한 프로그래머가 아니라는 것을 알고 당신이 만드는 모든 실수를 잡지 않을 것입니다. 그렇기 때문에 다른 관점에서 동일한 코드를 보는 더 많은 눈을 가진 팀이 필요합니다.

그것은 discipline 한 가지로 요약됩니다 . 코딩 스타일에 정통한 사람은 몇 명입니까? 훈련으로 코드를 작성하지 않으면 바로 가기 ( "나중에 수정"하기 때문에)를 사용하면 코드의 유지 관리 성이 떨어집니다. 우리는 모두 "나중에"오지 않는다는 것을 알고 있습니다. 사실 : 팀의 동료에게 즉시 책임을 지울 때 바로 가기를 사용하기가 더 어렵습니다. 왜? 당신의 결정에 의문이 제기되고 지름길을 정당화하기가 항상 어렵 기 때문입니다. 최종 결과? 더 강력하고 유지 관리가 잘되는 코드를 생성합니다.

모든 사람이 모든 것을 연구하고 이해할 필요는 없다는 장점이 있습니다. 단점은 각 사람이 자신의 코드 영역에 필요하게 만들고 다른 사람이 코드를 유지 관리하는 방법을 모른다는 것입니다.

각 코드 영역에 대해 최소 2 명의 소유자가 있어야합니다. 그런 다음 누군가 휴가를 가거나, 새로운 직업을 가지거나, 은퇴 할 수 있으며, 여전히 코드를 알고있는 사람이 있습니다 (새로운 제 2자를 훈련시킬 수 있음). 모든 사람이 모든 것을 배울 필요는 없지만 조금 더 효율적입니다.

동일한 2 명 (3 명)의 사람들이 항상 함께 일하지 마십시오. 서로 다른 영역에 대한 쌍을 전환하므로 관련 프로그램 영역에서 다른 사람과 작업 할 때 지식이 우연히 공유됩니다.

예, 단기적으로는 좀 더 효율적입니다. 그리고 이점이 끝납니다. 그것은 비용을 능가하는 것에 가깝지 않습니다.

휴가 중이거나 예기치 않게 아프거나 떠날 때 또는 속담 버스에 부딪히면 어떻게됩니까? 한 작업을 다른 작업보다 빠르게 처리하기 위해 리소스를 조정하려는 경우 어떻게됩니까? 코드 검토가 얼마나 효과적 일 수 있습니까? 관리자, 특히 코드 기반이 아닌 관리자는 개발자가 열심히 일하거나 양모를 눈으로 당기는 지 어떻게 알 수 있습니까? 기술 부채가 시작되면 누가 알 수 있습니까?

내 경험상 이런 식으로 일하는 것을 좋아하는 사람들은 영광스러운 사냥꾼이며 최악의 경우 게으른 사람입니다. 그들은 주어진 문제로 갈 수있는 유일한 사람이되고 코드를 비공개로 유지하기를 좋아합니다. 또한 가독성을 고려하지 않고 빠른 코딩을 원합니다.

50 명의 개발자로 구성된 팀에서는 모든 사람이 모든 코드를 알고 있어야하지만 5-7 명의 팀은 사람들이 계속 일할 수있을 정도로 큰 모듈을 소유해야합니다. 개인은 아무것도 소유하지 않아야합니다.

다른 답변이 지적하는 적어도 세 가지 문제가 있습니다. 하지만 둘 다 함께 노력하고 싶습니다. 두 가지 문제는 다음과 같습니다.

• 전문성 : 팀의 누군가가 특정 분야에 대한 자세한 지식을 가지고 있습니다. 이 지식은 프로젝트에서 해당 도메인의 특정 구현과 무관합니다.
• 리더십 : 프로젝트 개발 작업은 많은 개발자들에게 공유 될 수 있지만; 중요한 구현 세부 사항에 대한 즉각적인 결정뿐만 아니라 로드맵은 특정 팀 구성원이나 팀 구성원 중 일부가 직접 결정합니다.
• 자아없는 코드 : 프로젝트가 구현되는 특정 방식은 팀의 특정 개발자의 코딩 스타일, 실습 또는 지식에 의존하지 않습니다. 잘 알려진 코딩 스타일 또는 잘 관리 된 사양을 엄격하게 준수함으로써 모든 새로운 팀원은 숙련 된 개발자로서 프로젝트의 방법과 이유를 이해할 기회가 동일합니다.

주제가 순전히 전문 지식 중 하나 인 경우, 프로젝트의 성공은 도메인에 대한 높은 수준의 지식에 의존 할 수 있습니다. 그러나 해당 도메인에 대한 특정 전문가의 지식에 의존하지 않습니다. 전문가는 드물고 귀중하지만 여전히 본질적으로 상호 교환이 가능합니다. 한 경험이 풍부한 세무사는 도메인 지식의 관점에서 다른 세무 계획 소프트웨어 프로젝트에 유용합니다. 이 문제는 전문가가 지식을 프로젝트에 얼마나 잘 전달할 수 있는지 중 하나가됩니다.

주제가 순전히 리더십 중 하나 인 경우, 프로젝트의 성공은 주로 프로젝트 리더의 결정에 대한 일관성과 통찰력에 달려 있습니다. 우리는 해당 분야에서 경험이 있거나 프로젝트 리더로 입증 된 프로젝트 리더를 선호하는 경향이 있지만, 이는 때때로 그 역할에 부수적 인 일입니다. "리더"는 의사 결정이 사례마다 일치하고 각 의사 결정이 팀에 의해 신속하게 실행되는 경우 매일 바뀔 수 있습니다. 이것이 제대로 작동하면; 팀이 이미 어떤 결정을 내릴지를 이해하고 있기 때문에 프로젝트 리더가 많은 결정을 내릴 필요는 없습니다.

이 질문이 자아없는 코드에 관한 것이 아니라고 생각하지만이 문제가 얼마나 중요한지 논의하지 않고 코드 소유권에 대해 이야기하기는 어렵습니다. 프로젝트 유지 관리는 아마도 개발주기의 큰 부분 일 것입니다. 이 문제를 이해하는 방법은 일부 개발자가 즉시 떠나야 할 경우 어떻게 될지 궁금해하는 것입니다. 하면 어떻게 될까 양 팀 모두 교체했다? 일부 주요 업체에 따라 프로젝트가 의심되는 경우 실패 할 위험이 높습니다. 단일 팀원을 잃지 않더라도 한 명 또는 몇 명의 개발자가 프로젝트를 진행하는 데 필요하다는 단순한 사실은 더 많은 개발자가 참여했을 때보 다 효율적으로 작업하지 않을 수 있음을 의미합니다.

코드 소유권은 코드를 처리해야하는 문제가있는 경우 리팩토링을 방지하고 개발 병목 현상을 발생 시키며 자아 문제를 일으키는 경향이 있습니다.

높은 표준 코드는 문서화, 단위 테스트, 통합 테스트 및 시스템 테스트를 거쳐이 중복성을 만들기에 충분해야하지만 다른 의견을 얻는 데 여전히 어려움이 없습니다.

이것은 많은 이유로 나쁘다. 나는 그들이 이것에서 더 합리적인 것으로 바꾸려고 노력했던 상점에서 일했고 그것은 추악했다.

이것이 나쁜 이유 :

• 코드 소유자가 휴가를 보내고 큰 버그가 발생하면 코드를 배우고 버그를 수정하는 것이 매우 어렵고 시간이 많이 걸립니다.
• 코드 소유자가 회사를 떠나면 모든 유산과 부족 지식이 방금 나왔기 때문에 프로젝트가 심각하게 다시 시작됩니다.
• 설명서가 잘못되었습니다. 내가 코드를 작성하는 유일한 사람이라면 왜 문서화해야합니까? 관련된 문제는 문서가 완전하거나 정확한지에 대해 실제로 말할 코드에 대해 아무도 알지 못하기 때문에 작성해야하는 모든 문서도 열악 할 수있는 문제입니다.
• 모든 사람이 자신의 작은 샌드 박스를 가지고있을 때 코드 성전은 쉽게 발화 될 수 있습니다. 이것이 문제가되는 곳은 두 사람이 함께 일해야 할 때 어느 것도 타협하지 않습니다.
• 위의 점 때문에 팀워크 기술은 결코 형성되지 않습니다. 사람들은 다른 사람들과 협력 할 필요가 없습니다.
• 회사는 아무것도 사지 않는 쓰레기 주머니로 만든 작은 왕국을 쉽게 형성 할 수 있습니다. 당신은 모듈 또는 도구 X는 밥에 무엇을하고 있는지조차에 관한 문의해야 네게 밥의 책임과 비애 때문에 너무 늦기 때까지이 일어나고있다 모르는 자신의 코드입니다.
• 아무도 코드에 대해 아무것도 모르기 때문에 코드 검토 및 동료 검토가 어려움을 겪습니다. 코드를 모른다면 텍스트 형식 및 명명 규칙에 대해서만 주석을 달고 옳지 않은 곳을 찾을 수 없습니다.
• 그리고 당신이 나를 위해 일한다면 ... 회사는 당신이 아닌 코드를 소유합니다. 우리는 우리가하는 일과 우리가하는 일과 우리가 쓰는 것에 자부심을 가지고 있지만, 팀이 어려운 경기에서 이길 때와 같이 그룹적인 일입니다. 회사에서 일하는 모든 직원은 코드를 동등하게 소유하며, 업무를 수행하는 동안 회사의 목표를 전달하기 위해 자신의 업무를 수행하는 방식으로 코드를 편집 할 수 있습니다.

가장 큰 문제는 실제로 인사 문제와 문서입니다. 그 사람은 언젠가 떠날 것이고, 소년은 몇 주 동안 스케쥴을 왼쪽으로 밀게 될 것입니다.

더 나은 접근 방법은 모든 사람이 코드베이스의 모든 부분 (또는 실제로는 크고 다양한 경우 6 개 정도)에 익숙해 지도록하는 것입니다.

• 해당 영역의 결함 수정
• 사소하거나 중간 정도의 새로운 기능 또는 개선 사항 추가

각 사람은 다른 사람보다 몇 가지 사항에 대해 조금 더 알고있는 경향이 있으므로 어려운 문제는 둘 또는 셋이 서로 뭉치거나 사실상 전문가가 취할 수 있습니다. 나는 이것이 사실이었던 그룹에서 일했고 정말 잘 작동했습니다. 위에 열거 된 단점이 없었을뿐만 아니라, 전문가를 찾아 다니지 않았기 때문에 직원 채용이 훨씬 더 예측 가능했습니다.

유일한 코드 소유권의 장점은 "코드 소유자"가 다른 것보다 더 빠르게 작업을 수행 할 수 있다는 것입니다. 그러나 모든 사람이 겹치지 않는 프로젝트에서 "코드 소유자"인 경우에만 해당됩니다. 다시 말해, 사람들이 회전하면 "단독 코드 소유자"의 이점이 사라집니다.

버스 번호 ( 일명 버스 계수)를 참조하십시오.

버스 팩터 ( 트럭 팩터 또는 버스 / 트럭 번호 라고도 함 )는 개별 팀 구성원의 정보 집중도를 측정 한 것입니다. 버스 팩터는 프로젝트를 진행할 수없는 혼란에 프로젝트를 보내기 위해 (버스 / 트럭에 의해 타격을받는 것과 같이) 무능력 상태가되어야하는 주요 개발자의 총 수입니다. 프로젝트는 나머지 팀원이 익숙하지 않은 정보 (예 : 소스 코드 )를 유지합니다 . 버스 요소가 높으면 프로젝트가 실패하기 전에 많은 개발자를 제거해야합니다.

"버스를 치다"는 여러 가지 형태가 있습니다. 이것은 새로운 직업을 가지거나, 아기를 낳거나, 생활 양식이나 생활 상태를 바꾸거나, 문자 그대로 버스에 치인 사람 일 수 있습니다. 효과는 같습니다 ...

많은 것들과 마찬가지로, 그것은 큰 "의존"입니다. 엄격한 "다른 사람이 코드에서 작업 할 수 없습니다"인 경우에는 잘못된 것으로 판단 될 수 있습니다. "소유자가 변경을 수락하기 전에 코드 검토를 수행해야합니다"인 경우 소유자가 외부 변경을 기꺼이 받아들이는 방법에 따라 중간 단계로 진행됩니다.

단점은 심각하다. 팀의 "트럭 번호"는 거의 1이됩니다.

"트럭 번호"는 간단히 말해서 "일부 중요한 작업을 수행하는 데 필요한 지식이 팀에 손실되기 전에 최악의 경우 팀원이 트럭에 부딪 칠 수있는 사람"으로 정의됩니다.

개발자가 하위 분야에 초점을 맞추는 것은 당연한 일이며 장려해야 할 일입니다. 모든 사람이 프로젝트와 관련된 모든 것을 알아야한다면, 모든 사람들이 다른 사람들이 한 일을 배우고, 왜 그것이 효과가 있으며, 그것을 어지럽히 지 않고 변경하는 방법을 배우기 때문에 아무것도 할 수 없습니다. 또한 개발자가 다른 영역에서 다른 작업을 수행하지 않으면 변경 사항이 충돌 할 가능성이 줄어 듭니다. 따라서 일반적으로 프로젝트의 특정 하위 시스템에서 주로 작동하고 잘 알고있는 2 명 또는 3 명의 개발자 또는 개발자 쌍이있는 것이 좋습니다.

그러나 한 사람 만 특정 코드 줄을 건 드리면 그 사람이 종료되거나 해고되거나 휴가를 가거나 병원에서 퇴원하면 해당 코드 줄이 버그의 원인으로 나타납니다. 다른 사람이 들어가서 코드를 이해해야합니다. 그것을 쓴 사람 외에는 아무도 본 적이 없다면 개발자가 더 이상 변경하지 않고 버그를 수정하는 변경을 할 수있는 수준의 이해에 도달하려면 시간이 걸립니다. TDD는 도움을 줄 수 있지만 개발자에게 "잘못된"변경을했다고 알려야합니다. 다시 한번, 개발자는 실패한 테스트가 잘못된 주장을하지 않도록하기 위해 어떤 테스트가 어떤 코드를 사용하는지 이해해야합니다.

나는 그것을 극단적으로 받아들이지 않지만 코드 책임을 선호 합니다 . 깨진 코드를 작성하면 수정해야합니다. 개인, 쌍 또는 팀 수준에서 수행 할 수 있습니다. 정리를 위해 다른 사람에게 엉망을 전달하는 것을 방지합니다. 이것은 변화에도 적용됩니다.

작업량 및 예약 문제로이를 덮어 씁니다. 범인이 2 주간의 휴가 중이기 때문에 주요 버그 수정을 미루는 것은 어리석은 일입니다.

목표는 팀이 "비난 게임"을하도록하거나 버그 수를 너무 많이 늘리는 것이 아닙니다 (어쨌든 모두 같지는 않습니다). 코드를 마지막으로 확인한 사람을 기준으로하거나 감독자가 결정을 내리고 모든 코드 줄의 모든 부분을 거치지 않고 누군가에게 할당하도록합니다.

더 나은 프로그래머는 아마 다른 사람의 코드를 어떻게 할당하든 수정하게 될 것입니다.