“Hedef Yönlendirme” kodunun bir Geliştirme Yöneticisi tarafından nasıl ele alınması gerekir?

Önce bir terim yazmama izin ver:

kod hedef eğilimi: Sabah kodu kontrol etme, ardından diğer geliştiriciler tarafından önceki gün dosyada yapılan tüm değişiklikleri sessizce gözden geçirme (özellikle başlangıçta geliştirdiğiniz kod dosyaları) ve biçimlendirme, mantık, değişkenleri yeniden adlandırma, yeniden düzenleme ve VCS'deki değişiklikleri taahhüt eder.

Bu uygulama, tanımladığım birkaç artı ve eksiye sahip olma eğilimindedir:

• Pro : Kod kalitesi / okunabilirliği / tutarlılığı genellikle korunur
• Pro : Bazı hatalar, diğer geliştiricinin orijinal koda çok aşina olmaması nedeniyle düzeltildi.
• Con : Genellikle hedefe yönelten geliştiricinin zaman kaybıdır.
• Con : Bazen , önceki gün hatasız kod yazdıklarını düşünen geliştiriciler tarafından saç çekme öfkesine neden olan hatalar ortaya çıkıyor.
• Con : Diğer geliştiriciler aşırı nitpick ile ağırlaşıyor ve hedef-ihale koduna katkıda bulunmaktan hoşlanmamaya başlıyor.

Feragatname: Adil olmak gerekirse, aslında bir geliştirme yöneticisi değilim, aslında "hedef eğilimi" yapan geliştiriciyim.

Savunmamda, bunu iyi bir sebeple yaptığımı düşünüyorum (son derece büyük kod tabanımızı iyi yağlanmış bir makine tutmak için), ancak olumsuz bir atmosfer yarattığından çok endişeliyim. Ayrıca kesinlikle müdürümün bu sorunu ele alması gerekeceğinden endişe duyuyorum.

Eğer yönetici olsaydınız, bu sorunu nasıl çözersiniz?

GÜNCELLEME: Bunun çok lokalize olmasını kastetmiyorum, ancak bazıları sordu, bu yüzden belki de bazı arka plan aydınlatıcı olacak. Üç yıl önce dev bir proje (200K LoC) atandı ve sadece yakın zamanda (1 yıl önce) projeye, bazıları mimariye aşina olmayan, hala dili öğrenen (C #) ek geliştiriciler eklendim. Genel olarak ürünün genel kararlılığına cevap vermek zorundayım ve özellikle kod tabanının temel mimari kısımlarında şaşırtıcı bir şekilde değişiklikler yapıldığında gerginim. Bu alışkanlık ortaya çıktı çünkü ilk başta diğer geliştiricilerin katkıları konusunda iyimserdim, ancak haftalar öncesine kadar keşfedilmeyecek ciddi sorunlara neden olan, parmağın kararsız kod yazmak için bana işaret edeceği çok fazla hata yaptılar. Genellikle bunlar "

Yaptığınız şeyin temel olarak bir kod incelemesine eşdeğer olduğu anlaşılıyor, ancak geliştiriciye geri bildirim sağlamak yerine bir kod incelemesinde önerebileceğiniz tüm değişiklikleri yapıyorsunuz. Siz (veya bir başkasının) orijinal geliştiriciye kod kalitesi sorunları ve açık hatalar hakkında geri bildirim sağladığı ve orijinal geliştiriciden bunları düzeltmesini istediği gerçek bir kod incelemesi yapmak neredeyse kesinlikle daha iyi olur. Bu, kod kalitesini yükseltir ancak geliştiricinin orijinal kodu ve tuzaklarını daha iyi tanımasına yardımcı olur ve gelecekteki kod değişikliklerini geliştirmeye yardımcı olur. Ayrıca, bir hata sessizce tanıtıldığında veya diğer geliştiricilerin arkalarından bahsedildiğini düşünmelerine neden olduğunda "saç çekme öfkesine" neden olmanın dezavantajı yoktur.

Dürüst olmak gerekirse, IMHO, bu korkunç bir fikir.

Henüz olmasa moralin oluğa düşmesini beklerdim.

Size karşı dürüst olmak gerekirse, bunu kabul ediyorsunuz.

Akran kodu incelemeleri gayet iyi, bir "onları bize karşı" senaryosu olmak yerine, tüm devs üzerinde bir düzeyde onus koyar. (yönetim / potansiyel müşteriler).

Bazı geliştiriciler olabilir diğerlerinden daha fazla göz kulak gerekebilir, ancak battaniye ilk tüm kod senin içinden gelmeye zorlamak saçma.

Ve ne kadar iyi olduğunuzu düşündüğünüze rağmen, yanlış olduğunuz zamanlar ya da “nit toplama” olacaktır ve bu sadece işleri daha da kötüleştirecektir.

Yönetici olsaydım, bu sorunu çözmek için:

• Kod standartlarını ve uygulamalarını ekiple birlikte inceleyin, onlara kodlama standartlarının bir kopyasını verin
• Uyulması gereken standartları ve uygulamaları güçlendirmek için düzenli olarak akran değerlendirme kodu
• Geliştiricilerin standartları takip etmek zorunda kalmaları için niteleme / biçimlendirmeyi bir otomasyon aracıyla uygulayın
• Standartlara uymayı reddeden kötü takım arkadaşlarından kurtulun
• Goaltender olmayı bırak

Niyetleriniz iyi, ama uygulama korkunç ve diğerlerinin de belirttiği gibi, ekip üyeleri arasında moral ve keskin nişanlamaya neden olacak.

Projenin başlaması için hiç standardı olmadıysa, sadece bir anahtarı çevirmek yerine yeni standardı aşamalı olarak hafifletmeye çalışın.

Kötü juju.

Ben bir geliştirme yöneticisi değilim, ama olsaydım geliştiricilerimin kendilerine atanan bir kusurun veya özelliğin bir parçası olmayan koda dokunmasını istemezdim. Dönemi. Başka birinin kodu ile ilgili bir sorun görürseniz, bütün araçlar geliştirici (ler) sorumlu dikkatine getirmek o zamana kadar, ama yok sadece dalış ve (diğer geliştirici ile koordine değil, özellikle eğer bunu kendiniz düzeltmek s) önce.

Temizleme görevleri yalnızca ekip tarafından resmi bir kod incelemesi yapıldıktan sonra ve yalnızca bu görevlerin atandığı geliştiriciler tarafından gerçekleştirilmelidir.

Girişim genel olarak iyidir, ancak bazen sizi kıçından ısırır. Ne herhangi bir hata tanıtmak olursa edildi çalışma koduna, hızla farklı bir kariyer yolu seçmişti isteyen olabilir.