개별 코드 소유권이 중요합니까? [닫은]

전체 코드베이스의 팀 소유권이 해당 구성 요소의 개별 소유권보다 나은지 여부에 대해 일부 동료들과 논쟁 중입니다.

저는 모든 팀원에게 거의 동일한 코드베이스를 할당하는 것을 강력하게 제안합니다. 그것은 사람들이 그들의 창조에 자부심을 가질 수있게하고, 버그 스크리너에게 들어오는 티켓을 할당하는 명백한 첫 번째 장소를 제공하고, "깨진 창 증후군"을 완화하는 데 도움을줍니다.

또한 특정 기능에 대한 지식을 한 팀 (또는 두 팀)의 팀원에게 집중하여 버그를 훨씬 쉽게 수정합니다.

무엇보다도위원회 대신 많은 의견을 가진 한 사람과의 주요 결정에 대한 최종 결정을 내립니다.

다른 사람이 귀하의 코드를 변경하려는 경우 허가를 요구하는 것을 옹호하지 않습니다. 코드 검토를 항상 소유자에게 맡길 수도 있습니다. 또한 지식 사일로 구축을 제안하지도 않습니다.이 소유권에 대해 독점적 인 것이 없어야합니다.

그러나 이것을 동료들에게 제안 할 때, 나는 예상보다 훨씬 많은 푸시 백을 받았습니다.

그래서 저는 커뮤니티에 질문합니다 : 큰 코드베이스에서 팀과 협력하는 것에 대한 당신의 의견은 무엇입니까? 단체 소유권을주의 깊게 유지하는 데 빠진 것이 있습니까?

팀 소유권이 장기적으로 훨씬 더 유익하다고 생각합니다.

최소 인원수에 대한 지식을 집중시키는 것이 이상적이지 않은 이유를 이해하려면 다음 두 시나리오를 살펴보기 만하면됩니다.

• 팀원이 불행한 사고를 만난다
• 팀원은 더 나은 고용 기회를 만난다

당연히, 특정 섹션을 쓰는 사람 / 사람들은 그것에 대해 더 많은 지식을 가지게 될 것이지만, 그것들을 유일한 지식의 사일로 로 만들려는 유혹에 굴복하지는 않습니다 . 사일로 는 장기적인 고통으로 단기적인 승리를 줄 것입니다.

코드 섹션에 대한 개별 소유권이 없다고해서 코드를 작성했다고해서 "창조에 대한 자부심"등의 측면이 여전히 존재하지 않는다는 의미는 아닙니다. 작성된 코드의 개인적 소유권 느낌을 줄입니다.

궁극적으로 팀은 코드를 소유합니다. 그러나 귀하가 언급 한 모든 이유로 인해 코드의 특정 부분에 대해 개별 작성자를 지정했습니다. 각 작성자는 코드 부분에 대한 기본 책임과 코드 기반에 대한 보조 책임이 있습니다.

코드베이스 표면의 일부에 문제가 발생하면 원래 코드를 작성한 사람에게 수정을 요청합니다. 물론 다른 팀 구성원이 수정 사항을 적용하는 데 방해가되지는 않습니다. 모든 팀원은 다른 사람의 코드에 익숙해야합니다. 그러나 우리는 항상 원저자로부터 먼저 수정을 시도합니다. 결국, 그들은 코드를 작성했습니다. 그들은 그것에 가장 친숙한 사람입니다.

나는 사람들이 작성한 것에 대한 소유권을 느끼지 못했기 때문에 우수한 코드를 작성하는 것이 아니라 단지 평균 코드를 작성해야한다는 팀 환경에서 일했습니다.

제품에 대한 지식을 전파해야하는 이유에 대해서는 비즈니스 입장에서 동의하지만; 현실은 시간이 지남에 따라 주어진 영역에 그들의 노력을 집중시키는 것이 주어진 영역에서 훨씬 더 정통해질 것입니다.

이것을 무시하는 것은 과학을 무시하는 것입니다. 불행히도 뇌는 마주 치는 모든 것을 유지할 수 없습니다. 주어진 순간에 유효하고 가치있는 것을 기억하지만 시간이 지남에 따라 스토리지가 줄어든다.

더 큰 코드베이스 내에서 특정 모듈 또는 구획에 대한 소유권이 일반적으로 더 나은 결과를 생성한다는 데 동의합니다. 예고없이 떠나는 사람이 성공을 방해합니까? 확실히. 그러나 팀 내의 모든 사람이 코드 기반과 관련하여 동일한 양의 지식을 가져야하는 것은 순진하며 코드를 개선하는 데 아무런 도움이되지 않습니다. 코드를 보호하려고 시도합니다. 코드 보호는 분명한 이유로 비즈니스의 역할입니다. 기업이 코드를 보호하기 위해 노력하는 시간은 종종 똑같이 해로울 수 있습니다.

팀의 모든 선수가 쿼터백을 할 수 있는지 확실하지 않습니까? 팀원이 코드베이스에 대한 지분을 확보하는 것은 팀 내의 모든 플레이어가 만족스러운 수준에서 쿼터백을하도록하는 것과 같은 행을 따른다고 주장합니다. 백업이 있습니까? 물론 ...하지만 팀원은 팀 내에서 정체성을 가져야합니다. 모두가 같다고 믿는 것은 다른 종류의 고통을 요구하는 것입니다.

개별 코드 소유권 이 좋은 아이디어 라는 것을 모르겠습니다 . 적어도 사람들이 "이것은 내 코드이고, 내가 원하는 것을 할 것"이라고 말할 수는 없습니다. 개별 코드 관리자 가 있어야한다고 말하는 것이 좋습니다 . 코드는 팀이 소유해야하지만 팀이 책임과 권한을 위임하는 특정 사람이 있습니다.

그 이유는 그것이 모두의 책임이라면 누구의 책임도 아니기 때문입니다.

다음과 같은 이유로 개인에 대한 팀 소유권을 제지합니다.

• 전체 프로젝트에 대한 코드 일관성
• 코드에 대한 토론을 촉진하여 항상 더 나은 솔루션을 제공합니다.
• 한 팀원이 아프거나 악화되면 전체 코드 섹션이 지연되지 않습니다.
• 팀원은 프로젝트의 모든 부분에서 작업 할 수 있으며, 개발 프로세스에 내장 된 코드 검토를 수행합니다.

전문화는 괜찮습니다. 큰 코드베이스의 경우 장기적으로 통신 시간을 크게 절약 할 수 있지만 소유권은 그렇지 않습니다.

내 말은, 팀 에 버그가 있다는 태도가 있어야 하고 아무도 "오, X만이 그 코드를 만질 수 있으므로 내 문제는 아니다"라고 말해서는 안된다는 것입니다. 팀의 일원이라면 가능한 한 전체 코드베이스에서 버그를 수정하고 올바르게 수행하는 것도 귀하의 책임입니다. X를하는 것이 최선의 선택 일 수 있지만, 그렇게해야한다면 누구나 그렇게해야합니다. 이것은 자연스럽게 방식으로 작성되는 코드를 필요로 할 수 있습니다 및 초대 함께 작업 팀 구성원. 코드가 불분명 한 경우이를 금지하므로 명확하고 간단한 코드를 사용하면 대부분의 개발자가 코드를 사용할 수 있습니다. 당신은 그렇게 유지 하기 위해 동료 검토와 함께 갈 수 있습니다 .

동의하지 않습니다. 코드베이스의 팀 소유권은 개별 소유권보다 훨씬 더 나은 옵션입니다.

개인 소유에 대한 명백한 단점은 한 직원에게 어떤 일이 발생하면 (해고, 퇴직, 병에 걸리는 등) 실제로 깨끗한 코드를 작성하지 않으면 다른 사람이 그 사람을 채택하는 데 시간이 걸린다는 것입니다 특히 자신의 코드를 관리해야하는 경우

또한 팀 소유권을 쉽게 만드는 도구가 너무 많습니다. 코드 검토, 소스 제어 – 전체 코드베이스에서 팀의 참여를 장려합니다. 또한 코드베이스의 특정 부분을 한 사람에게 어떻게 할당합니까? 이 사람 만이 파일을 수정할 수 있다고 말합니까?

마지막으로, 코드베이스의 한 부분이 깨지면 그 책임을 맡은 사람을 너무 쉽게 비난하고 더 많은 문제를 일으킨다 고 생각합니다.

두 접근법 사이에 긴장이 있기 때문에 둘 다 필요하다고 생각합니다.

코드 조각에 대해 작업 할 수있는 사람이 한 명뿐이라면 회사마다 장기적으로, 특히 개발자가 실패 할 때마다 성장할 때 특히 나쁩니다. 다른 한편으로, 개발자가 코드를 잘 알고 있기 때문에 개발자가 일반적으로 접근 방식 (인센티브)을 선호하기 때문에 개별 코드 소유권 (희망)이 더 빠른 전달 시간을 가능하게합니다. 시간 문제도 있습니다. 가능해야합니다. 비즈니스 요구에 따라 특정 프로젝트에 개발자를 재 할당하지만 매일 수행하는 경우 끔찍합니다 (개발자가 싫어하기 때문에 스위치 비용이 너무 무거워서 대부분의 시간을 할애하는 경우) 아무것도).

관리자의 한 가지 역할 인 IMO는 둘 사이의 균형을 찾는 것입니다. 코드 검토, 코딩 표준, 일련의 툴에 대한 표준화는 장애 문제의 원인을 줄이는 데 도움이됩니다. 결국 유지 관리 가능한 코드의 주요 요점은이 문제를 해결하는 것입니다.

집단 코드 소유권은 개별 코드 소유권보다 비교할 수 없을 정도로 우수하다고 생각합니다.

나는 트럭 인수에 의해 방해받지 않습니다-개별 소유권 모델에서 소유자의 손실은 다른 사람이 인계하는 데 필요한 시간면에서 비싸지 만, 상각 비용이 낮을 정도로 이벤트는 거의 없습니다.

오히려 집단 코드 소유권이 고품질 코드로 직접 이어진다 고 생각합니다. 이것은 매우 간단한 두 가지 이유 때문입니다. 첫째, 고통스런 진실은 일부 프로그래머가 다른 프로그래머만큼 좋지 않다는 것입니다. 코드를 소유하고 있다면 그 코드는 좋지 않습니다. 더 나은 프로그래머에게 액세스 권한을 부여하면 향상됩니다. 둘째, 코드 검토 : 모든 사람이 코드를 소유 한 경우 누구나 코드를 검토하고 개선 할 수 있습니다. 좋은 프로그래머조차도 자신의 장치에 남겨두면 하위 파 코드를 작성합니다.

나는 이것이 현재 프로젝트에서의 경험을 바탕으로 말합니다. 우리는 집단적 소유권을 실천하는 것을 목표로하지만, 시스템의 일부가 전문화되었습니다. 저와 다른 사람은 사실상 빌드 시스템의 소유자입니다. 예를 들어, 들어오는 데이터 피드에서 대부분의 작업을 수행하는 사람이 있습니다. , 이미지 가져 오기 작업을하는 다른 사람 등. 이러한 영역 중 일부 (특히 내 영역에서 고백해야합니다!)에서 코드 품질이 심각하게 악화되었습니다. 팀, 다른 사람들의 관심에서 벗어나지 않는 실수, 오해, kludges 및 해킹이 있습니다.

특정 코드의 소유권이 다른 프로그래머들 사이에서 정기적으로 (예를 들어, 3 개월마다 또는 모든 릴리스, 심지어는 모든 반복마다) 이동하는 개별 코드 소유권을 가지면 집단 코드 소유권의 이점을 얻을 수 있습니다. . 자르기 회전과 동등한 프로그래밍입니다. 재미있을 것입니다. 그래도 직접 시도하지는 않을 것입니다.

여러 기여자가 기본 서브 시스템의 기본 아키텍처를 이해하도록하는 것만 큼 팀 코드 소유권이 중요하다고 생각하지 않습니다.

예를 들어, 우리 팀에는 서버 제품에 대한 관리 웹 페이지를 만드는 두 사람이 있습니다. 우리는 자바 스크립트 나 html에서 바로 서버에서 C 함수를 호출 할 수 있도록 커스텀 서버 측 스크립트 엔진을 만들었습니다. 나는 우리의 "웹"녀석들이 서로 다른 웹 페이지 애플리케이션의 공동 소유자가 아닌이 엔진을 사용하는 방법을 이해하는 것이 더 중요하다고 생각합니다.

코드를 작성할 때 코드를 개별적으로 소유 한 다음 팀에게 넘겨주는 것 같습니다. 이렇게하면 모든 사람이 책임을지고 기여합니다. 모든 사람은 자신이 만든 코딩 실패를 해결해야합니다. 코드 검토와 함께 더 높은 표준을 만듭니다. 아무도 다른 사람들을 쫓아내는 일을 원하지 않습니다.

더 많은 책임과 적은 소유권을 생각하십시오. 결국, 수표를 작성하는 사람은 어쨌든 실제 소유자입니다.

짐, 난 그 100 %에 당신과 함께 있습니다. 저는 제 직장에서 똑같은 전투를 겪고 있습니다. 그래서 저는 당신의 질문을 우연히 발견했습니다.

내가 보는 방식은 : "모두가 그것을 소유 할 때, 아무도 그것을 소유하지 않습니다".

저에게는 코드 품질에있어 소유권과 책임보다 더 중요한 요소는 없습니다.

실생활의 예가 이것을 잘 보여줍니다. 개인 잔디밭이나 지역 사회 공원 중 어느 쪽을 더 잘 관리 하시겠습니까? 꽤 분명합니다.

그건 그렇고, 반드시 "팀 유연성"과 절충되어야 할 필요는 없습니다. 그것은 단지 사람이 무언가를 소유 할 때 그것을 소유하고 있음을 의미합니다.

나에게 그것은 당신의 팀의 역학에 달려 있습니다.

예를 들어, 표준, 동료 검토, 방법 론적 테스트에 의해 통합되지 않은 팀이 있거나 역량 수준이 구성원마다 크게 다른 팀이있는 경우 더 강력한 코드 소유권 개념을 찾는 것이 좋습니다. 더 블랙 박스 모듈 식 사고 방식.

예를 들어, SOLID 원칙을 준수하는 신중하게 디자인 된 인터페이스는 "SOLID"의 의미조차 모르고 "편의성"을 위해 인터페이스에 항상 새로운 절충주의 기능을 추가하고자하는 사람에 의해 망가질 수 있습니다. 이것은 지금까지 최악입니다.

버그를 수정하려는 아이디어가 근본 문제를 이해하지 않고 증상을 수정하는 조잡한 동료를 처리 할 수도 있습니다 (예 : 버그를 숨기고 치명적인 코드를 전달하기 위해 코드에 해결 방법 만 추가하면 충돌 보고서에 응답하려고 함) 다른 사람에게 부작용). 이 경우 인터페이스 디자인 방해물만큼 나쁘지는 않으며 신중하게 구성된 단위 테스트를 통해 의도를 보호 할 수 있습니다.

이상적인 솔루션은 팀을 강화 시켜서 이러한 저작자 및 소유권 개념이 더 이상 중요해지지 않는 지점까지 강화하는 것입니다. 동료 검토는 코드 품질을 향상시키는 것이 아니라 팀워크를 향상시키는 것입니다. 표준은 일관성에 관한 것이 아니라 팀워크를 향상시킵니다.

그러나 동료 검토와 실제로 모든 사람이 표준을 준수하도록하는 시나리오는 절망적이며 절망적으로도 경험이없는 많은 비평가를 혼합하여 활용할 것입니다. 코드 소유권 또는 팀 소유권이 더 높은 우선 순위를 갖는지 여부는 팀이 실제로 효과적인 동료 검토를 수행하고 실제로 모든 사람이 자신이 이익을 얻는 것처럼 (검토 자체의 관점에서) 나갈 수 있도록하는 능력에 따라 결정됩니다 결과적으로 사고 방식과 표준에서 서로 더 가까워짐). 규모가 크거나 느슨하거나 이질적인 팀에서는 희망이없는 것처럼 보일 수 있습니다. 누가 무엇을 썼는지 거의 말할 수없는 "분대"처럼 팀이 기능 할 수 있다면, 독점 소유권은 어리석은 개념처럼 보일 것입니다.

이러한 종류의 원거리 시나리오에서는 이러한 코드 소유권 개념이 실제로 도움이 될 수 있습니다. 최악의 시나리오를 활용하려고 노력하고 있지만 팀워크가 일반적으로 저자의 코드 주위에 울타리를두기를 희망하는 경우 도움이 될 수 있습니다. 이 경우 팀워크가 줄어들지 만 "팀워크"가 발가락을 밟는 것만으로도 더 나아질 수 있습니다.