Geliştirici Araçlarına Özel Sektör Standartları: Neden Ölçümlemeleri Ayrı Bir Depoya Taşımalısınız?

Geçtiğimiz hafta, code-intelligence MCP sunucuları için bir performans ölçümlemesi yayınladım ve sonuçları — hatta kendi aracımın geride kaldığı durumları da — paylaştım. Sadece 36 saat içinde, rakip araçlardan biri olan jcodemunch-mcpnin bakımcısı, ölçümlemenin ortaya koyduğu sorunları gidermek için üç ardışık sürüm yayınladı. Yeni testler eklendikçe ise bu düzeltmelerin, kendi aracımın parse işleyicisinde de benzer bir kör nokta olduğunu gösterdi. Sonuç? Hemen bir düzeltme yayınladım.

Bu hızlı geri bildirim döngüsü — rakip geliştiricilerin aynı değerlendirme üzerinde, zıt yönlerde ilerleyerek 36 saat içinde birbirlerini tamamlamaları — bir performans ölçümlemesinin olması gereken şekilde çalışmasıdır. Ne yazık ki, bu durum neredeyse hiç gerçekleşmez ve çoğu zaman bunun nedeni, ölçümlemenin yanlış yerde bulunmasıdır.

İşte bu yüzden ben de ölçümlememi ayrı bir depoya taşıdım.

Ölçümleme Artık Bağımsız Bir Depo

Artık ölçümleme, kendi başına bir depo olarak yayınlanıyor: github.com/sverklo/sverklo-bench

Bu depoda neler var:

• README dosyası, sonuç tablosuyla birlikte — "blogu oku" yerine doğrudan karşılaştırma imkanı sunar
• METHODOLOGY.md, hangi verilerin ölçüldüğünü, hangilerinin ölçülmediğini ve neden belirli veri kümelerinin (Express, Lodash, projenin kendi monoreposu) seçildiğini belgeleyen detaylı bir açıklama
• CONTRIBUTING.md, üç farklı katkı yolunu tanımlayan rehber: temel performans sonuçlarını sunma, metodolojiyi sorgulama veya yeni veri kümeleri ekleme
• tasks/ klasörü, temel doğrulama dosyalarını referans olarak barındıran salt-okunur bir dizin

Performans çalıştırma zamanı ise ana monorepo içinde kalmaya devam ediyor; metodoloji ve sonuçlar ise bağımsız depoda sergileniyor.

Ölçümlemeyi Ayırmanın Nedeni

Çoğu geliştirici aracı, performans ölçümlemesini ana depo içinde yayınlıyor — bu doğru değil, hatta ölçümleme dürüstçe yapılmış olsa bile. İki ana neden var:

1. Ürünle Karışık Ölçümleme, Pazarlama Gibi Algılanabilir

Bir ölçümleme, geliştirildiği aracın bulunduğu aynı depoda yer aldığında, herhangi bir geliştirici, ölçümlemenin metodolojik sağlamlığını ürünün kendi kodundan bağımsız olarak değerlendiremez. Ölçümlemenin "dürüst" olduğunu kanıtlamak için, onunla ürün arasındaki ilişkiyi tamamen koparmak gerekir. Ölçümlemenin kendi commit geçmişi, kendi katkı PR'ları ve üründen bağımsız bir güvenilirlik sinyali olması şarttır.

2. Rakip Geliştiriciler, Ölçümlemeye Katılamaz

Eğer rakip bir geliştirici ölçümleme metodolojisine itiraz etmek istiyorsa — örneğin, "3. görev için beklenen çıktı yanlış, çünkü benim aracım X yerine Y çıktısını üretiyor" — o zaman tüm ürün deposunu forklamak, dizin ağacında gezmek ve ürün kodunun arasında kaybolmak zorunda kalmaz. Bağımsız bir ölçümleme deposu, rakiplere:

• Ölçümleme metodolojisini sorgulayan issue'lar açma olanağı sunar
• Temel performans sonuçlarını ayrı bir depo üzerinden PR ile sunma kolaylığı sağlar
• Araçlarının performansını zaman içinde izleme imkanı verir

Bu durum, MLPerf'in tek bir makine öğrenmesi çerçevesinin deposunda yer almamasıyla aynı mantığa sahiptir. Veya TPC ölçümlemelerinin bir veritabanı sağlayıcısının deposunda bulunmaması gibi. Ölçümleme, tüm uygulamalar arasında taşınabilir olmalıdır ve bu da onun hiçbir uygulamanın sahip olmadığı bağımsız bir depoda bulunmasını gerektirir.

Bu Yaklaşımın Getirdikleri

Ölçümleme deposunu yayınladığım ilk günden itibaren üç issue açarak süreci başlattım:

• #1 — Python kod tabanını dördüncü veri kümesi olarak eklemek. Mevcut üç veri kümesi (TypeScript, JavaScript modüler CommonJS, JavaScript monolitik IIFE), Python'ı hiç kapsamıyor. Bu açık, Python ekosistemindeki geliştiriciler için bir fırsat sunuyor.

• #2 — GitNexus bakımcısını çağrı yaparak temel performansı yenilemeye davet etmek. GitNexus, orijinal temel performans entegrasyonundan bu yana birçok sürüm yayınladı. Ölçümlemenin en güncel haliyle yansıtılmasını sağlamak için kamuoyunda davet etmek.

• #3 — jcodemunch bakımcısını çağrı yaparak temel performansı v1.80.9'a karşı yenilemeye davet etmek. jcodemunch v1.80.9 sürümüyle birlikte _meta.mode, max_results ve file_pattern gibi parametreler ekledi. Mevcut temel performans bu parametreleri kullanmıyor.

Bu issue'lar, ölçümlemenin bir geri bildirim döngüsü olarak çalışmasını ve rakiplerin temiz bir şekilde katılmasını sağlıyor.

Ölçümlemesi Olan Her Geliştiriciye Tavsiyeler

Eğer siz de bir geliştirici aracının bakımcısıysanız ve ölçümlemeniz varsa, üç somut adım atmanızı öneriyorum:

• Ölçümlemenizi ana deponuzdan ayırın. Bu, sizinadınız/sizinadınız-bench gibi bir kardeş depo, organizasyon düzeyinde ayrı bir depo veya MLPerf gibi topluluk tarafından yönetilen bir depo olabilir. Önemli olan, ölçümlemenin kendi commit geçmişine sahip olmasıdır.

• Kaybettiğiniz durumları yayınlayın. Her ölçümlemenin bir "dürüstlük bölümü" olmalıdır — aracınızın geride kaldığı alanlar. Bu kayıpları açıkça belgeleyin. İki nedenle önemlidir: (a) rakiplerin ciddi şekilde katılabilmesi için gerekli güvenilirlik sinyalini oluşturur, (b) rakiplerin düzeltme yapabileceği alanlardır. Sadece kazandığınız durumları belgeleyen bir ölçümleme, pazarlama aracından başka bir şey değildir.

• Rakiplerinize temel performans sonuçlarını sunmaya davet edin. Bunu özel veya kamuoyunda yapabilirsiniz. Eğer reddederlerse, ölçümlemenin açık olduğunu ve metodolojiye itiraz edebileceklerini gösteren bir güvenilirlik hikayesi oluşturmuş olursunuz. Eğer katılım gösterirlerse, ölçümleme tüm kategorinin skor tablosu haline gelir. Her iki durumda da, ölçümlemenin sadece orijinal yazar tarafından çalıştırıldığı bir senaryodan daha iyidir.

İlk iki adım kolaydır. Üçüncü adım ise rahatsız edicidir. Buna rağmen yapın — ölçümlemenin bir geri bildirim döngüsü olarak çalışması için tüm bu adımların tamamlanması gerekir ve üçüncü adımın yapay olarak taklit edilmesi yapısal olarak zordur.

Ölçümleme deposu: github.com/sverklo/sverklo-bench

Orijinal ölçümleme ve ölçümlemeyi ayrı bir depoya taşıma kararını motive eden hikaye: sverklo.com/bench/

Eğer bir code-intelligence aracının bakımcısıysanız ve ölçümleme metodolojisine itiraz etmek istiyorsanız, yeni depodaki issue #2 veya #3 en temiz giriş noktasıdır.

Unutmayın: Ölçümleme, geliştirici araçlarının kalitesini artırmak için sadece bir araç değildir — sektör standartlarını belirleyen bir mekanizmadır. Doğru yerde konumlandırıldığında, tüm ekosistemi yükseltir.