Kod inceleme alıştırmaları: Analiz ve teknik muhakeme geliştirmek için akran incelemesinden nasıl yararlanılır?

Bir geliştirici, ödeme hizmetine indirim hesaplaması ekleyen bir çekme isteği (pull request) açar. Testler başarılı olur ve fark kısadır. Bir gözden geçiren kişi iki dakika içinde "LGTM" (Tamamdır) diyerek onaylar. Üç ay sonra bir ekip arkadaşı aynı işlevi değiştirmek ister ve bunun fiyatlandırma kurallarını, yuvarlamayı ve veritabanı erişimini tek bir yerde karıştırdığını keşfeder. Kimse bunun neye izin verildiğinden emin bir şekilde emin olamaz.

Bu, belgelenmiş bir olay değil, örnek bir senaryodur. Akran kod incelemesinin bir öğrenme etkinliği olarak işlev gördüğünde ne üretmesi gerektiğini gösterir: makul bir değişikliği görebilen, henüz bir hata olmayan endişeyi tespit edebilen ve yazarın harekete geçebileceği şekilde açıklayabilen bir inceleyici.

Bu kılavuz, mühendislik destek liderleri ve mühendislik yöneticileri içindir. Tasarımın nasıl yapılacağını göstermektedir. kod inceleme alıştırmaları Bu, değerlendiricilerin bunu kendiliğinden öğrenmesini ummak yerine, bu beceriyi kasıtlı olarak geliştirmeyi amaçlar. Performans sorununu, teşhis edilecek eksiklikleri, hazırlık ve uygulama yapısını, bir örnek uygulamayı ve becerinin gerçek değerlendirmelere nasıl aktarıldığını kontrol etmeyi kapsar. Kullanmadan önce her vakayı, hatayı ve kriteri kıdemli mühendislere onaylatın.

Kod inceleme egzersizleri nelerdir?

Kod inceleme alıştırmaları, bir geliştiricinin önceden hazırlanmış bir değişikliği incelediği, bulduklarını ve neden önemli olduğunu açıkladığı ve bu açıklamanın kalitesi hakkında geri bildirim aldığı yapılandırılmış uygulama görevleridir. Bunlar, ekibinizin her gün yaptığı incelemelerden farklıdır. Değişiklik önceden seçilir, içindeki endişeler bilinir ve amaç, değişikliği yayınlamak yerine inceleyeni geliştirmektir.

Hızlı gerçekler

1. Performans sorununu açıklayın.

Görevi tek bir cümleyle özetleyerek başlayın: Bir değişiklik verildiğinde, değerlendirici bulduklarını, neden önemli olduğunu ve yazarın bu konuda ne yapabileceğini açıklar. "Açıklar" kelimesi burada önemlidir. Bir sorunu tespit etmek becerinin yarısıdır. Farklı bir görüşe sahip bir meslektaşın anlayabileceği, değerlendirebileceği ve harekete geçebileceği şekilde ifade etmek ise diğer yarısıdır.

Modern kod incelemesi üzerine yapılan araştırmalar, hata avcılığının ötesine bakmayı destekliyor. Microsoft'ta Bacchelli ve Bird tarafından yapılan bir çalışmada, geliştiriciler ve yöneticiler gözlemlendi, röportajlar yapıldı ve anketler gerçekleştirildi. Hata bulmanın hala incelemenin ana motivasyonu olduğunu, ancak incelemelerin insanların beklediğinden daha az hata odaklı olduğunu buldular. Ayrıca bilgi paylaşımı, ekip farkındalığı ve alternatif çözümler gibi diğer faydaları da sağladılar ve araştırmacılar, kod ve değişiklik anlayışını incelemenin kilit yönü olarak tanımladılar.Bacchelli ve Bird, ICSE 2013Bu, bir şirketin ekipleri üzerine yapılan bir çalışma; dolayısıyla bunu kendi ekipleriniz için bir değerlendirme ölçütü olarak değil, anlayış odaklı tasarım yapmanız için bir neden olarak kullanın.

Google'ın yayınladığı inceleme standardı da aynı şeyi belirtiyor. İnceleyicilere, mükemmel olmasa bile, kodun genel sağlığını kesin olarak iyileştiren bir değişikliği onaylamayı tercih etmelerini söylüyor ve incelemenin geliştiricilere yeni bir şeyler öğretebileceğini, bu nedenle birinin öğrenmesine yardımcı olan yorumların memnuniyetle karşılandığını belirtiyor.Google Mühendislik UygulamalarıHer iki kaynak da değerlendirmeyi, yargıların uygulandığı ve aktarıldığı bir yer olarak tanımlıyor. Egzersizleriniz de bunu prova etmelidir.

2. Öğrenme ve bağlam eksikliklerini teşhis edin.

Bu görevi, mevcut programınızın uyguladığı ve değerlendirdiği konularla karşılaştırın.

1. Mevcut uygulamada gerçek görev kullanılıyor mu? Yeni gözden geçirenler, önce bir stil kılavuzu okuyarak ve ardından canlı çekme isteklerini inceleyerek öğrenirlerse, hata yapma güvenli bir alan olmadan gerçek işler üzerinde pratik yaparlar. Değerlendirme, inceleme görgü kuralları üzerine bir sınav ise, kuralları hatırlama yeteneğini ölçer, bir değişikliğe uygulama yeteneğini değil.
2. Bilişsel talep nedir? Yeniden gözden geçirilmiş Bloom taksonomisinde, bir tasarımın sağlam olup olmadığını değerlendirmek ve avantaj-dezavantajlarını tartmak analiz ve değerlendirme seviyelerinde yer alırken, daha iyi bir yapı önermek yaratma seviyesine ulaşır. Eğer alıştırmalarınız sadece "bu kod ne yapıyor?" sorusunu soruyorsa, anlama aşamasında kalırlar. Kılavuzumuz Öğrenme etkinliklerini Bloom Taksonomisi ile eşleştirmek Etkinliğin seviyeye nasıl uyarlanacağını gösterir.
3. Beceriden başka bir şey mi engel oluyor? İnceleme süresini, araçları, sahipliği ve ekip normlarını kontrol edin. Eğer inceleyicilere her çekme isteği için beş dakika süre verilirse, hiçbir çalışma düşünceli bir açıklama ortaya çıkaramaz. Yazarlar her yorumu eleştiri olarak algılarsa, inceleyiciler bulgularını yumuşatacak ve sonunda hiçbir şey söylemeyeceklerdir. Bu nedenleri, bunları düzeltebilecek kişilere bildirin.

3. Tasarım hazırlığı, uygulama ve geri bildirim

Her aşamaya ayrı bir görev verin.

Hazırlık. İncelemeye başlamadan önce, inceleyicilerin nelere ihtiyaç duyduğunu kontrol edin: ekibin inceleme kontrol listesi, dayandığı tasarım prensipleri ve araçlarınızda bir farkı nasıl okuyacağınız. Bunu kendi hızınızda ve kısa tutun. Geri çağırma kontrolü yalnızca ön koşulları doğrular ve birinin inceleme yapabileceğine dair bir kanıt değildir.

Uygulama. Farklı türde az sayıda önceden belirlenmiş sorun içeren hazırlanmış değişiklikler kullanın: bir doğruluk hatası, açılış örneğindeki karışık sorumluluklar gibi bir sürdürülebilirlik sorunu, belirsiz bir isim veya eksik bir test ve sorunsuz çalışan bazı kodlar. Gözden geçiren kişiden bırakacağı yorumu yazmasını, sorunları sıralamasını ve hangi ek bilgileri istediğini belirtmesini isteyin. CodeRefinery'nin uygulamalı dersi şekli gösteriyor: insanlar küçük bir yazım hatası ve daha büyük bir hata içeren bir çekme isteği açıyor, ardından bunu akran olarak inceliyorlar (CodeRefinery, Kod incelemesi uygulamasıKendi kod tabanınızdan yola çıkarak geliştirin, böylece kurallar ve ödünleşmeler gerçek olsun.

Geri bildirim. Bunu, değerlendiricinin aldığı kararlarla ilişkilendirin. "Yuvarlama sorununu fark ettiniz ancak yorumunuzda 'bu yanlış görünüyor' dediniz, hangi girdinin soruna yol açtığını belirtmediniz" ifadesi, "4'te 2 bulundu" ifadesinden daha faydalıdır.

Canlı giriş mi yoksa eşzamansız inceleme mi? Canlı geri bildirim, bir sorun belirsiz olduğunda ve gözden geçirenler kıdemli bir mühendisin neden bu sorunu gündeme getirdiğini veya görmezden geldiğini dinleyerek bilgi edindiğinde en büyük değeri katar. Eşzamansız inceleme, yorumları açıklamalı bir uzman incelemesiyle karşılaştırmak için yeterlidir.

4. Gerçekçi bir örnek üzerinde çalışın.

Örnek niteliğindedir. Kullanmadan önce bir mühendislik yöneticisinin durumu ve cevap kriterlerini doğrulaması gerekir.

Dosya. Bir değişiklik, ödeme hizmetine indirim hesaplaması ekliyor. Testlerden geçiyor. Tek bir fonksiyonda yüzde ve sabit indirimleri uyguluyor, sonucu yuvarlıyor, veritabanına yazıyor ve bir olay gönderiyor. Tek bir yüzde indirimi için sadece bir testi var.

Görev. Değerlendirici, bırakacağı yorumları yazıyor, endişelerini sıralıyor ve onaylamadan önce bilmesi gerekenleri belirtiyor.

İlk deneme. "Gayet iyi görünüyor, test başarılı. Belki de bölümlere ayırmak daha iyi olur?" Değerlendiren kişi bir şey fark etmiş ancak ne olduğunu, neden önemli olduğunu veya ne yapılması gerektiğini belirtmemiş. Yazar bu konuda harekete geçemez.

Geri bildirim ve yeniden deneme. Kolaylaştırıcı şu soruları sorar: Bu fonksiyonda yapılacak gelecekteki bir değişiklik hangi sorunları doğurabilir? Onaylamadan önce yazardan ne eklemesini istersiniz? Tekrar deneme aşamasında, her bir endişe için gerekçe ve öneriyle birlikte özel bir yorum istenir.

Daha güçlü bir girişim. "Bu fonksiyon iki tür indirim uyguluyor, yuvarlama yapıyor, kaydediyor ve bir olay yayınlıyor; bu nedenle yuvarlamada yapılacak bir değişiklik, aynı anda hem sakladığımız hem de yayınladığımız verileri değiştirebilir. Fiyatlandırma kurallarının, kendi başına test edebileceğimiz saf bir fonksiyona taşınmasını rica ediyorum. Tek test yalnızca yüzde indirimini kapsıyor. Sabit bir indirim ve toplamı sıfıra getiren bir sipariş rica ediyorum. Olayın toplam sıfır olduğunda tetiklenmesi gerekip gerekmediğinden emin değilim, bu nedenle yazara sormak istiyorum." Dikkat edin, bu yorum endişeyi belirtiyor, nedenini açıklıyor, somut bir öneride bulunuyor ve gözden geçirenin bilmediği şeyleri ifade ediyor.

5. Kapasiteyi değerlendirin ve devri planlayın

Yeterlilik kanıtı, değerlendiricinin daha önce görmediği yeni bir değişiklik üzerindeki performanstır. Bulguların doğruluğunu ve açıklamanın yararlılığını puanlayın. Basit bir değerlendirme ölçeği, her kriter için 0 ila 2 arasında bir puan kullanır:

Puanlama Kriterleri: 0 eksik veya desteksiz, 1 ilgili eksikliklerle kısmi, 2 ise kabul edilen kriterlere göre eksiksiz ve gerekçelendirilmiş anlamına gelir. Kritik hataları ayrı olarak tanımlayın, örneğin veri kaybı riski olan bir değişikliği onaylamak gibi, böylece iyi bir genel puan bir hatayı gizleyemez. Kriterleri mühendislik yöneticisiyle birlikte uyarlayın; bu değerlendirme formu bir başlangıç ​​önerisidir, onaylanmış bir hazırlık standardı değildir. Puanlama gerekçelendirmesi hakkında daha fazla bilgi için kılavuzumuza bakın. Faydalı geri bildirim içeren etkileşimli uygulama tasarımı.

Aktarım planı. Tatbikatın ardından, birkaç hafta sonra aynı kriterleri kullanarak değerlendiricinin gerçek değerlendirmelerinden bir örneklem kontrol edin. Eğitimden önce alınan bir temel değerle karşılaştırın ve hedef kitleyi ve zamanlamayı önceden belirleyin. Tatbikatların sonuçlarını değerlendirmeden önce, aynı dönemde meydana gelen diğer değişikliklere (örneğin yeni bir değerlendirme aracı veya personel değişikliği) bakın.

6. Egzersizi AhaSlides ile canlı veya kendi hızınızda gerçekleştirin.

Bu alıştırmayı bir atölye çalışmasında gerçekleştirebilir veya değerlendiricilerin kendi başlarına üzerinde çalışmalarına izin verebilirsiniz. Canlı bir oturumda, hazırlanan değişikliği gösterin ve tartışma için etkileşimli slaytlar kullanın:

1. Yanıt Seç "Hangi endişeyi ilk olarak dile getirirsiniz?" sorusuna, önceden belirlenmiş endişeleri seçenek olarak sunarak cevap verin. Kendi sıralamanızı açıklamadan önce dağılımı gösterin.
2. Açık Uçlu "Bırakacağınız yorumu yazın" seçeneği için. Değerlendirenler kendi ifadelerini diğerleriyle karşılaştırabilir ve işte burada açıklama becerisi ortaya çıkar.
3. Değerlendirme ölçeği "Bu ne kadar ciddi?" sorusuna cevap arayarak, grubun değerlendirmelerindeki farklılıkları görmesini ve nedenlerini tartışmasını sağlayabiliriz.

Katılamayan değerlendiriciler için, aynı sıra kendi hızlarında ilerleyerek kullanılabilir ve her yanıttan sonra uzman değerlendirmesi gösterilebilir. Kod yürütme, entegrasyonlar veya yapay zeka özellikleri hakkındaki herhangi bir iddiayı, kendi materyalinizle denemeden önce doğrulanmamış olarak kabul edin.

Ayrıca yapay zeka tarafından yazılmış kod konusunda inceleyicileri eğitiyorsanız, ilgili kılavuzumuza göz atın. Yapay zeka tarafından oluşturulan kod inceleme eğitimiÖnceki yazı üretilen çıktıların denetlenmesiyle ilgiliydi. Bu yazı ise insanların birbirlerinin çalışmalarını nasıl inceledikleri ve bulduklarını nasıl açıkladıklarıyla ilgili.

Kalabilecek kısıtlamalar

• Değerlendirme zamanı. Düşünceli bir yorum yazmak "LGTM" demekten daha uzun sürer ve son teslim tarihleri ​​kısa versiyona yönlendirir.
• Takım kuralları. Geri bildirim kişisel bir eleştiri olarak algılanırsa, değerlendiriciler bulgularını yumuşatacak veya tamamen geri çekecektir.
• Dava kapsamı. Bu alıştırma, birkaç farklı endişe türünü ortaya koymaktadır. Bir puan, bir değerlendiricinin genel yargısını yansıtmaz.
• Aktarım. Bir atölyedeki performans, yoğun bir kuyruktaki performansla aynı değildir, bu nedenle gerçek yorumları da inceleyin.

Bunları sponsorlara erkenden bildirin ve ayrı ayrı düzeltmeler planlayın. Tatbikatlar, bir değerlendiricinin görebileceği ve açıklayabileceği şeyleri geliştirir. Ancak zamanı veya normları yaratmazlar.

Sık Sorulan Sorular

Kod inceleme egzersizleri nelerdir?

Bunlar, bir geliştiricinin bilinen endişeleri olan bir değişikliği incelediği, bırakacağı yorumları yazdığı ve doğruluğu ve kullanışlılığı konusunda geri bildirim aldığı önceden hazırlanmış uygulama görevleridir. Amaç, değişikliği yayınlamak değil, inceleyicinin becerisini geliştirmektir.

Bir değerlendiricinin yargı yeteneğinin gelişip gelişmediğini nasıl değerlendirirsiniz?

Daha önce görmedikleri yeni bir değişiklik sunun ve bulguları ve açıklamayı üzerinde anlaşılan kriterlere göre puanlayın. Ardından, birkaç hafta sonra gerçek yorumlardan oluşan bir örneklem kontrol edin. Yorum kuralları hakkındaki bir sınav yalnızca ön koşulları doğrular.

Akran kod incelemesi esas olarak hataları bulmakla mı ilgilidir?

Hataları bulmak hâlâ temel motivasyon olsa da, Microsoft'ta yapılan bir çalışma, incelemelerin beklenenden daha az hata odaklı olduğunu ve ayrıca bilgi paylaşımını ve ekip farkındalığını artırdığını ortaya koydu. Açıklama ve anlayışı ödüllendiren, aynı zamanda hata sayısını da dikkate alan tasarım egzersizleri geliştirin.

Nerede başlar

Ekibinizin sık sık incelediği bir değişiklik türü seçin. Performans raporunu yazın, kıdemli bir mühendisten üç veya dört temel endişe içeren bir değişiklik hazırlamasını isteyin ve 0 ile 2 arasında bir ölçek ve kritik hataların listesini içeren üç kriterli bir değerlendirme formu taslağı hazırlayın. Bunu küçük bir grupla pilot uygulama olarak gerçekleştirin, ardından bir sonraki gerçek değerlendirmelerini temel verilerle karşılaştırın.

Bir değerlendirme çalışmasının kendi ekibinizle nasıl canlı olarak yürütülebileceğini ve sonrasında kendi hızınızda yeniden nasıl kullanılabileceğini görmek için AhaSlides'ı inceleyin.