İnsanlık tarihinin büyük bölümünde kod kalitesini kod incelemesi ile değerlendirdik: birisi yazdıklarınızı okur ve kodun temiz, özenli, hızlı, anlaşılır ve iyi test edilmiş olduğundan emin olur. Ajanlar için bu yaklaşım iyi ölçeklenmiyor; kimsenin okuyamayacağı kadar çok kod var. Sonuç olarak, kalite kontrollerimizin giderek daha büyük bir kısmının ajanın etrafındaki harness, ortam ve işletim sisteminde gerçekleşmesi gerekiyor. Ben hâlâ kod okuyup inceliyorum, ancak kontrol olarak kısıtlamaları kullanmaktan memnun olduğum yerler konusunda çok bilinçliyim.
Yazılım kalitesi artık ajanlarınızın etrafına koyduğunuz kısıtlamalara bağlı.
Guillermo'nun listesi, okumayı atlayıp atlayamayacağınız için iyi bir test. Dikkat edin, her "evet" aslında risklerin ne kadar düşük olduğuna dair bir ifadedir - kullanıcı yok, tek kullanımlık kod, prototip. Riskler artınca, kodun bir şey tarafından okunması gerekir. Her diff'te kodu okuyan siz değilseniz, bunu kısıtlamalar yapmak zorundadır.
Kısıtlamalar, ajanın önerilerine testler ve deterministik kısıtlamalar uygulayarak sistemin ne yapmasına izin verildiğini tanımlar. Bu kısıtlamaları belirleyip sürdürerek, ajanlar her gün yüz binlerce veya milyonlarca değişiklik oluştursa bile güvenilir şekilde yüksek kaliteli üretim yazılımı teslim eden döngüler kurarız.
Bu kısıtlamalara kalite kapıları diyoruz ve birçok biçimde karşımıza çıkıyorlar.
Bunlar arasında geleneksel birim testleri, özellik testleri ve kabul testleri yer alır. Ayrıca mutasyon testi de var: kodun varyasyonlarını üretir, aynı testlere karşı çalıştırır ve kaçırdığımız hataların gizlice sızmadığından emin oluruz. Bunlar, döngüsel karmaşıklık ve satır uzunluğu gibi kodun okunabilir kalmasını sağlayan kod kalitesi metrikleridir.
İki kişi kodun okunup okunmaması konusunda aynı fikirde olmayabilir ama mekanizma konusunda hemfikir olabilir. Guillermo kodu okur. Bob hiç okumaz. İkisi de bir engel parkurunu tarif ediyor - fark yalnızca içinde bir insanın oturup oturmaması (Bob'un diğer görüşlerini onaylamıyorum)
Kısıtlamalar, sistemin hangi önerileri kabul edip kod değişikliği olarak uygulayacağı konusunda da önemli bir rol oynar. Bir değişiklik önerisi ajanı çalıştıran yorumlayıcıdan ajan denetleyicisine ve oradan üretime geçtiğinde, üzerinde yeterince kontrol yapmış oluruz; böylece yayınlanmasının güvenli olduğundan ve değişikliğin etkisinin ajanın kapsamı dahilinde olduğundan emin oluruz.
Bir ajan her şeyi önerebilir. Sizin kısıtlamalarınız, bir önerinin sizin ve ekibinizin yayınlaması için yeterince güvenli, doğru, kapsamlı ve kullanışlı olup olmadığına karar verir.
Bu model çok şey sunuyor, ancak birçok parçayı da dışarıda bırakıyor ve bu eksiklikler bugün üzerinde düşünmeye değer. Sorunlardan biri özerklik; ajanlar niyetlerini iyi uygulayabilir, ancak eksik bilgi olduğunda veya yapmaya çalıştıkları şey belirsiz olduğunda başarısız olabilirler. Bu hem görevin kendisi hem de görevin harness, ortam ve diğer bileşenler tarafından nasıl parametrelendirildiği için geçerlidir.
İnsanların harika kod yayınlayamama nedenlerinin çoğu, ajanların da yapabileceği şeylerle ortaktır: betik kaynaklı stres altında dayanamayan kırılgan ortamlar, deterministik olmayan derlemeler, eksik izinler ve zayıf testler. Bu da ajanlara güvenilir geri bildirim veren, düşük hasarlı hata modlarına izin veren ve başarının aşamalı olarak inşa edilmesini kolaylaştıran daha iyi bir ortamı teşvik ediyor.
Peşinde olduğumuz ortam, bir ajanın gerçek iş yapabildiği, güvenebileceği geri bildirim alabildiği ve fazla hasar vermeden başarısız olabildiği bir ortamdır.
Diğer önemli konu ise güven. Modern bir ajan kadar akıllı ve sağlam olsa bile, doğruluğunu kontrol etmeden niyeti bir şeye safça teslim edemeyiz. Güvenle başlarız, ancak bu güvenin kazanılması zor olmalıdır.
Bazı kısıtlamalar iş başlamadan önce işi şekillendirir. Bazıları ajan çalışırken geri bildirim verir. Bazıları ise çıktısının üretim sınırını geçip geçemeyeceğine karar verir.
Bir sistemin etrafına doğrulama yapısı kurmayı modellemenin birçok yolu vardır.
Deneyimlerime göre, yalnızca birim testlerine güvenmek yerine, kısıtlamalarınız için daha geniş ama bilinçli seçilmiş bir kontrol setine sahip olmak yardımcı olur. Buradaki fikir, her kontrolün ayrı bir sorumluluğunun olmasıdır ve bu, tip güvenliği ve performanstan geç aşama güvenlik taramasına kadar uzanabilir. Herkes, ESLint gibi lint araçlarının uygulayabileceği mimari kurallar dahil kendi kısıtlamalarını da tanımlayabilir. Bu araçların çoğu, bir şeyler bozulduğunda ajanları veya insanları sürece dahil etmek için kullanılabilecek yerleşik kancalara sahiptir.
Şimdilik, yararlı ajan çıktısı ile döküntü (slop) arasındaki farkın büyük kısmı hâlâ döngüyü yöneten ekibin becerisine bağlıdır.
Yapay zeka bize yüksek hacimli kod üretimi ve hız sağlıyor, ancak bu aynı zamanda insanların her değişikliği incelemesinin zorlaştığı anlamına da gelebilir. Bunun yerine, dikkatlerinin nereye gittiği konusunda bilinçli olmanız gerekir. Makine hızında hareket eden bir sisteme insan kontrolü koyarsanız, bunun üretkenliği etkilemesine şaşırmayın. İnsan dikkati kıt ve değerlidir; bu yüzden onu, muhakememizi gerektiren en nüanslı sorunlara proaktif olarak yönlendirmeliyiz. Sürecin ilerisindeki insanlar yalnızca kısıtlamalar için otomatik korkuluklar bozulduğunda sürece dahil edilmelidir.
Gelecekte insan "kod incelemesi" çok farklı görünecek
Doğruluk önemli bir boyuttur, ancak sürdürülebilirlik, performans, güvenlik, verimlilik ve anlaşılabilirlik gibi diğer boyutlar da sizin için önemli olabilir. Doğruluk birçok sinyal türüne ayrıştığı gibi, kalitenin geri kalanı da ayrışır. Kaç kısıtlamamız olduğu önemli olsa da, kısıtlamaların kalite ve üretime hazır olma çıtamızı karşılayacak kadar zorlu olup olmadığı daha da önemlidir.
Yazılım kalitesi tek bir metrik değildir. Bunu, sizin ve ekibiniz için farklı önem derecelerine sahip bir sinyal koleksiyonu olarak düşünün.
Geri basınç birçok araçla uygulanabilir: derleyicilerin geçersiz kodu reddetmesi, testlerin başarısız olması, güvenlik politikalarının kötü uygulamaları engellemesi, CI'ın dağıtımı reddetmesi. İdeal olarak, tüm işin en sonunda yapılan tek bir inceleme olarak değil, döngünün her yerinde bulunmalıdır.
Dex Horthy'nin aynı döngüyü gösteren haritası, Why Software Factories Fail'dan. Yeşil kutu, insan incelemesinin döngüden çıkarılmak yerine döngüye geri konulması gerektiği argümanı.
Kısıtlamalar ve geri basınç, ajanların kötü işi sorun haline gelmeden yakalamasını sağlar
Değişiklik hacmi araçlarımızın tüketebileceğinden daha yüksek olduğu için kısıtlamayı uygulayamazsak ne olur? Sonunda bir kuyruk oluşturur ve insan hızında hareket eden bir doğrulama sistemine bel bağlarız. Ölçeklenmek için, mümkün olduğunca çok şeyi baştan sona doğrulama döngüsüne itmek ve sonuna kadar beklememek istiyoruz. Otomatik kontrollerimiz dahilinde ölçeklenebilirsek, tüm teslimat sistemimizin hızını ve verimini artırabiliriz. Doğrulama döngüsünde alanımız tükenirse, birkaç şeyden birini yapmamız gerekir.
İlk olarak, doğrulama sistemimizi ölçekleyebilir ve gelen değişiklikleri kısıtlamak ve geri itmek için daha fazla kapasite oluşturabiliriz. İkinci olarak, ajanların yeni değişiklik üretme hızını düşürebiliriz; böylece doğrulama, iş hacmine yetişebilir. Üçüncü olarak, kalite çıtamızı düşürebiliriz; böylece doğrulama, aksi halde olabileceği kadar sert geri itmez. Ölçekleme perspektifinden bakıldığında, tüm bunları yapmaya hazır olmamız gerekir. Aynı zamanda, bazı yönlerde kısıtlamaları kaldırarak aslında daha fazla iş başarabileceğimizi fark etmekten geri durmamalıyız. Belki de her birini incelememizi beklemeden değişiklikler oluşturmak için ajan geliştirici sürüleri veya otomatik yazılım fabrikaları sağlayarak ajan tarafından üretilen değişikliklerin hızını artırabiliriz.
Ve bazı yerlerde, diğerlerinde daha sıkı kısıtlamalar tuttuğumuz sürece onlara daha fazla özgürlük vermek isteyebiliriz. En çok önemsediğimiz yerlerde daha sıkı kısıtlamalar sağlayarak, kaliteden ödün vermeden verimimizi en üst düzeye çıkarabiliriz. Bu kararlar boyunca birçok seçenek vardır. En bariz olanı, kalitenin farklı boyutları arasında takas yapmak zorunda olmamızdır. Vurguladığımız gibi, güvenlik çok önemlidir; ancak güvenlik sağlamak ile ürünü zamanında teslim etmek arasında da takas yapmak zorunda kaldık. Bir ucunda inovasyon odaklı, diğer ucunda kalite odaklı bir yelpaze vardır. Bir noktada, bu yelpazede nerede olmak istediğimize dair seçimler yapmamız gerekir.
Ortamdan ve sistemden ajanlarımıza veya ekiplerimize net geri bildirim göndermek istiyoruz; böylece insanlar zevk, niyet ve mimari gibi daha öznel konulara odaklanabilir. İnsanların kısıtlamaların güvenli aralığında kalmasına yardımcı olabilirsek, işlerin nerede ters gittiğini bulmak için çok çalışmalarına gerek kalmaz.
Yazılım kalitesi yalnızca doğruluktan ibaret değildir. Yazılım kalitesi aynı zamanda sürdürülebilirlik, iyi performans, güvenlik, verimlilik ve kolay anlaşılır olmak demektir. Bu standartları karşılamamıza ve üretimimizin akışını sürdürmemize yardımcı olan tüm kısıtlamalar, teslimat hattımızda geri basınç oluşturur.
Güçlü kısıtlamaları nereye uygulayacağımız ve nerede kaldıracağımız veya gevşeteceğimiz konusunda bilinçli kararlar almamız gerekir. Güçlü kısıtlamaları bu iki hedefe de hizmet ettikleri yerde uygulayın. Birine veya ikisine de hizmet etmiyorlarsa onları tutmayın. Durumun gerektirdiği şekilde standartları yükseltmeye veya düşürmeye hazır olun. Ve unutmayın: yazılım sisteminin farklı noktalarındaki bu kısıtlamalar, yazılım kalitesini uygulanabilir kılan şeydir.
Güçlü kısıtlamaları bu ikili amaca en iyi hizmet edecekleri yerde uygulamalı; iki amaca da iyi hizmet etmeyen kısıtlamaları kaldırmayı veya gevşetmeyi düşünmeliyiz. Gerektiğinde kalite çıtalarını yukarı veya aşağı kaydırmaya da hazır olmalıyız. Sonuç olarak, yazılım sistemimizin çeşitli noktalarındaki bu kısıtlamalar kaliteye diş kazandıran şeydir. Birçok durumda, yeni araçlar dağıtarak veya mevcut araçları güçlendirerek daha fazla geri basınç ve daha fazla kısıtlama oluşturabiliriz. Tüm bunlar, çoğu değişiklik talebini geri itmek için kullanılabilir. Bunları hattın her yerine kurmak istiyoruz.
Hattın sonunu, CI sistemimizin bize sorunları düzeltmeden dağıtım yapamayacağımızı söyleyeceği ana kadar beklemek istemiyoruz. Bu sinyalleri mümkün olan her yoldan, olabildiğince erken kullanmak istiyoruz. Bu sistemdeki nihai kısıtlama, sistemi inşa etmek ve işletmek için aldığımız kararların ve yaptığımız eylemlerin arkasında durmak için kendimize koyduğumuz kısıtlamadır. Ancak diğer tüm kısıtlamalar gibi, kendi muhakememizin ne kadar devreye girip kısıtlayacağı, geri basınç uygulayacağı ve son kontrol olacağı konusunda dikkatli seçimler yapmamız gerekir.
Kalite, ajanlarımızın etrafına koyduğumuz kısıtlamalardadır. Bu yüzden kendi uygulamalarınız için kaliteyi düşünürken bu problem tanımını alın ve kendi kısıtlama odaklı planınızı oluşturun.
Kaliteden bahsetmişken, ajanlar kodunuzu yazıyor. Sonar size onu yayınlanabilir kılacak kalite kapıları sunar. Her commit'te aynı kapsamlı kontrolü çalıştırır: derin dosyalar arası analiz, riskin nerede yaşadığının haritası ve her insanı ve ajanı tek bir çıtada tutan bir kalite kapısı.
Bu makale, Pangram 4 tarafından %100 insan yazımı olarak derecelendirildi.
