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 yetenek geliştirme liderleri ve mühendislik yöneticileri içindir. Kod inceleme alıştırmalarının, inceleyicilerin bu beceriyi kendiliğinden edinmesini ummak yerine, bilinçli olarak bu beceriyi geliştirecek şekilde nasıl tasarlanacağını gösterir. Performans sorununu, teşhis edilecek eksiklikleri, hazırlık ve uygulama yapısını, bir örnek uygulamayı ve becerinin gerçek incelemelere nasıl aktarılacağını kapsar. Kullanmadan önce her bir durumu, 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, geliştiricileri ve yöneticileri gözlemledi, onlarla röportaj yaptı ve anketler gerçekleştirdi. 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 ( Baccelli ve Bird, ICSE 2013 ). Bu, bir şirketin ekipleri üzerinde yapılan bir çalışmadır, bu nedenle bunu kendi ekibiniz için bir oran olarak değil, anlayış odaklı tasarım 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 incelemeyi, yargını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 okuyacakları. 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.

Pratik yapın. 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, yapıyı 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 inceliyor ( CodeRefinery, Kod incelemesi pratiği ). Kuralların ve ödünleşmelerin gerçek olması için kendi kod tabanınızdan yola çıkarak kendi incelemenizi oluşturun.

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 neden olduğunu belirtmediniz" ifadesi, "4'te 2'sini buldum" ifadesinden daha faydalıdır.

Canlı geri bildirim mi yoksa eşzamansız inceleme mi? Canlı geri bildirim, bir sorun belirsiz olduğunda ve inceleyiciler 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 ise 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.

Örnek olay şu: 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 şu: Değerlendirici, bırakacağı yorumları yazıyor, endişelerini sıralıyor ve onaylamadan önce bilmesi gerekenleri belirtiyor.

İlk deneme. "İyi 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ş ama ne olduğunu, neden önemli olduğunu veya ne yapılması gerektiğini söylememiş. 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? Yeniden 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. "Fonksiyon iki tür indirim uyguluyor, yuvarlı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 şeyleri 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 yüzden 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 belirtiyor.

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 noktaları: 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, yararlı geri bildirimlerle etkileşimli uygulama tasarlama kılavuzumuza bakın.

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.

Eğer siz de yapay zeka tarafından yazılmış kodlar konusunda incelemecileri eğitiyorsanız, yapay zeka tarafından üretilen kod inceleme eğitimi hakkındaki kılavuzumuza göz atabilirsiniz . O yazı, üretilen çıktıların denetlenmesiyle ilgili. 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.