Kendi bulgusunu kanıtlamak zorunda olan bir kod inceleme platformu
Çoğu inceleme aracı, düzeltilecek işten çok okunacak metin üretir. Biz, aynı değişikliği birden çok analiz ajanının paralel çalıştığı, ikinci bir geçişin bulunan her şeye itiraz ettiği ve ayakta kalanın yerine geçecek kodla ve arkasındaki kanıtla birlikte geldiği bir platform kurduk. Terminalin, editörün, API'nin ve arka planda çalışan servisin arkasında tek bir motor var; böylece inceleme nerede başlarsa başlasın aynı şeyi ifade ediyor.
- SektörGeliştirici araçları
- Çalışma türüKurum içi ürün geliştirme
- DurumAktif kullanımda, geliştirilmeye devam ediyor
İnceleme istemenin her yolunun arkasında tek bir motor
Platform önerilen değişikliği okur, neye dokunduğunu çıkarır ve aynı anda birden çok analiz ajanının önüne koyar. Bulgular birleştirilir, yinelenenler ayıklanır, önem sırasına dizilir ve sınırlanır; geriye okunacak bir duvar değil, baştan çalışılacak bir sıra kalır. Bu bir linter değil, tek bir modelin görüşünün karara dönüştürülmüş hâli de değil.
Aynı motor; istek terminalden, editörden, API'den ya da bir depoyu kendi takvimiyle izleyen arka plan servisinden gelsin, aynı şekilde çalışır. Tek bir geçmişi paylaşırlar; klavyede başlatılan inceleme, panonun sonra gösterdiği incelemenin ta kendisidir ve pull request'te yeni yorum yığmak yerine kendi yorumu güncellenir.
Neden bir inceleme aracı daha
Otomatik inceleme, kapsam sorunundan önce bir güvenilirlik sorunu yaşıyordu. Tasarımı şu üç başarısızlığa karşı kurduk.
Gürültü, yakaladığından fazlasına mal olur
Biçim düzeltmelerini, yeniden sıralanmış importları ve kendinden emin tahminleri işaretleyen bir araç, ekibe göz gezdirmeyi öğretir. İnceleme çıktısına göz gezdirilmeye başlandığında, önemli olan tek bulgu da onunla birlikte atlanır.
Düzeltmesiz bir bulgu, yeni bir iş kaydıdır
Sorunu anlatıp orada duran inceleme yorumları, işi zaten yoğun olan kişiye geri verir. Okuyan kişi düzeltilmiş kodun neye benzediğini hâlâ kendi çıkarmak zorundadır ve çoğu zaman bunun bekleyebileceğine karar verir.
Her yüzey farklı davranıyordu
Terminaldeki inceleme, editördeki inceleme, pull request üzerindeki inceleme ve takvimle çalışan inceleme ayrı araçlardı; ayrı davranışları ve ayrı geçmişleri vardı. Aynı değişiklik birinden geçip diğerinde kalabiliyordu.
Ne kurduk
Tek bir hat, ona ulaşan dört yol ve bir modelin tahmini ile bir kişinin okuması istenen şey arasında birkaç kat şüphe.
Her yüzeyin arkasında tek bir inceleme motoru
Tek bir hat değişikliği ayrıştırır, filtreler, zenginleştirir, ajanlara dağıtır ve sonucu birleştirir. Biçimlendirme ve saklama, çağıran tarafın işidir; yüzeylerin farklılaşıp incelemenin farklılaşmamasının nedeni budur.
- Terminal komutu, editör entegrasyonu, canlı güncellemeli API ve arka plan servisi aynı incelemeyi çalıştırır
- Tek bir ortak geçmiş: klavyede başlatılan inceleme, panonun sonra gösterdiği incelemedir
- Model sağlayıcıları tek bir arayüzün arkasındadır; birini eklemek ya da değiştirmek yeniden yazım değil, yapılandırmadır
Düzeltmesiyle birlikte gelen bulgular
Beş önem düzeyi üç eyleme iner: şimdi düzelt, yakında düzelt, sonra bak. Böylece rapor baştan aşağı çalışılabilir. Her bulgu kodun haritasından zenginleştirilir; bir kalıba değil, gerçek bir yola işaret eder.
- Her bulgu yerine geçecek kodu taşır; taşımayan bir bulguyu şema reddeder
- İncelemeler sembol dizininden zenginleştirilir: hangi fonksiyonlar değişti, onları kim çağırıyor, hangi testler kapsıyor ve ne neyi import ediyor
- Bulgular satır numarasıyla değil içerikleriyle tanımlanır; bir dosyayı yeniden biçimlendirmek, kapatılmış bir konuyu diriltmez
Tahminle rapor arasında beş kat
Her kat kendisinden sonrakinden ucuzdur; gürültü olacak şeyin çoğu, pahalı bir adım atılmadan önce elenir. Son kat katı olanıdır: platform bulguyu kaynağa karşı kanıtlamayı dener.
- Yalnızca boşluk, yorum ve import değişiklikleri tek bir modele bile gitmeden düşürülür; statik bir örüntü geçişi riskli kodu önceden işaretler
- Düşük güvenli bulgular incelemeden hemen sonra çıkarılır; ardından ikinci bir geçiş ayakta kalan her bulguya itiraz eder ve yalnızca çürütemediğini bırakır
- Yapabildiği yerde platform, iddiayı gerçek kaynağa karşı sınayan küçük bir program yazar ve bunu yalıtılmış bir kum havuzunda çalıştırır; sınama yapılamıyorsa bulgu sessizce silinmez, tutulur
Öneren ama asla uygulamayan çekişmeli mod
Bir kod tabanına karşı üç dalgalı tatbikat: bir ajan kümesi sömürülebilir bir şey arar, ikincisi yamayı yazar, üçüncüsü yamayı kapattığını iddia ettiği açığa karşı sınar. Sonuç doğrulandı, kısmen düzeldi, hâlâ açık ya da yanlış alarm olarak geri döner.
- Saldıranlar ayrı görev tanımlarıyla çalışır: iş kuralı denetçisi, kötü niyetli müşteri, kaos mühendisi, gözlemlenebilirlik uzmanı ve uyum incelemecisi; böylece tarama aynı içgüdünün beş kopyası olmaz
- Yamalar diff olarak üretilir ve doğrulanır, depoya asla yazılmaz; neyin gireceğine bir kişi karar verir
- Ajanlar, yıkıcı işlemlerin kapalı olduğu bir komut izin listesi içinde çalışır ve çıktıları enjekte edilmiş talimatlara karşı taranır
Pratikte ne değişti
Platformun ne yaptığını yayımlıyoruz, ne kadar iyi yaptığına dair bir sayıyı değil. Herhangi bir doğruluk iddiası, yayımlamadığımız bir ölçüme dayanmak zorunda.
Tek sıra
Bir inceleme ne üretir
Ajanlar arasında birleştirilmiş, yinelenenleri ayıklanmış, önem sırasına dizilmiş ve sınırlanmış bulgular. Baştan sona okunacak bir metin değil, baştan çalışılacak bir sıra.
Tahmin değil, sınama
Kişiye ne ulaşır
Önemsiz değişiklikler modele hiç gitmez, zayıf bulgular düşürülür, ayakta kalanlara itiraz edilir ve platform yapabildiği yerde bulguyu önce kaynağa karşı kanıtlar.
Kararı kişi verir
Değişiklikler nasıl girer
Düzeltmeler ve yamalar, önizlemesi ve orijinal dosyanın yedeği ile birlikte öneri olarak gelir. Kimse onaylamadan depoya hiçbir şey yazılmaz.
İnceleme süreciniz düzeltilecek işten çok okunacak metin mi üretiyor?
Şirketinizde kodun bugün nasıl incelendiğini ve nerede tıkandığını anlatın. Neyi otomatikleştirmenin değdiğini, neyin değmediğini söyleyelim.
Projenizi konuşalım