Kod gözden geçirme ve birim test uygulamalarını geliştirme

Kod inceleme ve birim testinde deneyimi olmayan (ve gerek görmeyen) bir grup geliştiriciyi yöneten bir ekip lideri olarak, kod inceleme ve birim test uygulamasını nasıl geliştirebilirsiniz?

Kod incelemesi ve birim testinin geliştiricinin akışına doğal olarak uyması için nasıl bir yol oluşturacaksınız?

Bu iki alanın direncinden biri "her zaman dateline sıkı sıkıya bağlıyız, bu yüzden kod inceleme ve birim testi için zaman yok".

Kod incelemesi için bir başka direnç, şu anda nasıl yapılacağını bilmememizdir. Her check-in sırasında kodu gözden geçirmeli miyiz yoksa kodu belirtilen bir tarihte mi gözden geçirmeliyiz?

Ekip üyeleriniz aslında kod incelemelerinin ve birim testlerinin İyi Şeyler olduğu konusunda hemfikir mi, sadece bunlar için zaman yok mu?

Yoksa sadece bu bahane ile fikri reddetmeye mi çalışıyorlar?

İlk durumda, çözüm Şimdi Yapmaya Başlamaktır . (Tamam, eğer önemli bir kilometre taşından önceki son günlerde iseniz, belki sonraya kadar bekleyebilirsiniz - ama daha fazla değil.) Bu durumu, Kalite Mühendisi olduğum önceki bir işyerinde kodlama uygulamalarını geliştirmekle ve Genel Kalite. Önümüzdeki haftaya kadar kod incelemelerinin başlangıcını ertelemeye devam ettik. Bir gün bunu bir ay kadar süredir yaptığımızı fark ettim ve farklı bir şey denemediğim sürece muhtemelen sonuna kadar devam edeceğim. O hafta ilk kod incelemesini duyurdum. Adamlara "kusurlu olacaksa sorun yok ya da henüz ne yapacağımızı tam olarak bilmiyorsak - sadece yapmaya başlayacağız, nasıl gittiğini göreceğiz ve öğrendikçe şeyleri geliştireceğiz" dedim. En azından şirketten ayrılana kadar işe yaradı.

İkinci durumda, ekiple daha fazla eğitime ve açık tartışmaya ihtiyacınız olabilir. Kod kalitesi sorunlarını tartışır onlara ne sormak onlar geliştirme sürecinde sorunlara olarak gördükleri vb test / kod / (veya bunların eksikliği) Ve bunlar nasıl çözüleceği konusunda birlikte beyin fırtınası . Nihai amaç mutlaka kod incelemeleri yapmak değildir - amaç sadece geliştirme sürecini ve çıktı kalitesini artırmaktır. Daha kolay iyileştirilebilecek, daha fazla fayda sağlayan daha başka acı verici sorunların olduğu ortaya çıkabilir; önce bunları alın. Çevrede veya süreçte önemsiz değişiklikler bile olabilirler; bunların hepsi ekip moralini iyileştirecek, karşılıklı güven tesis edecek ve ekip bağına yardımcı olacaktır.

Sonuç olarak, kaliteyi kimseye zorlayamazsınız - sadece kalite yaratmanın önündeki engelleri kaldırabilirsiniz . Önceden fikir birliği olmadan katı kurallar ve zorunlu uygulamalar uygulayarak ekibi yabancılaştırabilir ve sonuçta hedeflediğiniz kalite gelişimini önleyebilirsiniz. OTOH açık tartışarak ve takım için en acil sorunların neler olduğu ve durumun nasıl iyileştirileceği konusunda anlaşma sağlayarak, takım desteği alma olasılığınız daha yüksektir. Bu, uzun vadede kalite iyileştirme sürüşünü sürdürmede önemli bir fark yaratacaktır.

Klasik problem. Asla doğru yapmak için yeterli zaman, işi tekrar yapmak için yeterli zaman. İnsanlar en iyi uygulamaları yapmaya başlayana kadar, en iyi uygulamaları yapmak için asla yeterli zaman olmayacaktır. Özellikle kazançlar geliştirme dışındaki insanlara görünmez olduğu için.

Kod incelemesi için anahtar, mümkün olan en kısa sürede kodu mümkün olan en kısa zamanda gözden geçirmek istemenizdir. Bu şekilde, incelemek için zaman kazanmak daha kolay olur, kod insanların zihninde taze ve önerilen iyileştirmeleri uygulamak daha kolay olacaktır. Aşırı olarak, her bir check-in'i gözden geçirmek istersiniz. Bunu otomatikleştirmek için iyi bir araç http://code.google.com/appengine/articles/rietveld.html . Google'ın, her check-in sırasında kod incelemesini yapmaya zorlamak için dahili olarak kullandığı aracın bir çeşididir.

Kod incelemesinin zorluğu onlarca yıl önce klasik Bilgisayar Programlama Psikolojisi'nde açıklanmıştır . Sorun, programcıların kendi imajlarını programlama becerilerine bağlama eğiliminde olmasıdır. Bu, programcıların becerilerinin enfiye olmadıklarına dair kanıtlarla karşı karşıya kaldıkları anlamına gelir, kişisel olarak alma eğilimi vardır. Bu ciddi çatışmalara neden olabilir. Steve McConnell'in klasik Hızlı Gelişimini alırsanız , bu tür çatışmaların olasılığını azaltan bir kod inceleme sürecinin nasıl kurulacağı konusunda bir dizi öneri sunar. (Önemli bir unsur, yönetimin sürece hiçbir zaman katılmadığından emin olmaktır.) Bunun çatışma olasılığını azalttığını, ancak çatışmanın olmasını engellemediğini unutmayın.

Bununla birlikte, faydalar maliyetlerden çok daha ağır basmaktadır. Sadece bir metriğe değinmek için IBM, kod incelemesinin dolar için dolar olduğunu, hataları bulmanın ve ortadan kaldırmanın en etkili yolunu buldu. Bu, KG departmanınızın hiçbir şekilde yerine geçmez. Ama bu onların bulmaları için çok daha az sorunla sonuçlanır. Ve bu, öğrenmeyi ne kadar hızlandırdığını, bilgiyi yaydığını vb.

Onlara seçenek vermeyin. Test ve incelemeleri zorunlu hale getirin. Eğer işbirliği yapmazlarsa, denenmemiş veya incelenmemiş promosyonları reddetmek gibi bazı sert taktiklere başvurabilirsiniz. İşler gerçekten kötüyse, en kötü suçlunuzu kovun.

Bir ekibin her zaman programın gerisinde kaldığı durumları gördüm çünkü test ve gözden geçirmelerle yakalanması gereken hataları her zaman düzeltiyorlar. Ön tarafta biraz daha fazla çalışma uzun vadede çok daha fazla tasarruf sağlar ve takımınızı ne kadar çabuk sıraya sokarsanız, takımınız o kadar iyi olur.

Ne yazık ki, sonuçların gerçekten görülmesi zaman alabilir. Uygulamayı teşvik etmek için hata raporlarının oranını, hata düzeltmelerinin ortalama süresini ve özellik uygulama oranını çizmeye başlayabilirsiniz. Genellikle yaklaşık altı aylık test ve incelemelerden sonra, bu metriklerin iyileşeceğini ve ekibinizin nihayetinde elde edeceğini görüyorum.

Geliştiricilerin iradesine karşı tdd getirmek zor. Tdd'yi sevmeyi öğrenmek zor bir yoldur.

Tdd yeşil bir alanda en etkili olduğu için (ya da testler sonrasında wirten yapılıyorsa sert, maliyetli, verimsiz) yeni bir şey yapan küçük bir ekiple başlayacağım. Takımda diğerlerine göre daha az karşı olan iki geliştirici bulursanız, bu iyi bir başlangıç ​​noktasıdır. tdd geliştiricilerinin üretkenliğinin, tdd ile deneyimsiz olduklarında zarar göreceğini unutmayın.

Bu tdd gelişimi bir kod görünümü için iyi bir başlangıç ​​noktasıdır. Tdd'nin program mimarisini nasıl etkilediğini ve yazılımın nasıl kolaylaştırıldığını tartışın.