GitHub Anketi: 1.000 Geliştirici Verimlilik İstiyor

GitHub ile Yale Program on Climate Change Communication’ın yürüttüğü yeni anket, geliştiricilerde verimli yazılım ilgisinin yüksek olduğunu ortaya koyuyor; eksik kalan, bu ilgiyi somut mühendislik işine çevirecek araçlar ve ölçüm yöntemleri. 1.039 GitHub kullanıcısıyla yapılan çalışmada katılımcıların 10’da 8’i, daha enerji verimli kod yazmaya yardımcı olacak araçlara ilgi duyduğunu söyledi. Aşağıda anketin bulguları, bu bulguların yorum sınırları ve GitHub’ın önerdiği pratik akış var.

Ankette ne soruldu, ne çıktı

Örneklem, ABD’deki GitHub aylık aktif kullanıcıları arasından oluşturuldu. Sorular iklim değişikliği, yapay zeka, yazılım verimliliği ve teknoloji sektöründeki kurumların sorumluluklarını kapsıyordu. Öne çıkan yanıtlar şöyle:

• %79’u küresel ısınma konusunda endişeli olduğunu belirtti.
• %71’i yapay zeka sistemlerinin çevresel etkisinden (enerji ve su kullanımı ile karbon emisyonları dahil) endişe duyduğunu söyledi.
• %75’i çalıştığı kurumun çevresel etkisini azaltmak için aktif çaba göstermesini önemli buldu.

Bu rakamlar yapay zekanın ya da herhangi bir yazılım sisteminin gerçek çevresel ayak izini ölçmüyor, yalnızca ankete katılanların görüşlerini yansıtıyor. Örneklem pazarlama iletişimlerini almayı kabul etmiş GitHub kullanıcılarından oluştuğu için sonuçları tüm geliştiricileri ya da tüm GitHub kullanıcılarını temsil eden veriler olarak okumamak gerekiyor.

GitHub kullanıcıları ile ABD geneli arasındaki fark

Yale’in ulusal düzeyde temsil gücü olan Climate Change in the American Mind araştırmasındaki sorular GitHub kullanıcılarına yöneltildiğinde, katılımcılar ABD’deki yetişkin nüfusun geneline kıyasla daha yüksek düzeyde endişe bildirdi:

• Küresel ısınmanın gerçekleştiğini söyleyenler: %86 (ABD yetişkinlerinde %68)
• Konuyu en azından bir ölçüde kişisel olarak önemli bulanlar: %82 (%65)
• Kendisine en azından orta düzeyde zarar vereceğini düşünenler: %68 (%45)
• Gelecek kuşaklara en azından orta düzeyde zarar bekleyenler: %82 (%68)
• Küresel ısınma konusunda endişeli olanlar: %79 (%66)

Yorum sınırı burada da net. Rapordaki veriler, pazarlama e-postalarına onay vermiş GitHub kullanıcılarından oluşan olasılıksız (non-probability) bir örnekleme dayanıyor. Yani bulgular geliştiricilerin tamamını değil ankete yanıt verenleri tanımlıyor, ABD yetişkinleriyle arasındaki farklar da hem nüfus hem anket tasarımı farklılıklarından kaynaklanıyor.

İlgi yüksek, uygulanabilir yol eksik

Katılımcıların yalnızca %10’u, yazılım geliştirme ve kod yazma biçiminin kişisel çevresel etkisini azaltmada büyük rol oynadığını düşünüyor. %28’i orta düzeyde etkisi olduğunu, %63’ü etkinin küçük olduğunu söylüyor. Talep tarafı ise oldukça güçlü:

• %80: Daha enerji verimli kod yazmaya yardımcı araçlara ilgi duyuyor.
• %78: Yazılımın çevresel ayak izini azaltmaya yönelik en iyi uygulamaları öğrenmek istiyor.
• %74: Yazılımının veya geliştirme sürecinin çevresel etkisini ölçmekle ilgileniyor.
• %70: Sürdürülebilirliğe odaklanan açık kaynak projelere katkı vermek istiyor.

Açık uçlu yanıtlar talebin ne kadar somut olduğunu gösteriyor: depoların ve CI/CD iş akışlarının ayak izini tahmin etme, gereksiz GitHub Actions çalıştırmalarını bulma, kod verimliliğini artırma, yapay zeka kullanımını diğer işlem gücü taleplerine kıyaslama. Birkaç katılımcı da kanıtı olmayan çevresel iddialarda bulunmaya karşı uyardı.

Bu uyarı önemli. Daha hızlı kod kaynak tüketimini azaltabilir, ama tek başına çalışma süresi enerji kullanımının veya emisyonların düştüğünü kanıtlamaz. Donanım, iş yükü, konum, zaman ve elektriğin kaynağı sonucu etkiler. Ölçüm, ortaya atılan iddiayla eşleşmeli.

Ölçülebilir israfla başlayın

Yazılım verimliliği zaten iyi mühendisliğin parçası. Altyapı maliyetini düşürebilir, performansı iyileştirebilir, gecikmeyi azaltabilir, kapasite açabilir. Aynı sonucu üretmek için gereken işlem gücü azaldığında enerji kullanımı da azalabilir. Ölçülebilir israfı aramak için dört alan öneriliyor:

• Kod: Tekrarlanan hesaplamalar, verimsiz algoritmalar, gereksiz bellek ayırmaları veya önbelleğe alınabilecek pahalı işler.
• Veri: Fazla veri çekme (over-fetching), sınırsız sorgular, eksik önbellekleme veya toplu hale getirilmesi gereken veritabanı çağrıları.
• Ağ ve G/Ç: Yinelenen istekler, olay tabanlı hale getirilebilecek yoklamalar (polling), gereğinden büyük yükler veya eksik sıkıştırma.
• Frontend: Gereksiz render işlemleri, ekran dışındaki varlıkların erkenden yüklenmesi veya daha küçük formatlarla sunulabilecek medya.

Doğru metrik yapılan değişikliğe göre değişir. Çalışma süresi, CPU kullanımı, bellek ayırma ve ağ üzerinden aktarılan veri boyutu, hesaplama talebi için kullanışlı birer vekil gösterge olabilir. Her birinin sınırları var, bu yüzden neyi ölçtüğünüzü ve neyi ölçmediğinizi açıkça yazmak gerekiyor.

Örneğin O(n²) bir aramayı hash-map aramasıyla değiştiren bir pull request, temsili bir iş yükü için öncesi ve sonrası ölçümlerini, testi yeniden üretmek için gereken komutları, bellek ya da bakım kolaylığı tarafındaki ödünleşmeleri içermeli. Değişikliği veri sunmadan “daha yeşil” diye nitelemekten çok daha güçlü bir mühendislik gerekçesidir bu.

Ajan tarar, kararı maintainer verir

Büyük bir depoda verimlilik fırsatlarını taramak yavaş bir iş olabilir. GitHub Agentic Workflows bu aramayı otomatikleştirirken kararı maintainer’larda bırakmayı hedefliyor. Açık kaynak Daily Efficiency Improver iş akışı depoyu kod, veri, ağ, G/Ç ve frontend performansı açısından inceliyor, ölçülebilir değişiklikleri önceliklendiriyor, deponun testlerini çalıştırıyor, kanıt ile ödünleşmeleri içeren taslak pull request’ler açabiliyor. Değişiklikleri kendisi merge etmiyor.

İş akışını bir depoya GitHub CLI ile eklemek için:

gh extension install github/gh-aw 
gh aw add-wizard githubnext/agentics/efficiency-improver

Zamanlanmış bir iş akışını etkinleştirmeden önce izinlerini, yapılandırmasını, model kullanımını, beklenen çalışma sıklığını ve olası işlem gücü maliyetini gözden geçirin. Uygun bir test deposuyla başlayın ya da elle çalıştırın. Her öneriyi, benchmark ve testler doğrulayana kadar hipotez sayın.

Güçlü bir pull request şu beş soruyu yanıtlamalı:

1. İş akışı hangi israfı buldu?
2. Beklenen iyileşmeyi hangi metrik temsil ediyor?
3. Başlangıç değeri (baseline) neydi?
4. Değişiklik işlevselliği ve kaliteyi korudu mu?
5. Maintainer’ların dikkate alması gereken ödünleşmeler neler?

Yapay zeka olası iyileştirmeleri aramada, test etmede ve belgelemede yardımcı olabilir. Kanıtın sağlam olup olmadığına ve değişikliğin kod tabanına girip girmeyeceğine yine insanlar karar verir.

Verimliliği mühendislik döngüsünün parçası yapmak

Verimlilik çalışması, geliştiricilerin halihazırda kullandığı araçlara ve karar noktalarına yerleştiğinde sürdürülebilir hale geliyor: depo düzeyinde bir iş akışı fırsatı ortaya çıkarır, taslak pull request önerilen düzeltmeyi gösterir, benchmark ve testler değişikliğin işe yarayıp yaramadığını ortaya koyar, maintainer’lar da kabul eder, revize eder ya da reddeder. Anket katılımcılarının istediği pratik destek de bu döngüde toplanıyor; araç, ölçüm ve endişeden koda uzanan net bir yol.

Kaynaklar ve İleri Okuma

• github.blog

• GitHub Blog: Developers want more efficient software. Here’s what over 1000 GitHub users told us they need.
• Yale Program on Climate Change Communication: Software Developers on Climate Change, AI, and Sustainable Software raporu
• Daily Efficiency Improver iş akışı dokümantasyonu (githubnext/agentics)
• GitHub Actions ve npm tarafındaki tedarik zinciri saldırılarına karşı alınan önlemler