Bağlam Değiştirmenin Gerçek Maliyeti: 5 Milyon GitHub PR
5 milyonun üzerinde PR'dan derlenen verilerle geliştiriciler için gerçek bağlam değiştirme maliyetini ölçtük – ve sonuç sandığınız yerde değil.
By Ellis Keane · 2026-03-29
Çoğu makalenin aktardığı bağlam değiştirme maliyeti – Gloria Mark'ın UC Irvine araştırmasından alınan, bir kesintinin ardından yeniden odaklanmak için 23 dakika – gerçek bir çalışmadan elde edilmiş gerçek bir bulgudur. Ancak bu çalışma, yazılım mühendislerini değil, 2008 yılındaki genel bilgi çalışanlarını ölçmüştür. Üstelik 23 dakikayı tahmini günlük kesinti sayısıyla çarparak ürkütücü yıllık dolar rakamları üretme endüstrisi (baş tutan birinin stok fotoğrafı eşliğinde), özgün araştırmanın hiçbir zaman amaçlamadığı bir şeyi yapmaktadır.
Bu konuda kişisel bir çıkarım var. Önceki bir şirkette – abartmıyorum – bazı günlerimin %80 ila %100'ünü yalnızca bir insan yönlendirici olarak geçirdim. Kod yazmadım, inceleme yapmadım. Hiçbir sistemin onları birbirine bağlamadığı için insanlar ve araçlar arasında bilgi aktardım. O deneyim Sugarbug'ı neden kurduğumuzu kısmen açıklıyor; ama aynı zamanda standart bağlam değiştirme maliyeti hesaplayıcılarına neden kuşkuyla baktığımı da. Bunlar kesintileri ölçüyor. Asıl yapmanız gereken şeye hiç ulaşamadığınız günleri ölçmüyor.
Bu yüzden bağlam değiştirmenin mühendislik çalışmasında gerçekte ne kadara mal olduğunu anlamak istedik – soyut geliştirici üretkenliği açısından değil, ekiplerin her gün ürettiği somut çıktı olan pull request'ler üzerinden. 5 milyonun üzerinde PR'ı kapsayan üç büyük ölçekli çalışmanın bulgularını sentezledik ve pull request inceleme süresini gerçekte neyin yönlendirdiğine baktık.
Ana bulgu: kod incelemesindeki en pahalı bağlam değiştirme, akışınızı kıran Slack bildirimi değildir. Sorular nihayet geldiğinde yazarı tüm zihinsel modeli yeniden oluşturmaya zorlayan, bir gün boyunca inceleme kuyruğunda bekleyen pull request'tir.
Yararlandığımız Veri Setleri
Özel bir tarayıcı oluşturup 10.000 PR'ı tek başımıza analiz etmedik. İki hakemli çalışmanın ve bir büyük sektör veri setinin bulgularını sentezleyerek sonuçlarını birbirleriyle test ettik.
stat: "3.35M" headline: "Zhang ve ark. tarafından analiz edilen pull request sayısı" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Üç temel veri seti:
- Zhang ve ark. (2022), hakemli: 11.230 projede 3.347.937 kapatılmış PR. PR inceleme gecikmelerini neyin tetiklediğini belirlemek için karma etkili doğrusal regresyon kullandı. Empirical Software Engineering dergisinde yayımlandı.
- Adadot (2023), sektör veri seti: ~30.000 geliştiriciden 300.000'den fazla birleştirilmiş PR. Hakemli değil, ancak örneklem büyük ve metodoloji (Kendall tau korelasyonu) şeffaf. PR boyutu ile teslim süresi ilişkisine odaklandı.
- Çoklu inceleme çalışması (2019), hakemli: 760 GitHub projesinde 1.836.280 PR. Information and Software Technology dergisinde yayımlandı. Eş zamanlı inceleme davranışını inceliyor – kod incelemesinde bağlam değiştirmenin doğrudan bir göstergesi.
Bu verileri 2024 DORA State of DevOps Report ve Atlassian'ın 2024 Geliştirici Deneyimi Raporu ile çapraz referans aldık (2.100'den fazla geliştiriciye bağlam değiştirme, geliştirici üretkenliği ve insani boyut üzerine anket yapıldı).
Asıl Katil Kuyruktur
Zhang ve ark., bir PR'ın ilk yanıtı alması için geçen sürenin – ilk yorum, ilk inceleme, herhangi bir şey – PR'ın toplam ömründeki varyansın %58,7'sini açıkladığını buldu. Bu, veri setindeki gözlemlenen en güçlü tahmin edicidir – PR boyutunun, kod karmaşıklığının veya değiştirilen dosya sayısının önüne geçiyor! Hiç yakın değil.
Kod incelemesinde bağlam değiştirmenin en büyük maliyeti değiştirmenin kendisi değildir – herkesin başka şeyler arasında değiştirme yaparken oluşan kuyruktur.
Bunun pratikte ne anlama geldiğini düşünün. Bir mühendis sabah 10'da PR açar. Atanmış inceleyici kendi özellik dalında derinlemesine çalışmaktadır, ya da bir toplantıdadır, ya da Slack mesajlarını sıralıyordur (dürüst olmak gerekirse muhtemelen sırasıyla üçü de). PR bekler. Öğleden sonra 3'te biri onu aldığında, yazar tamamen başka bir şeye geçmiş olur. Şimdi inceleyicinin soruları vardır; bu da yazarın beş saat önce yazdığı koda geri dönmesi, zihinsel modeli yeniden oluşturması ve yanıt vermesi gerektiği anlamına gelir. Bu yanıt 16:30'da gelir ama inceleyici eve gitmiştir.
PR bir gün daha yaşlanır.
Veri, bunun bir disiplin sorunundan çok bir kuyruklama sorunu olduğunu gösteriyor – ve bu kuyruğun bağlam değiştirme maliyeti, kesinti hesaplayıcılarının tamamen gözden kaçırdığı şekillerde birikmektedir.
Küçük PR'lar Sizi Kurtarmaz
Bunu daha önce duymuşsunuzdur: daha küçük PR'lar daha hızlı incelenir, bu yüzden PR'larınızı küçük tutun. Bu tam anlamıyla yanlış değil, ama etki boyutu (gerçekten) beklediğinizden küçük.
Adadot'un 300.000'den fazla PR analizinde PR boyutu ile teslim süresi arasında Kendall tau korelasyonu yalnızca 0,06 bulundu – toplam rakam için güven aralıkları rapor edilmemiş olsa da zayıf bir ilişki. 100 satırın altındaki PR'ların bir hafta içinde tamamlanma olasılığı yaklaşık %80'dir; bu kulağa hoş gelir, ta ki bunun altı günlük inceleme kuyruğunda bekleyen bir PR'ın aynı tamamlanma oranı olduğunu fark edene kadar!
stat: "0.06" headline: "PR boyutu ile teslim süresi arasındaki korelasyon" source: "Adadot'un ~30.000 geliştiriciden 300.000'den fazla PR analizi (2023)"
Daha ilginç bulgu: bu korelasyon kuruluşlar arasında büyük farklılık gösterdi, şirkete bağlı olarak 0,1 ile neredeyse 0,7 arasında değişti. Bu, PR boyutunun doğası gereği darboğaz olmadığını – asıl meselenin PR çevresindeki inceleme kültürü ve süreci olduğunu gösteriyor. Güçlü bir inceleme kadansına sahip ekip, daha büyük PR'ları verimli şekilde ele alabilir. İncelemeleri sonradan düşünen bir ekip, her boyuttaki PR'da zorlanır.
SmartBear/Cisco kod inceleme çalışmasındaki 400 satır eşiği, kullanışlı bir kural olarak hâlâ geçerliliğini korumaktadır – Adadot'un verileri de bu aralığın ötesinde inceleme bağlılığının düştüğünü ortaya koymuştur. Ancak temel inceleme kadansını düzeltmeden yalnızca küçük PR için optimizasyon yapmak (bunu denemiş her mühendislik yöneticisine gerçek bir sevgiyle söylüyorum) batan bir gemide şezlong düzenlemektir.
Herkes Her Şeyi Aynı Anda İnceliyor
Çoklu inceleme çalışması, pull request'lerin %62'sinin birden fazla PR'ı eş zamanlı olarak inceleyen geliştiricileri kapsadığını buldu. Daha önemlisi, istatistiksel olarak anlamlı bir korelasyon buldular: inceleyici başına daha fazla eş zamanlı inceleme, daha uzun PR çözüm gecikmesiyle ilişkiliydi.
Pull request'lerin %62'si aynı anda birden fazla PR inceleyen geliştiricileri kapsıyor – ve çoklu inceleme doğrudan daha uzun çözüm süreleriyle ilişkili. attribution: Çoklu inceleme pull-request çalışması, 760 projede 1,8 milyon PR
Mekanizma sezgisel (çalışma gözlemsel olduğundan nedensellik yönünü kanıtlamamış olsa da). Bir inceleyici PR #1'i alır, farkı okur, kodun ne yapmaya çalıştığına dair zihinsel model oluşturmaya başlar. Ardından bir bildirim gelir – PR #2'nin incelenmesi gerekiyor çünkü bir dağıtımı engelliyor. İnceleyici geçiş yapar. PR #1'e döndüğünde, zihinsel model bozulduğu için farkın yarısını yeniden okumak zorunda kalır.
Bunu her biri iki ya da üç PR açık olan, her biri iki ya da üç iş arkadaşı için inceleme yapan sekiz mühendislik ekibine yayın; koordinasyon maliyeti kendiliğinden açıklanmaya başlar. Ayrıca 2024 DORA Raporu, "yüksek performanslı" kümenin %31'den %22'ye gerilediğini, düşük performanslı kümenin ise %17'den %25'e büyüdüğünü buldu. DORA, PR inceleme eş zamanlılığını ayrı bir etken olarak ele almıyor, ancak artan koordinasyon maliyeti bu değişimin olası bir katkısıdır.
Bağlam Değiştirme Maliyeti Tahminlerinin Yanıldığı Yer
Bağlam değiştirme maliyeti makalelerinde yaygın biçimde dolaşan "geliştirici başına yılda 50.000 dolar" rakamı hakkında doğrudan konuşayım. Bu tahminlerin çoğunun arkasındaki metodoloji şu şekildedir: 23 dakikalık yeniden odaklanma süresini alın, tahmini günlük kesinti sayısıyla çarpın (yazarın o an ne kadar dramatik hissettiğine bağlı olarak genellikle 6 ila 15 arasında), saatlik geliştirici ücretiyle çarpın ve yıllığa çevirin.
Sorun, matematiğin yanlış olması değil. Sorun, tüm bağlam değiştirmeleri eşdeğer olarak ele almasıdır. Derin kodlamadan takımın öğle yemeğinin nerede olduğunu soran bir Slack mesajına geçmek – bu bir bağlam değiştirmedir. Tamamen farklı bir kod tabanındaki farklı bir PR'ın incelenmesine geçmek – bu da bir bağlam değiştirmedir. Ama bilişsel maliyet karşılaştırılamaz bile, ve bunları tek bir saatlik ücrete indirgemek gerçek hasarın nerede olduğunu gizler.
Somut bir örnek verecek olursam: son işimde tipik bir gün Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster ve sayısız Telegram ve Signal kanalı arasında geçiş yapmak anlamına geliyordu – muhtemelen yarım düzinesini unutuyorum. Şimdi bir avuç araç kullanıyorum (Signal, Obsidian, Figma, GitHub, e-posta, takvimler). Geçiş başına maliyet değişmedi. Değişen şey, dikkat için sıraya giren bağlam sayısıydı – ve bunlardan hangilerinin gerçekten önemli olduğu.
PR verisi, pahalı geçişlerin akışı kesenlerin değil, kuyruklar oluşturanların olduğunu gösteriyor. Bir PR'ı anında (dakikalar içinde) incelemeye çağrılan ve hızlı bir 50 satırlık inceleme yapan geliştirici – bu yüksek getirili kısa bir kesinti. İnceleme isteğini dört diğeriyle birlikte kuyruğa alıp yarın buna gelen geliştirici – bu inceleyici için daha uzun bir kesinti, ama yazar ve ekip için çok daha büyük bir maliyettir.
Maliyet hesaplayıcılarının ölçtüğü
- Bireysel kesintiler – birinin akışının ne sıklıkla kırıldığı
- Yeniden odaklanma süresi – önceki göreve dönmenin ne kadar sürdüğü
- Saatlik ücret çarpımı – büyük ürkütücü yıllık rakamlar
PR verisinin gerçekte gösterdiği
- Kuyruk oluşumu – ilk yanıt bekleyen PR'lar
- İnceleme eş zamanlılığı – birden fazla PR'ı dengeleyen inceleyiciler
- Kademeli gecikmeler – yazar bağlam değiştirmelerinin inceleyici gecikmelerini katlayan etkisi
Ekibiniz İçin Anlamı
Ekibinizdeki geliştiriciler için bağlam değiştirme maliyetini azaltmaya çalışıyorsanız, pratik yanıt sıkıcıdır – muhtemelen bu yüzden pek yazılmıyor. Bir araç değil. Sertifika programı olan bir süreç çerçevesi değil. İnceleme kadansı. (Biliyorum, biliyorum. İnceleme kadansını iyileştirerek terfi eden kimse görmedim.)
LinearB'nin 2025 mühendislik kıyaslamaları, 3.000 kuruluştaki 6,1 milyon PR'dan elde edilen verilere dayanarak, elite döngü sürelerine ulaşan ekiplerin (2,5 günün altında) ortak bir özelliği paylaştığını buldu: PR'ları hızlı incelediler. Daha az PR'ları olduğu ya da PR'ları daha küçük olduğu için değil (her ne kadar genellikle öyle olsa da), inceleme isteklerine saatler içinde yanıt vermek bir ekip normu olduğu için.
Belirtmek gerekirse, Ben ve ben – iki kişilik bir ekip – ilk PR yanıtında saatler değil dakikalar ortalamasındayız. Bu disiplin hakkında bir övünç değil (değiliz). Bir ekip anlaşması: inceleme istekleri, kuyruğa almadığınız tek bildirimdir. CI aksiyonları ve otomatik testler mekanik kontrolleri halleder; bu da insan incelemesi – gerçek bağlam gerektiren kısmı – daha kısa ve anında gerçekleşir. Önce anlaşma geldi. Araçlar bunu sürdürülebilir kıldı.
Pratikte bu şu anlama gelir:
- Yalnızca döngü süresini değil, ilk yanıt süresini ölçün. DORA metriklerini takip ediyorsanız bunu ekleyin. Zhang ve ark.'a göre PR veriminin tek en güçlü tahmin edicisi (ömür varyansının %58,7'sini açıklıyor).
- İnceleme eş zamanlılığını sınırlayın. Bir inceleyicinin bekleyen üç inceleme isteği varsa, dördüncüsü zaten iyi bir inceleme almayacaktır. Çoklu inceleme verisi, eş zamanlılık ve gecikme arasında açık bir ilişki gösterdi. İki eş zamanlı incelemenin WIP sınırıyla başlayın ve etkiyi izleyin.
- PR boyutunu ayrı ayrı optimize etmeyi bırakın. Küçük PR'lar iyidir, ancak gerçekten inceleme yapan bir ekibin yerini tutmaz. 48 saatlik inceleme birikimi olan yirmi adet 50 satırlık PR üreten ekip, aynı gün inceleme yapan beş adet 200 satırlık PR üreten ekipten daha kötü durumdadır.
- İncelemenin gerçek iş olduğunu kabul edin. Atlassian'ın 2024 anketi, geliştiricilerin %69'unun her hafta verimsizlikler nedeniyle 8+ saat kaybettiğini buldu. İnceleme bu verimsizliklerden biri olmak zorunda değil – ama yalnızca "gerçek" işe yönelik bir kesinti olarak değil, birinci sınıf bir mühendislik faaliyeti olarak ele alındığında.
Ve işte üretkenlik araçları alanındaki hiç kimsenin (biz dahil, dürüst olmak gerekirse) yüksek sesle söylemek istemediği kısım: mühendislik ekiplerinde bağlam değiştirme maliyeti için en etkili müdahale bir araç değildir. PR'ların ne zaman inceleneceğine dair bir ekip anlaşmasıdır. Ekibinizin örtük normu "Boş bulduğumda incelerim" ise, hiçbir araç PR verilerinin ortaya koyduğu kuyruklama basamağını önleyemez.
Araçlar yardımcı olur – dört tarayıcı sekmesi açmadan bir PR'ın tam bağlamını görebilmek, geçiş başına bilişsel yükü azaltır; başkalarının çalışmasını hangilerinin engellediğini görünür kılmak önceliklendirmeye yardımcı olur. Ama asıl kaldıraç anlaşmadır; anlaşmalar ücretsizdir. 23 dakikalık hesaplayıcı gerekmez.
En pahalı bağlam değiştirme, akışınızı kıran bildirim değildir. Sorular nihayet geldiğinde yazarı zihinsel bağlamı yeniden oluşturmaya zorlayan, bir gün boyunca kuyrukta bekleyen inceleme isteğidir.
Sinyal istihbaratını doğrudan gelen kutunuza alın.
Sıkça Sorulan Sorular
Q: Geliştirici başına yıllık bağlam değiştirme maliyeti ne kadardır? A: Tahminler değişmekle birlikte, altta yatan araştırma çoğu makalenin önerdiğinden daha zayıftır. Gloria Mark'ın UC Irvine çalışması kesinti başına 23 dakikalık yeniden odaklanma süresi buldu; Atlassian'ın 2.100'den fazla geliştiriciye yönelik 2024 araştırması ise %69'unun her hafta verimsizlikler nedeniyle 8+ saat kaybettiğini ortaya koydu. Dolar rakamı büyük ölçüde maaş varsayımlarına, kesinti sıklığına ve "değiştirme"yi nasıl tanımladığınıza bağlıdır – bu yüzden biz PR verisine odaklandık.
Q: Sugarbug mühendislik ekipleri için bağlam değiştirmeyi azaltmaya yardımcı oluyor mu? A: Evet. Sugarbug, Linear, GitHub, Slack ve Figma gibi araçları tek bir bilgi grafiğine bağlar; böylece mühendisler dört sekme açmadan bir görevin tam bağlamını – ilgili PR'ı, Slack tartışmasını, Figma yorumunu – görebilir. Amaç daha az değiştirme, daha az araç değil.
Q: İnceleme gecikmelerini en aza indirmek için ideal pull request boyutu nedir? A: Adadot'un 300.000'den fazla PR analizinden elde edilen araştırma, 100 satırın altındaki PR'ların bir hafta içinde tamamlanma olasılığının yaklaşık %80 olduğunu buldu. 400 satırın üzerinde hem inceleme kalitesi hem de tamamlanma hızı düşüyor. Daha küçük PR'lar aynı zamanda inceleyicinin bağlam değiştirme yükünü de azaltır.
Q: Sugarbug GitHub pull request'leriyle entegre oluyor mu? A: Evet. Sugarbug GitHub aktivitesini – PR'ları, yorumları, incelemeleri ve durum değişikliklerini – toplar ve bunları diğer araçlarınızdaki ilgili sinyallerle ilişkilendirir. Bir Linear issue PR'ı tetiklediyse ve bir Slack thread yaklaşımı tartıştıysa Sugarbug üçünü otomatik olarak birbirine bağlar.
Q: "Yeniden odaklanmak için 23 dakika" istatistiği nereden geliyor? A: Gloria Mark'ın UC Irvine'deki araştırmasından geliyor; "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008) adlı çalışmada yayımlandı. Araştırma, çalışanların bir kesintiden sonra orijinal görevlerine geri dönmek için ortalama 23 dakika 15 saniye harcadığını buldu. Çalışmanın yazılım mühendislerini değil, genel bilgi çalışanlarını gözlemlediğini belirtmek gerekir.