* Kod sahibi * sistemi: verimli bir yol mu? [kapalı]


50

Ekibimizde yeni bir geliştirici var. Bir çevik metodoloji bizim şirkette kullanılıyor. Ancak geliştiricinin başka bir deneyimi var: Kodun belirli bölümlerinin belirli geliştiricilere atanması gerektiğini düşünüyor. Dolayısıyla bir geliştirici bir program prosedürü veya modülü oluşturmuşsa, prosedür / modülde yapılan tüm değişikliklerin sadece kendisi tarafından yapılması normal kabul edilir.

Artı tarafta, sözde önerilen yaklaşımla ortak geliştirme zamanından tasarruf ediyoruz, çünkü her geliştirici kodun bir kısmını iyi biliyor ve düzeltmeleri hızlı bir şekilde yapıyor. Dezavantajı ise geliştiricilerin sistemi tamamen bilmemesidir.

Bu yaklaşımın orta büyüklükte bir sistem için (sosyal ağ sitesinin geliştirilmesi) iyi çalışacağını düşünüyor musunuz?


23
Bu şekilde çalıştım ve sahip olmadığım kodları değiştirmek zorunda kaldım. Kod “benim” olmadığından her zaman birini rahatsız etti ve değişikliklerin kolay olması için kod asla belgelenmedi veya test edilmedi. Sahip olduğum projelerde, hızlı entegrasyonla birlikte grup sahipliğini her zaman teşvik ettim (uzun süreli birleşmeleri önlemek için).
Danny Varod,

26
Bunun bir fikirden ne kadar kötü olduğunu sana yeterince vurgulayamam. Aşağıdaki cevaplar kod sahipliğindeki her şeyi yanlış olarak özetliyor, bu yüzden ekleyebileceğim tek şey kişisel deneyimim: Çalıştığım bir yazılım geliştirme mağazasının, iyi insanlarla çalışmak için harika bir yerden, çok sayıda tembel geliştiricinin bir kabusuna dönüştüğü geliştiriciler ve korkunç sürdürülemez kovboy kodu.
maple_shaft

6
Bu soruyu uzun zaman önce çoktan sordum: programmers.stackexchange.com/questions/33460/…
Jim Puls

7
Kendini yeri doldurulamayacak şekilde kodlamaya çalışıyor gibi görünüyor.
Iain Sahibi

6
Bir açıklama: "prosedür / modülde yapılan tüm değişiklikler sadece onun tarafından yapılacaktır" derken, başka kimsenin o modüle dokunmasına izin verilmeyen anlamına mı geliyorsunuz, yoksa işleri dağıtırken, görevler verdiğimizi mi söylüyorsunuz? Bu modül ile ilgili, eğer mümkünse, önce onu yazan (veya ona aşina olan) programcıya? Bu ince bir fark, ancak sorunun yapısını gerçekten değiştiriyor.
Scott Whitlock

Yanıtlar:


37

Bu soruların çoğu gibi, cevabın şu olduğunu düşünüyorum:

Değişir

Her programcının her kod satırını bilmesi gerektiği pozisyonunu almanın yanlış yönlendirildiğine inanmak için sebep vardır.

Bir an için, bir kod parçasını derinlemesine anlayan birinin, hiç bilmeyen birinden (deneyimime dev bir inanç sıçraması değil) 5 kat daha hızlı bir şekilde değişiklik yapabileceğini varsayarsak, bu yaklaşık bir ay sürer. önemli ölçüde boyutlandırılmış bir modülün (ayrıca mantıksız olmayan) gerçekten iyi bir şekilde anlaşılması için kodlama deneyiminden sonra bazı (tamamen sahte ve kurgusal) sayılar çalıştırabiliriz:

  • Programcı A: derin bir anlayışa sahip
  • Programcı B: yok

Diyelim ki programcı A günde 1 iş yapıyor. 5 iş gününün 4 haftasında 20 birim iş yapabilir.

Bu nedenle, B programcısı, günde 0.2 birimden başlayarak ve 20. gününde 0.96 birim çalışmayla sona erecek (21. günde, programcı A kadar iyidirler), aynı şekilde 11.6 birim çalışacak 20 günlük süre Bu ay boyunca B programcısı, A programına kıyasla% 58 verimlilik elde etti. Ancak, şimdi bu modülü ve birincisini bilen başka bir programlayıcınız var.

Tabii ki, iyi bir büyüklükte bir projede, 50 modül olabilir mi? Bu yüzden hepsine aşina olmanız yaklaşık 4 yıl sürüyor ve bu, öğrenme programlayıcısının, ortalama olarak programlayıcı A ... hmmm'ye kıyasla% 58 verimlilikle çalıştığı anlamına geliyor.

Öyleyse bu senaryoyu inceleyin: aynı programcılar, aynı proje (A hepsini biliyor ve B hiçbirini bilmiyor.) Diyelim ki yılda 250 iş günü var. İş yükünün 50 modül üzerine rastgele dağıtıldığını varsayalım. Her iki programlayıcıyı eşit şekilde bölersek, A ve B'nin her ikisi de her modülde 5 iş günü alır. A her modülde 5 ünite iş yapabiliyor, ancak B sadece küçük Excel simülasyonuma göre, her modülde 1.4 ünite iş yapıyor. Toplam (A + B), modül başına 6.4 iş birimidir. Bunun nedeni, B zamanlarının çoğunu üzerinde çalıştıkları modülle ilgili herhangi bir beceri olmadan geçirmektir.

Bu durumda, B'nin daha küçük bir modül alt kümesine odaklanması daha uygun olur. Eğer B sadece 25 modüle odaklanırsa, her birinde 10 gün ve her birinde toplam 3.8 ünite çalışır. Programcı A daha sonra B'nin çalışmadığı 25 modülde 7 gün, her biri 3 gün B ile aynı günde çalışabilir. Toplam verimlilik, modül başına 6.8 ila 7 ünitedir ve ortalama 6.9'dur. A ve B işleri eşit bir şekilde yayarken modül başına 6.4 üniteden daha fazlasını yaptık.

B'nin çalıştığı modüllerin kapsamını daralttıkça daha da verimli oluyoruz (bir noktaya kadar).

Eğitim

Ayrıca, bir modül hakkında çok fazla şey bilmeyen birinin, daha fazla deneyime sahip birinden çok daha fazlasını yapan kişiyi rahatsız edeceğini savunuyorum . Bu yüzden yukarıdaki rakamlar, B'nin anlamadıkları kodlara daha fazla zaman harcadıklarını, soru sorarak A'nın daha fazla zaman harcadıklarını ve bazen A'nın, B'nin yaptıklarını düzeltmek veya sorun gidermek zorunda kaldıklarını hesaba katmamaktadır. Birini eğitmek zaman alıcı bir faaliyettir.

En uygun çözüm

Bu yüzden optimal çözümün aşağıdaki gibi sorulara dayanması gerektiğini düşünüyorum:

  • Ekibiniz ne kadar büyük? Herkesin her alanda çapraz eğitim almasını sağlamak mantıklı mıdır veya 10 kişilik bir ekibimiz varsa, her modülün en az 3 kişi tarafından bilindiğinden emin olabilir miyiz? (10 programlayıcı ve 50 modül ile her programcının 3 kat kapsama alanı elde etmek için 15 modül bilmesi gerekir.)
  • Çalışanların cirosu nasıl? Çalışanları ortalama her 3 yılda bir devredecekseniz ve sistemin her köşesini gerçekten bilmek, bundan daha uzun sürüyorsa, eğitimin geri ödeyebilmesi için yeterince uzun sürmezler.
  • Bir problemi teşhis etmek için gerçekten bir uzmana ihtiyacınız var mı? Pek çok insan "ya o tatile giderse" bahanesini kullanıyor, ancak deneyimlediğim bir sistemde bir problemi teşhis etmek için defalarca çağrıldım. Deneyimli kişinin onu daha hızlı bulabileceği doğru olabilir, ancak onlarsız ya da iki hafta yaşayamayacağınız anlamına gelmez. Birkaç yazılım sistemi o kadar kritik öneme sahiptir ki, problem 5 saat yerine 1 saat içinde teşhis edilmek zorundadır, yoksa dünya sona erecektir. Bu riskleri değerlendirmek zorundasınız.

Bu yüzden "bağlı" olduğunu düşünüyorum. 20 modülün iki programlayıcı arasında tam ortasından aşağıya bölünmesini istemezsiniz (her biri 10'ar), çünkü o zaman esnek olmuyorsunuz, ancak 50 programın tamamında 10 programlayıcıyı geçmek istemiyorsunuz çünkü çok fazla kaybediyorsunuz verimlilik ve bu kadar fazlalığa ihtiyacınız yok.


3
Bazı insanların bazı parçaları diğerlerinden daha iyi tanımaları doğaldır. Ancak “mülkiyet” kavramı, diğer kişilerin bu koda izinsiz olarak dokunmaması gerektiği veya yalnızca sahibinin kesin bir şekilde söyleyeceği anlamına gelir ve bu çok ileri gider. Açıkçası evet, "demek istediğin şey buysa" değişir.
poolie 14:11

1
@poolie - Katılıyorum ama bu kesilmiş ve kurutulmuş olup olmadığını bilmiyorum. Mülkiyet gerçekten "dokunmamalı" anlamına mı geliyor? Buna ikna olmadım. Belli bir kod parçasında "bu, nihai otoriteye sahip olan kişi" anlamına geldiğini düşünüyorum. Burada birden fazla sorun var ... ama sanırım sorunun kökeni, programcılara görev vermekle ilgili değil, bazı programcıların belirli kod üzerinde çalışmasına izin vermemek değil. "B programcısı bu kod üzerinde çalışmamalıdır" demek aptalca.
Scott Whitlock

Bence mülkiyet , bir kod parçasıyla çalışmak için en yüksek öncelik anlamına geliyor . Eğer A programcısı serbestse ve en yüksek kaliteye sahipse, parçası ile çalışmaya başlamalı, ancak B programcısı bunu yapmamalıdır.
sergzach 14:11

76

Bu korkunç bir fikir . Kısa vadede daha hızlı olabilir, ancak yanlış belgelenmiş zor kodları, yalnızca onu korumaktan sorumlu olduğunu yazan kodlayıcı olarak teşvik eder. Birisi şirketten ayrıldığında ya da tatile gittiğinde, bütün plan kapatılır. Aynı zamanda iş yükü tahsis etmeyi de zorlaştırmaktadır; İki acil hata bir kodlayıcı "sahip" kodunu bulduğunda ne olur?

Takım olarak kod yazmalısın . İnsanlara doğal olarak görevler verilecek ve belirli alanlara odaklanılacak, ancak iş yükünü paylaşma ve birlikte çalışma cesaretlendirilmemeli, teşvik edilmelidir.


5
Takım olarak çalışmayı prensip olarak kabul ediyorum, ancak pratikte insanlar çalışmaları hakkında sahiplenme hissine sahip olduklarında daha iyi görünüyorlar, “o kodu değiştiremezsiniz, benim!" Bu yüzden çalıştığım yerde ekip projeleri yaparken, bireysel geliştiriciler kodun belirlenmiş bölümlerini tamamlamaktan sorumludur.
Robert Harvey,

1
Kod sahipliğinin en büyük sorunlarından biri seri hale getirmedir. İşin% 90'ı bir kişinin alanı içinde yattığı zaman ne olur? Takımın geri kalanının başparmaklarının üstüne oturması ve beklemesi mi gerekiyor?
Neal Tibrewala

5
Çalıştığım yerde, birisinin (veya bazı grupların) sahip olduğu kod bölümleri var, ancak bu dosyalara dokunanlar sadece onlar değil. Herkesin her şeyi bilmesi için çok fazla kod var, bu yüzden insanlar belirli alt sistemlerde uzmanlaşıyor ve bazı sistemlerde daha büyük ölçekli tasarım kararları almaktan ve bunlardan haberdar olmaktan sorumlu, ancak başkaları için nadir olmayan ve gerektiğinde daha küçük hızlı değişiklikler yapmaktan sorumlu değiller.
Alex

3
@Robert Harvey: Takım tüm koda sahip.
Steven A. Lowe

2
"korkunç fikir" çok güçlü. Linux çekirdeği bu modeli kullanıyor ve görünüşe göre iyi çalıştı.
Joh,

28

Sorunun etki alanının ne olduğuna bağlı.

Genel bir şeyse (yani basit CRUD eylemleri, vb.), O zaman Tom Squires ile aynı fikirdeyim (herkes üzerinde çalışmalı ve onu düzeltebilmelidir).

Ancak ...

Söz konusu çözüm alan uzmanlığı gerektiriyorsa (geçmişe çok fazla zaman harcanmıştır veya uygulamadan önce çok fazla araştırma yapılması gerekmektedir, çünkü bu, bir iş gereksiniminde uzmanlaşmış bir bilgi olarak listeleyeceğiniz bir şeydir. Projedeki herkesin değil), bir sahibinin kesinlikle kodun bu bölümüne atanması gerekir . Bunu söyleyen, herhangi biri gerektiğinde üzerinde değişiklik yapabilmeli, ancak projenin o alanına sahip olan kişi tarafından her zaman gözden geçirilmelidir.

Tüm ekibinizin (veya ekipteki bazı kişilerin) aynı konuyu araştırıp öğrenmesini (boşa harcanan döngüleri) istemezsiniz. Bir sahip atayın, ancak öğrendiklerini ve tasarımlarını belgelemelerini sağlayın ve belki de teknoloji hakkında gayrı resmi (veya resmi, gerçekten önemli değil) eğitim oturumları yapmalarını sağlayın.


2
Kenar davaları hakkında iyi bir nokta. +1
Tom Squires

1
@Danny: Yayını tamamen okuduğunu sanmıyorum. Herhangi birisinin sahibi tarafından incelendiği sürece kod üzerinde değişiklik yapması gerektiğini söyledim. Ayrıca, etki alanı uzmanının bilgilerini resmi ya da resmi olmayan eğitim oturumlarıyla paylaşması gerektiğini önerdim.
Demian Brecht

Üzgünüm, yorgundu ve bu kısmı kaçırdı.
Danny Varod

+1 Bu, farklı mülkiyet seviyelerinin projeye bağlı olarak yararı olabileceğini gösteren tek cevap olduğunu düşünüyorum.
Thomas Levine

1
Bunu gerçekten mülkiyet olarak görmüyorum. Kod incelemeleri doğal (evet, doğal) ve belirli bir alt sistemdeki en uzman geliştiricinin bu alt sistemdeki değişiklikleri gözden geçirmesi de doğal.
Matthieu M.

10

Bu korkunç bir fikir . Bu yaklaşımı kullanan bir şirkette çalıştım ve teknik borç yığınları için bir reçete . Sonuç olarak, iki kafa neredeyse her zaman birinden daha iyidir. Neden? Çünkü sen bir aptalsan, mükemmel bir programcı olmadığını biliyorsun ve yaptığın her hatayı yakalayamayacaksın. Bu yüzden bir takıma ihtiyacınız var - aynı koda farklı açılardan bakan daha fazla göz.

Disipline : Tek bir şey kaynıyor . Kodlama tarzında kimin gerçekten disiplinli olduğunu yalnızca kaç tane yalnız programcı tanıyorsunuz? Disiplin kodunu yazmazsanız, kısayollar kullanırsınız (çünkü "daha sonra düzeltirsiniz") ve kodun sakıncası vardır. Hepimiz biliyoruz ki "daha sonra" asla gelmez. Bilgi : Bir takımdaki meslektaşlarınıza derhal hesap verirken kısayollar almak daha zordur. Neden? Çünkü kararlarınız sorgulanacak ve kısayolları doğrulamak her zaman daha zor. Sonuç? Aynı zamanda daha sağlam olan daha iyi ve daha iyi korunabilir kodlar üretiyorsunuz.


9

Bunun avantajı, herkesin her şeyi araştırması ve anlaması gerekmemesidir. Dezavantajı, her bir insanı kendi kod alanı için gerekli kılan ve başka hiç kimsenin onu nasıl koruyacağını bilmediğidir.

Bir uzlaşma, her bir kod alanı için en az 2 mal sahibine sahip olmak olacaktır. Sonra biri tatile gidebilir, yeni bir işe girebilir veya emekli olabilir ve hala kodu bilen biri (ve yeni ikinci kişiyi eğitebilir) vardır. Herkesin her şeyi öğrenmesi gerekmez, bu biraz daha verimlidir.

Her zaman aynı 2 (veya 3) insanın birlikte çalışması gerekmez. Farklı alanlar için çiftler kullanın, böylece ilgili program alanında farklı bir kişiyle çalışırken de bilgiler yanlışlıkla paylaşılır.


1
Veya başka bir deyişle, XP :-)
Ediyorsunuz Danny Varod

6

Evet, kısa vadede biraz daha verimli. Ve faydaları bitiyor. Bu maliyete ağır basmaya bile yaklaşmıyor.

Tatildeyken veya beklenmedik bir şekilde hastalandığında, ayrıldığında veya meşhur otobüse çarptığında ne olur? Bir işi diğerinden daha hızlı yapmak için kaynakları esnetmek istediğinizde ne olur? Kod incelemeleri ne kadar etkili olabilir? Özellikle kod bazında olmayan bir yönetici, geliştiricinin çok çalıştığını veya yününü gözlerinin üzerine çekip çekmediğini nasıl bilebilir? Teknik borç çalışmaya başlarsa kim fark edecek?

Tecrübelerime göre, bu şekilde çalışmayı seven insanlar en iyi ihtimalle en iyi zafer avcısı, en kötüsü de tembel. Belirli bir problemle gidebileceğiniz tek kişi olmayı seviyorlar ve kodlarının gizli kalmasını istiyorlar. Ve genellikle okunabilirlikten bağımsız olarak hızlı şekilde kodlamayı severler.

Bu, 50 geliştiriciden oluşan bir ekipte herkesin tüm kodu bilmesi gerektiği anlamına gelmez, ancak 5-7 kişilik bir ekibin, bu insanları çalıştıracak kadar büyük bir modüle sahip olması gerekir. Hiçbir birey hiçbir şeye sahip olamaz.


Kod tabanının boyutuna ve kapsamına bağlı olduğunu söyleyebilirim. Birkaç yüz milyon çizgiyi vurduğunuzda, kesinlikle "tek bir insanın kafasında her şeyi bulabilir" alanının dışındasınız ve birincil sorumlulukları paylaştırmaya başlamanız gerekecek.
Vatine

1
@Vatine: Doğru. Böylece kodunuzu modüllere ayırır ve her modül üzerinde çalışan bir ekibiniz olur. Hala bir kişinin sahip olduğu bir kod parçanız yok.
pdr 11:12

Evet, onu tek kişilik kişilere (muhtemelen) ayırmak mantıklı değil, ama kesinlikle "kod tabanının farklı bölümleri için farklı mülkiyet" için bazı argümanlar var.
Vatine

6

Diğer cevapların işaret ettiği en az üç konu var; ama ikisine de birlikte davranmayı denemek isterim. İki konu:

  • Uzmanlık : Takımdaki biri belirli bir alan hakkında detaylı bilgiye sahiptir; bu bilgi projede o alanın spesifik uygulamasından bağımsızdır
  • liderlik : Her ne kadar proje oluşturma çalışmaları birçok geliştirici arasında paylaşılabilse de; Yol haritasının yanı sıra önemli uygulama detaylarıyla ilgili acil kararlar belirli bir ekip üyesinin veya ekibin yalnızca birkaç üyesinin elindedir.
  • egoless code : Projenin uygulanma yolu, takımdaki herhangi bir geliştiricinin kodlama stillerine, uygulamalarına veya bilgisine bağlı değildir; ve iyi bilinen bir kodlama stiline veya iyi yönlendirilmiş bir spesifikasyona sıkı sıkıya bağlı kalarak, herhangi bir yeni ekip üyesi, projenin nasıl ve niçin deneyimli dev olarak olduğunu anlama konusunda eşit şansa sahip.

Konu tamamen uzmanlık alanlarından biriyse, projenin başarısı etki alanı hakkında yüksek düzeyde bilgiye bağlı olabilir; ancak belirli bir uzmanın o alan hakkındaki bilgisine bağlı değildir. Uzmanlar, belki nadir ve değerli olsalar da, esasen birbirleriyle değiştirilebilirler; Tecrübeli vergi muhasebecisi, bir vergi planlama yazılımı projesine, alan bilgisi açısından bakıldığında, bir diğeri kadar yararlıdır. Mesele, uzmanın bilgilerini projeye aktarabilmesinin en iyi yönlerinden biri haline geliyor.

Konu tamamen liderlerden biri olduğunda, projenin başarısı temel olarak proje liderinin verdiği kararların tutarlılığına ve içgörüsüne bağlıdır; Alanında deneyime sahip olan veya proje liderleri olarak kanıtlanmış proje adaylarını destekleme eğiliminde olsak da, bu bazen rol için ikincildir. "Lider", alınan kararların bir davadan diğerine tutarlı olması ve her kararın ekip tarafından hızlı bir şekilde yapılması durumunda günden güne değişebilir. Bu doğru çalışıyorsa; Pek çok kararın proje lideri tarafından “alınması” gerekmez, çünkü takım hangi kararların alınacağını zaten bilir.

Sorunun gerçekten kuralsız kodla ilgili olduğunu sanmıyorum, ancak bu konunun ne kadar önemli olduğunu tartışmadan kod sahipliği hakkında konuşmak zor. Bir projeyi sürdürmek, muhtemelen geliştirme döngüsünün en büyük kısmıdır. Bu konuyu anlamanın yolu, geliştiricilerin bazıları derhal terk etmek zorunda kalsa ne olacağını merak etmektir. Tüm takımın değiştirilmesi gerekirse ne olur ? Eğer proje bazı kilit oyunculara bağlı olduğu için şüphede bulunursa, o zaman yüksek bir başarısızlık riskiyle karşı karşıyasınız. Tek bir ekip üyesini asla kaybetmeseniz bile, projeyi ilerletmek için bir veya birkaç geliştiriciye ihtiyaç duyulması gerektiği gerçeği, daha fazla geliştiricinin ilgisini çekerse, elinizden geldiğince verimli çalışamayacağınız anlamına gelir.


6

Kod mülkiyeti, yeniden yönetilmeyi önleme, geliştirme darboğazları oluşturma ve kodun ele alınması gereken sorunları olduğunda ego sorunlarına neden olma eğilimindedir.

Yüksek standartlı kodun yeterince belgelenmesi, birim testinin yapılması, entegrasyon testlerinin yapılması ve sistemin gereksiz hale getirilmesi için test edilmesi gerektiğinden, değişiklik yapmadan önce kod yazarlarına danışmanızı tavsiye ediyorum.


5

Bu, pek çok nedenden dolayı kötü, bundan daha makul bir şeyle değiştirmeye çalıştıkları bir dükkanda çalıştım ve çirkindi.

Bunun kötü olmasının sebepleri:

  • Kod sahibi tatil yaparsa ve bazı büyük böcek eşyalarında açılırsa, kodu öğrenmeye çalışmak ve hatayı düzeltmek çok zaman alıcı ve zor olacaktır.
  • Kod sahibi şirketten ayrılırsa, tüm miras ve kabile bilgileri kapıdan çıktıktan sonra projeleri ciddi şekilde geri çekilecek
  • Belgeler zayıf. Kodlayacak tek kişi benim ise niye belgeleyim ki? Bununla ilgili olarak, oluşturulması zorunlu olan herhangi bir belgenin de muhtemelen zayıf olacağı, çünkü kod hakkında bir dokümantasyonun eksiksiz veya doğru olup olmadığını gerçekten kimse yeterince bilmeyecektir.
  • Kod kutsal savaşlar, herkes kendi küçük kum havuzuna sahip olduğunda kolayca tutuşabilir, çünkü diğerleri dediği gibi, gerçekten çok çabuk aptallaşabilir. Bunun bir problem olduğu yerde, iki insan birlikte çalışmak zorunda kaldıklarında, hiçbir zaman hiçbir şeyden ödün vermek için kullanılmazlar.
  • Yukarıdaki noktadan ötürü, takım çalışması becerileri asla oluşmaz - insanlar asla başkalarıyla çalışmak zorunda kalmazlar.
  • Fightdom'lar kolayca şirket kurabilir, şirkete hiçbir şey almayan atık ceplerinden küçük krallıklar oluşturabilir. Sen modül veya aracı X Bob ne yaptığını bile araştırmalıdır sana Bob sorumluluğundadır ve keder olduğu için çok geç olana kadar bu oluyor bilmiyorum onun kod.
  • Kod incelemeleri ve meslektaş değerlendirmeleri, hiç kimse kod hakkında hiçbir şey bilmediğinden acı çekiyor. Kodu bilmiyorsanız, doğru olmayan ve yalnızca metin biçimlendirme ve adlandırma kurallarına yorum yapmakla sınırlı olan yerleri tespit edemezsiniz.
  • Ve eğer benim için çalışıyorsan ... şirket şifreye sahip, sen değil. Yaptıklarımızdan ve başardıklarımızdan ve yazdıklarımızdan gurur duyuyoruz, ancak takımınızın zor bir maç kazandığı zamanki gibi bir grup işi. Şirket için çalışan herhangi bir çalışan, eşit olarak kodun kendisine sahiptir ve işlerini yaparken, şirketin hedeflerini ilerletmek için işlerini yapmak için istedikleri şekilde düzenlemelerine izin verilir.

Bunlardan en büyüğü, personel sorunları ve dokümantasyondur. O kişi bir gün ayrılacak ve oğlan birkaç haftalığına programı sola doğru iteceksin.

Daha iyi bir yaklaşım, herkesin kod tabanının (veya yarım düzine kadar parçanın veya çok büyük ve farklı olması durumunda) her bölümüne aşina olmalarını sağlamaktır.

  • Bu bölgedeki herhangi bir hatayı düzeltin
  • Küçük veya orta düzeyde yeni özellikler veya geliştirmeler ekleyin

Her insan bazı şeyler hakkında diğerlerinden biraz daha fazla şey bilmeye meyillidir, bu yüzden iki ya da üç kişinin birlikte yaşayabileceği zor problemler için ya da defacto uzmanı bunu başarabilir. Durumun olduğu gruplar halinde çalıştım ve gerçekten çok iyi sonuç verdi. Sadece yukarıda sıralanan eksilerden hiçbiri yoktu, uzmanlar için avlanmadığımız için personel çok daha öngörülebilirdi.

Tek başına kod sahibi olma özelliği, "kod sahibinin" muhtemelen diğerlerinden daha hızlı şeyler yapabileceğidir, ancak bu yalnızca herkes çakışmayan projelerde bir "kod sahibi" olduğunda geçerlidir. Başka bir deyişle, insanlar "tek kod sahibinin" avantajı etrafında dönerse ortadan kaybolur.


2
Savunmadığım ve sanırım nadir olduğunu düşündüğüm bir tür ciddi silodan bahsediyorsun. Hâlâ bir ekibin bir parçası olduğunu anladığı sürece, birine bir görev vermesi ve onunla çalışmasına izin vermesi hiç sorun değil. Bu, mağazanın programlama standartlarını ve uygulamalarını takip etmesi gerektiği ve genel olarak kodunu kendisinden sonra saklayacak kişiye kibar davranması gerektiği anlamına gelir. Bu, ekibin kodunun nasıl çalıştığını da anlamalı ve kaynak kontrol sistemi aracılığıyla ona tam erişime sahip olması gerektiği anlamına gelir, böylece bir başkası gerektiğinde "mülkiyeti" devralabilir.
Robert Harvey

5

Bkz Kamyon Numarası aka Otobüs Faktörü

otobüs faktörü ( araç faktörü olarak da bilinir veya otobüs / araç numarası ), bireysel ekip üyelerindeki bilgi konsantrasyonunun bir ölçümüdür. Veri yolu faktörü, projeyi devam etmeyecek şekilde kargaşaya yollamak için yetersiz kalması gereken (bir otobüs / kamyonun çarpması gibi) yetersiz anahtarların toplam anahtar sayısıdır; Proje, kalan hiçbir ekip üyesinin aşina olmadığı bilgileri ( kaynak kod gibi ) tutacaktır. Yüksek veri yolu faktörü, projenin mutlaka başarısız olması için birçok geliştiricinin kaldırılması gerektiği anlamına gelir.

“Bir otobüse çarpmak” birçok farklı şekilde olabilir. Bu, yeni bir işe giren, bebeği olan, yaşam tarzını veya yaşam durumunu değiştiren veya kelimenin tam anlamıyla bir otobüse çarpan bir insan olabilir: etkisi aynı olurdu ...


Kaynağın tarihsel önemi göz önüne alındığında, yetkili olduğunu hissettim. en.wikipedia.org/wiki/WikiWikiWeb , Bus Factor'un yaklaşık 4 yıl boyunca yaygın şekilde kullanılmasını öngörüyor gibi görünüyor.
Joshua Drake

1

Birçok şeyde olduğu gibi, bu büyük bir "bağlı" dır. Sıkı bir "kod üzerinde başka kimse çalışamaz" ise, muhtemelen kötüdür. Eğer "bir değişiklik yapmadan önce mal sahibi kod incelemesi yapmalı" ise, mal sahibinin harici değişikliği kabul etmesine ne kadar istekli olduğuna bağlı olarak iyiye karışır.


1

Dezavantajı şiddetlidir; Takımınızın "kamyon numarası" hemen hemen 1 olur.

İncelemek için, "kamyon numarası" basitçe "takımın kaç kritik üyesi olmak için gerekli bilginin takıma kaybedilmesi için kaç takımın en kötü durumunun bir kamyonetin çarpabileceği" olarak tanımlanır.

Geliştiricilerin alt disiplinlere odaklanmaları doğaldır ve biraz teşvik edilir; Eğer herkes projeyle ilgili her şeyi bilmek zorunda olsaydı, hiçbir şey olmazdı çünkü herkes başkalarının ne yaptığını, neden çalıştığını ve kırılmadan nasıl değiştirilebileceğini öğreniyor olacaktı. Ek olarak, eğer devler farklı alanlara farklı şeyler yapıyorlarsa değişikliklerin çarpışması olasılığı daha düşüktür. Bu nedenle, genellikle projenin belirli bir alt sisteminde çalışan ve bunu iyi tanıyan iki veya üç geliştirici veya dev çiftin olması genellikle iyidir.

Ancak, yalnızca bir kişinin belirli bir kod satırına dokunması gerekiyorsa, o zaman bu adam istifa eder, kovulur, tatile çıkar veya hastanede son bulur ve bu kod satırı bir hatanın nedeni olarak gösterilir. düzeltilmesi gerekiyor, başkasının girmesi ve kodu anlaması gerekiyor. Yazan adam dışında başka kimse görmediyse, geliştiricinin hatayı düzelten değişiklik yapmadan daha fazlasını yapmadan değişiklik yapmasına izin veren bir anlayış seviyesine ulaşmak zaman alacaktır. TDD yardımcı olabilir, ancak yalnızca geliştiriciye "yanlış" bir değişiklik yaptığını söyleyerek; Yine geliştirici, hangi testlerin hangi kodu kullandığını, başarısız testlerin yanlış iddialarda bulunmaya çalışmadığından emin olmak için anlamalıdır.


1

Ben aşırıya kaçmıyorum ama kod sorumluluğunu tercih ediyorum . Bozuk kod yazarsın, düzeltmelisin. Bu bireysel, çift veya takım düzeyinde yapılabilir. Pisliğini temizlemek için başkasına vermeyi önler. Bu aynı zamanda değişiklikler için de geçerli.

İş yükü ve zamanlama sorunları bunun üzerine yazacaktır. Suçlu iki haftalık bir tatildeyken, büyük bir hatayı tamir etmekten vazgeçmek aptallık olur.

Amaç, ekibinizin "suçlama oyunu" nu oynamasını ya da çok fazla hata yapmamasını sağlamaktır (Her halükarda eşit değillerdir.). En son kodu kontrol eden veya bir denetçinin karar vermesini ve her kod satırının her bölümünden geçmek yerine birisine vermesini isteyin.

Daha iyi programcılar muhtemelen nasıl atadığınıza bakılmaksızın birçok başka insanın kodunu düzeltir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.