Kovboy kodlayıcıyı nasıl silahsızlandırıyorsun? [kapalı]


37

Bir soru buldum (takımdaki kod kovboy), ama daha sonra sahip olduğum problem olan "Ninja Coder" ile ilgiliydi.

" Kovboy Kodlayıcı " nın canlı bir örneği olan bir takım üyem var . İnsanların insanları değiştiremeyeceğini biliyorum, ama onu "Kovboy Kodlayıcı" gibi davranmayı bırakmanın bir yolu mu?

Ekibi dinlemeyi reddediyor ve kısa süre önce kod incelemelerini, birim testlerini, uygulama ayrıntılarını paylaşmayı vb. Durdurdu.

Evet, hızlı "kodlar", fakat kodu sadece bir hata üreteci. Diğer ekip üyeleri ve ben bir "hata düzeltme aşamasındayız" ve hataların% 80'i kodundan geliyor. Hatalarını düzeltmek istemiyorum. Ve yönetim kördür, ya da bunu görmek istemiyor, ya da belki "hızını" seviyorlar.

Bu konuda bir şey yapabilmemin bir yolu var mı (yaşına göre genç meslektaşı olarak patronu değil)?

Bu kovboy kodlayıcıyı nasıl etkisiz hale getirebilirim?

Projeyi gerçekten önemseyen son kişi olduğumu hissediyorum.


17
Bu adamın kendi hatalarını düzeltmesi gerekiyor. Neden her geliştiricinin kod incelemeleri yapması gerekmiyor?
programcı

8
Kimin yetkisi altında kod incelemelerini durdurdu?
Otávio Décio

14
Yani ... bunu yöneten bir tane yok. Bu senin sorunun, kovboy kodlayıcısı değil.
Otávio Décio

3
Eğer durum buysa, Scrum hiçbir işlem için iyi değildir. Hepsi sorumlu olduğunda kimse sorumlu değildir ve ürün seyirci etkisinden muzdariptir.
Otávio Décio

7
Ama "yakın iplik" kovboylarını nasıl etkisiz hale getirebiliriz ...
Rig

Yanıtlar:


21

Birkaç seçenek görüyorum:

  • Kodlayıcıya endişelerinizle yaklaşın. Özel noktalarla yapıcı eleştiri olarak yapılmalıdır. Daha büyük adımlar atmadan önce, kişiye değişme fırsatı vermek için doğrudan ve özel olarak endişeleri dile getirmek uygun olacaktır.
  • Bilgi ve istatistik toplayın ve yönetime getirin. Yönetim önemsemiyor gibi görünebilir, ancak yine de çalışması için çabayı göstermek genellikle önemlidir. Muhtemel olumsuz sonuçlar, yönetime şikayetleri takdir etmeyen diğer kişilerin yabancılaştırılmasını içerir.
  • Kovboy kodlayıcıdan bir arkadaş bul ve özel olarak tartış. Kişiyi dinlemesi için daha iyi bir şansı olabilir.
  • Başka bir takımda çalışmak isteyin. Sorunu çözmezsin ama akıl sağlığını koruyacaksın. En azından her zaman elinizden gelenin en iyisini yapın ve sizi aşağı sürüklemesine izin vermeyin.
  • Kimse dinlemezse organizasyonu terk edin. Kötü bir ortam gibi geliyor.

6

Ekibi dinlemeyi reddediyor ve kısa süre önce kod incelemelerini, birim testlerini, uygulama ayrıntılarını paylaşmayı durdurdu ...

Kod incelemeleri, kod yazıcının çalışmayı inceleme için göndermesini gerektirmez.

Yaptıklarını takip etmenin kolay bir yolu VCS tarihine göz kulak olmak ve check-in'lerini aramaktır. Onun kodu hakkında endişeleniyorsanız, bu onu bulmak için kolay bir yoldur. Farklı bir geçmişe sahip olun, neler koyduğuna bakın ve kırmızı bayrakların size atlayıp atlamadığını görün. Girişlerini yeterince hızlı bir şekilde yakalayın ve bir sorun bulursanız, taahhüdünüzü geri alabilir ve bu amaçla e-posta ile gönderebilirsiniz. Açıkça yanlış bir şey gördüğünüzde, takım arkadaşlarınızla, hatta bir kodlayıcı olarak seslenmenize izin verilir.

Evet, hızlı "kodlar", fakat kodu sadece bir hata üreteci. Diğer ekip üyeleri ve ben bir "hata düzeltme aşamasındayız" ve hataların% 80'i kodundan geliyor. Hatalarını düzeltmek istemiyorum. Ve yönetim kördür, ya da bunu görmek istemiyor, ya da belki "hızını" seviyorlar.

Kod gereksinimlerden geliyor. Gereksinimler, gereksinimlerin karşılandığını doğrulayan uygulanabilir testlerle sonuçlanır. Bu testler daha da bozulabilir ve değişikliklerin gereksinimleri karşıladığını doğrulamak için değişiklik yapılmadan önce yazılabilir (kırmızı-yeşil-refactor; TDD'nin özü).

Ekibinizin derleme sunucusuna bir "kod kapsamı" ölçümü ekleyin (umarım bir tane vardır; değilse de, bu sizin ilk sorununuzdur). Basitçe birim testlerinin geçip geçmediğini kontrol etmek, TDDed olmayan yeni kodu ile birim testi olmayan alanlarda yapılan sorunları yakalamayacaktır. Tüm birim testlerini yaptıktan sonra, derleme sunucusunun her kod satırını ideal olarak yürütmüş olması gerekirdi, ancak birim testi yapamayacağınız bazı şeyler var. Gerçekçi olarak, hala% 95 oranında kapsama alanı veya daha fazlasını beklemeniz gerekir (veya bazı kitaplıkları veya dosya türlerini kapsam dışında bırakabilirsiniz). Er ya da geç, kovboyunuz yapıyı bozan bir şeyi kontrol edecek, çünkü eşik seviyenin altına düşmüş ve siz onu çağırıyorsunuz.

Ve "hız" söz konusu olduğunda, hız “işleri” ne kadar hızlı yaptığınızdır ve doğru şekilde yapılıncaya kadar “yapılmaz”. Yöneticilerinize bu şekilde koyabilirsiniz; Müdür, BMW’sini bir yağ değişimi için aldığında, yağ karterinin tekrar takılmasını unutan ve sonuç olarak garajdan çıkmadan önce tüm yeni yağların dışarı akmasını unutan bir otomobil tamircisi düşünün. Elbette, yağ değişimi sadece beş dakika sürdü, ancak müdür otomobilinin motoru eve giderken bunu ele geçirdiğinde bunu umursamayacak. Tamircinin bir basamağı kaçırması, ona düzeltmesi için çok fazla zaman ve paraya mal olacak. Şu anda, işi gerçekten hızlı yapmak için bir kovboy ödüyor, ve sonra ekibin geri kalanına, gelip işi tekrar doğru yapmak için daha büyük bir miktar ödüyor. Gerçekten, kovboyun işini yapmasına izin vermenin avantajı nedir?

Bu konuda bir şey yapabilmemin bir yolu var mı (yaşına göre genç meslektaşı olarak patronu değil)?

Ara onu. Berbat bir şey bulduğunuzda, kodunun nasıl başarısız olduğunu, ilk etapta problemi nasıl önleyebildiğini (uygun tasarım, TDD, kod incelemeleri dahil) ve bunun sonucunda ne yapmanız gerektiğini ya da ne yapmanız gerektiğini gösterin Bozuk kodunu düzeltmek için.

Projeyi gerçekten önemseyen son kişi olduğumu hissediyorum.

klaronslar ışıldıyor, yanıp sönen ışıklar, sirenler fışkırıyor - gerçekten ekibin ürettiği kodun kalitesini önemseyen bir kişi olduğunuzu hissediyorsanız, ciddi bir sorun var. Tüm takımı tekmelemek ve çığlık atmak için iyi kodlama çağına girmeye çalıştığınızı düşünüyorsanız ve çekmek için çok fazla ağırlık var, sonra bırakın. Şirkette doğru şekilde yapan başka bir ekip varsa, transfer isteyin, aksi halde cehennemi çıkarın.


5

Bu geliştiriciden kaç tane böcek / sorun geldiğine dair istatistiklerinizle yönetime gidin. Onlara hatalarını düzeltmenin ekibinizin verimliliğini etkilediğini açıklayın. Sorunların gerçekten% 80'i tek bir kişiden geliyorsa, bunun mutlaka ele alınması gerekir. Yönetime, hemfikir olabilecekleri şekilde (yani, "boşa harcanan para boşa harcanır") açıklarsanız, müdahale edeceklerdir.

Ayrıca, bu geliştirici kendi hatalarını / sorunlarını düzeltiyor olmalı, bu yüzden bu sorunları kendilerine atamak yardımcı olabilir. Ekibiniz bu bir kişiyi korumamalıdır.


4

Bu konuda bir şey yapabilmemin bir yolu var mı (yaşına göre genç meslektaşı olarak patronu değil)?

Akran baskısı ve örnek olarak liderlik tek iyi yoldur. En iyi yollar patronları / liderleri tarafından yapılır. Eğer onların patronu / başrolü değilsen o zaman olanlarla konuş. Ama sonuçta, onların ilgilenmesi onların işi, senin değil. İyi bir iş yaptığınızdan emin olun ve işler kendiliğinden işe yarayacak.


1
Kovboy kodlayıcısı, yönetimin gerçek etkisini anlamazsa, algılanan etkisiyle kör olmuş olabilir.
mhoran_psprep

Hatalarını yönetmeden önce çok iyi savunabilir, böylelikle büyük hatalar veya sorunlar yönetime küçük görünebilir, fakat sonuçta kod mahvolmuş halde kalır. Ve bu yönetimin umursamadığı bir şey.
Adronius

2
@mhoran_psprep - Ah, kesinlikle. Onun başarılı olmasını beklemiyorum ama aynı zamanda olumsuz sonuçlara gelince işleri düzeltmeye çalışmanın daha riskli olduğunu düşünüyorum. Bu konuda devasa bir yaygara yapmak, özellikle OP'nin kovboyla ilgili algıları yanlışsa, dışlanmaya başlamanın hızlı ve kolay bir yoludur.
Telastyn

0

Ekibi dinlemeyi reddediyor ve kısa süre önce kod incelemelerini, birim testlerini, uygulama ayrıntılarını paylaşmayı durdurdu ...

İnceleme, test etme ve uygulama yoluyla kod için belgelenmiş bir yolunuz yok mu? Eğer değilse, daha geniş bir probleminiz var. Bunu yaparsanız, o zaman bu tırmandırılması gereken bir şeydir.


Tabii ki, tonlarca işlem ve belgemiz var. Ama insanlar onları nasıl kullandıklarını anlatıyor .
Adronius

Ancak hiçbir şey, ilgili bir imza almadan, üretime geçmemelidir. Bana normal değişim kontrolünü engellediğini mi söylüyorsun?
temptar

Tam olarak değil, ama bir nevi. Kodda değişiklikler yapar, ardından kod incelemesini yapmak için "resmi" adımları uygular = yalnızca bazı araçları kendisi kullanır, bu nedenle kod "bayrağını" işaretledi "veya eşinden istediği (kodu umursamıyor) kodunu "gözden geçirin". Sonra bir dakika içinde kodu "açıklar" ve yapılır. Huray ve değişiklikleri göndermeye gidiyor.
Adronius
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.