Bu Kodun Sahibi Kim: Hesap Verebilirlik ve Suçlama

“Bunu her kim yazdıysa aptalın tekiymiş” cümlesi yazılımda en sık kurulan, ama en işe yaramaz cümlelerden biridir. Analiz gibi hissettirir; oysa önemi olmayan bir soruyu yanıtlar. Bir dosyayı açıp tek bir satırı değiştirdiğiniz an, orijinal kodu kimin yazdığından bağımsız olarak, o kodun canlıdaki davranışının sahibi olursunuz. Yazarlık geçmiştir. Sahiplik ise şimdiki zamandır. Çoğu geliştirme ekibi için kalıcı yanıt şudur: makine tarafından okunabilir bir kayıt (bir CODEOWNERS dosyası ve bir servis kataloğu) ile desteklenen, gerçek bir on-call rotasyonuna sahip ekip düzeyinde servis sahipliği. Bunu işe yaratan şey ise ekiplerin yanlışlıkla eş anlamlı sandığı üç kelimedir: sorumluluk (responsibility), hesap verebilirlik (accountability) ve suçlama (blame).

Bu yazı, sürekli sahipsiz kalmış legacy kod, net sahibi olmayan on-call rotasyonları ve bir düzeltme yerine bir isimle biten incelemeler devralan geliştiriciler ve liderler için. Üç kelimeyi ayırır, ardından sağlıklı ekiplerin miras alınan kodu nasıl sahiplendirdiğini gösterir: bir operatörsüz bırakmak yerine işletilen, izlenen ve düzeltilen kod. Olay incelemesinin kendisini yeniden anlatmaz; incelemenin içinde ne yapılacağı için suçsuz postmortem modeli bu yazının tamamlayıcısıdır.

Ekiplerin Eş Anlamlı Sandığı Üç Kelime

Çoğu sahiplik tartışması aslında bir kelime tartışmasıdır. Ekipler üç farklı fikri tek kelimeye sıkıştırır, sonra da neden kimsenin hiçbir şeyin hesabını vermediğine şaşırır. Onları ayrı tutun, kafa karışıklığının büyük kısmı ortadan kalkar.

Kelime	Yanıtladığı soru	Kaç kişi	Ne zaman geçerli
Sorumluluk	Bugün işi kim yapıyor ve kodu kim işletiyor?	Paylaşılabilir	İş sürerken aktiftir
Hesap verebilirlik	Sonucun hesabını kim verir?	Tam olarak bir	Sonuçlar bilindikten sonra netleşir
Suçlama	Ahlaki kusur kimde?	Nadiren işe yarar	Yalnızca gerçek ihmal veya kötü niyet

Bu ayrım doğrudan RACI’den, yani sorumluluk atama matrisinden gelir. Kanonik kuralı şudur: bir görevin birden çok Sorumlu (Responsible) kişisi olabilir, ama tam olarak bir Hesap Veren (Accountable) kişisi olur; sorumluluk göreve dönüktür ve paylaşılabilir, hesap verebilirlik sonuca dönüktür ve tekildir. Suçlama tamamen üçüncü bir şeydir. O bir ahlaki kusurdur ve sağlıklı organizasyonların gerçek ihmal dışında neredeyse her şey için emekliye ayırdığı bir kategoriye aittir. Hesap verebilirliği suçlamayla karıştırmak, bu yazının çözmeye çalıştığı temel hatadır.

Bunu kararlar hakkında değil, kod ve servisler hakkında tutun. Bir kararın hesabını kimin verdiği farklı bir sorudur ve rol beklentileri ile ekip performansı yazısında ele alınır. Burada konu her zaman çalışan bir servis ve onu kimin işlettiğidir.

Yazarı Suçlamak Neden Titizlik Gibi Hissettirir

Önceki geliştiriciyi suçlamak titizlik gibi hissettirir; çünkü temiz bir anlatı ve hızlı bir kapanış üretir. Aynı zamanda kodun neden o hâle geldiği konusunda yanlıştır ve bu yanlış pahalıdır.

Kendimi bunu yaparken yakaladım. Tanımadığım bir modülü açtığımda, bunu her kim yazdıysa framework’ü anlamamış diye söylendim. Sonra gözden kaçırdığım kısıtı açıklayan commit’i buldum: yalnızca o kesin biçimdeki istekleri kabul eden bir tedarikçi API’si. Kod dikkatsiz değildi. Artık göremediğim bir duruma verilmiş makul bir yanıttı.

Bu refleksin bir adı var. Ross’un 1977 tarihli çalışmasında tanımlanan temel atıf hatası (fundamental attribution error), başkalarının davranışını karakterleriyle, kendi davranışımızı ise koşullarımızla açıklama alışkanlığımızdır. Kod okumaya uygulandığında, önceki geliştiricinin “kötü” kodu genellikle bir teslim tarihine, bir veri biçimine ya da o günün bir aracına verilmiş makul bir yanıttı; sizin artık göremediğiniz bir yanıt. Geriye dönük bakış hatayı bariz gösterir; oysa orijinal kısıtlar altında bariz değildi.

Chesterton’ın Çiti (Chesterton’s Fence) bu refleksi durduran disiplindir. Bir çiti yıkmadan önce neden dikildiğini öğrenin. Onun bir işe yaramadığını söyleyen reformcuya şu yanıt verilmelidir: bir işe yaradığını görmüyorsan, önce git öğren, ancak ondan sonra onu kaldırmana izin verebilirim. Kodda “çit” o tuhaf koşul, o retry, o anlamsız görünen bekleme çağrısıdır. Silmeden önce kısıtı anlayın.

Miras alınan kodu devralmayı ve yeniden işlemeyi güvenli kılan şey, Weinberg’in egosuz programlama (egoless programming) fikridir: biz kodumuz değiliz. Kodu, yazan kişinin bir uzantısı olarak değil, ekibin sahip olduğu bir nesne olarak görün. Kod kişisel bir şey olmaktan çıkıp paylaşılan bir nesne olduğunda, onu eleştirmek ve yeniden işlemek bir saldırı olmaktan çıkar ve bakıma dönüşür.

Sahiplik Şimdiki Zamandır

Sahiplik bir wiki’deki etiket değildir. Bir servisi işlettiğinizde, izlediğinizde, düzelttiğinizde ve geliştirdiğinizde ona sahip olursunuz. Werner Vogels bu işleyiş modelini 2006 tarihli bir söyleşide “you build it, you run it” (sen inşa edersin, sen işletirsin) olarak tanımladı: geliştiricilere yazılımlarının işletimiyle ve müşteriyle günlük temas sağlamak, geri bildirim döngüsü doğrudan olduğu için kaliteyi artırdı.

Miras alınan bir kod parçası bozulduğunda, üç soru sırayla işler. Yalnızca ilk ikisinin işe yarar yanıtı vardır.

Kim işletiyor sorusuyla başlayın. Sahip ekibi CODEOWNERS veya katalog üzerinden bulun. Sahip yoksa asıl bug sahipsiz sahipliktir; koda dokunmadan önce bir sahip atayın. Sonra sonucun hesabını kimin verdiğini sorun: tek bir hesap veren ekip, asla orijinal yazar değil. Yalnızca en sonda gerçekten kusurlu biri olup olmadığını sorun; yanıt neredeyse her zaman hayırdır. Kusur, varsayılan değil, Just Culture yoluna yönlendirilen nadir istisnadır. Pratikte sahip bir ilk müdahale eden kişidir, bir sanık değil.

Sahipliği Makine Tarafından Okunabilir Kılmak

Bir wiki’de ilan edilen sahiplik, sınandığı an buharlaşır. Hayatta kalan sahiplik makine tarafından okunabilir ve pager’a bağlıdır. Yükün çoğunu iki artefakt taşır.

Bir CODEOWNERS dosyası, yol desenlerini sahip ekiplere eşler. Bir pull request bir yola dokunduğunda, GitHub eşleşen ekipten otomatik olarak inceleme ister ve yöneticiler birleştirmeden önce kod sahibinin onayını zorunlu kılabilir. Eşleşen son desen kazanır ve sahiplerin depo üzerinde yazma erişimi olması gerekir.

# .github/CODEOWNERS
# Her satır bir yol desenini bir veya daha fazla sahip ekibe eşler.
# Eşleşen son desen öncelik kazanır.

*                     @acme/platform
/services/billing/    @acme/payments
/services/checkout/   @acme/checkout
/infra/               @acme/platform @acme/sre
*.tf                  @acme/sre

İkinci artefakt bir servis kataloğudur. Backstage’de Component, API ve System gibi çekirdek katalog varlıkları, bir Group veya User’a çözülen bir spec.owner bildirmek zorundadır; bu da her servisin sahibi için tek bir doğruluk kaynağı verir.

# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: billing-service
  description: Charges and invoices for customer accounts
  annotations:
    github.com/project-slug: acme/billing-service
    pagerduty.com/service-id: PXXXXXX
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: billing

Bir uyarı, herhangi bir alandan daha önemlidir. Kapatılmış bir ekibi işaret eden sahip, hiç sahip olmamaktan daha kötüdür; çünkü yanıtlanmış gibi görünürken kimse evde değildir. Kayıt, girdilerin sessizce değil, sesli çürümesi için gerçek bir organizasyon şeması kaynağına ihtiyaç duyar. İşe yarar yerel bir sinyal, adlı ve canlı bir sahibi olan servislerin oranıdır; bunu neredeyse tam kapsamaya, sahipsiz servisleri ise sıfıra doğru izleyin. Bunu kaynak gösterilebilir bir kıyas noktası değil, kendi ürettiğiniz bir gösterge olarak değerlendirin.

Burada gerçek bir denge var. Katı kod sahipliği, kolektif kod sahipliğine karşı çalışan inceleme darboğazları ve “benim kodum değil” siloları yaratabilir. Çözüm, sahipliği bir kişiye değil bir ekibe kapsamaktır. Adlı bir hesap veren ekip, hesap verebilirliği tekil tutarken kod kolektif olarak düzenlenebilir kalır; ekip düzeyinde sahiplik, bireysel kapı bekçiliğiyle aynı şey değildir.

Sahiplik Ayrılmalardan Kurtulur, Sahipsizlik Kurtulmaz

Sahip bir ekip, sahip bir kişinin kurtulamadığı bir şeyden kurtulur: bir ayrılıştan. Bireysel sahiplik bir kişilik bir bus factor yaratır ve bilgi kişiyle birlikte gider. “Software Engineering at Google”, bir ekibin başarısını tek bir kişiye atfeden Deha Miti’ni (Genius Myth) bir tuzak olarak adlandırır ve kalıcı sahipliği birincil ve ikincil bir sahip ile dokümantasyona bağlar. Sahiplik bir ekip özelliğidir; yalnız kahraman bir ideal değil, bir risktir.

Bir kişi veya ekip ayrıldığında, sahiplik sessizce düşürülmez, bir ritüelle devredilir. Ritüel runbook’u, dashboard’ları, erişimi, bilinen sorunları ve pager’ı teslim eder. Bunu atlarsanız servis sahipsiz kalır: sonraki olayda ilk müdahale eden kimse olmaz ve konuşma yeniden “bunu kim yazdı?” sorusuna döner. Yüksek bir bus factor devri en baştan mümkün kılan şeydir. Operasyonel sahipliği Tamamlanmış Tanımınıza (Definition of Done) katın, böylece bir özellik, adlı bir ekip onu işletmeyi sahiplenmeden bitmiş sayılmasın.

Liderlerin Sorduğu Soru

Bir liderin herkesin önünde sorduğu soru, tüm ekibe bir sonraki adımda ne yapacağını öğretir. Açıkça sorulan “bunu kim bozdu?” insanlara bir sonraki sorunu gizlemeyi öğretir ki bu, liderin istediği hesap verebilirliğin tam tersidir. Onu farklı bir soruyla değiştirin: hangi servis, hangi sahip ve neyi değiştiriyoruz?

Amy Edmondson’ın psikolojik güvenliği (psychological safety) sağlıklı döngünün ön koşuludur. Sorular, endişeler ve hatalarla sesini yükseltmenin güvenli olduğuna dair ortak inançtır. Kibar olmakla ilgili değildir; cezalandırılma korkusu olmadan açık sözlülüktür. O olmadan dürüst sahiplik değil, gizlenmiş sorunlar elde edersiniz. Liderler bunu suçlamayı üstlenerek ve krediyi dağıtarak pekiştirir ki bu da Extreme Ownership’in gerçekten işe yarayan yarısıdır.

Ne Zaman Varsayılanı Geçersiz Kılmalı

Ekip düzeyinde servis sahipliği varsayılandır, ama iki durum farklı bir kurulumu haklı çıkarır ve popüler bir çerçeveleme bir koruma bandına ihtiyaç duyar.

Küçük ekipler veya düşük kritiklikteki kod için bireysel sahiplik kabul edilebilir. Bus-factor riski gerçektir ama kod kritik yolda değilken ve ekip herkesin okuyabileceği kadar küçükken tolere edilebilir. Kaçınılması gereken sürüm, gayri resmi “X’e Slack’ten sor” sahipliğidir; çünkü her yeniden yapılanmada sızar ve arkasında hiçbir artefakt bırakmaz.

Extreme Ownership, yani kötü ekip yoktur yalnızca kötü lider vardır diyen liderlik fikri, aynı nefeste hem yararlı hem tehlikelidir. Gücü, bir liderin suçlamayı üstlenmesi ve sonucu sahiplenmesidir. Başarısızlık biçimi ise sistemik bir başarısızlığı tek bir kişiye yeniden özelleştirmesidir; suçsuz kültürün düzeltmek için var olduğu tam da o şey. Sentez dar ve önemlidir: kişisel olarak kusurlu olmayı değil, sistemi düzeltmeyi sahiplenin. Bir lider sonucu ve onarımı sahiplenir; bir sistem boşluğunu kişisel suça çevirmez.

“You build it, you run it” kaliteyi artırır, ama tam ve farklılaşmamış sahiplik bir tükenmişlik vergisine dönüşebilir. Eleştirmenler, her ekip kendi her şeyini işlettiğinde modeli on-call yüküne ve bilişsel yük yayılmasına bağlar. Platform mühendisliği karşı görüşü ilkeyi korur ve farklılaşmamış yükü, bazen golden path (altın yol) denen döşenmiş yollar üzerinden bir platform ekibine taşır. Uyarı dürüsttür: kötü kurulmuş bir platform yükü ortadan kaldırmaz, yalnızca yerini değiştirir. “Ona sen sahipsin” için döşenmiş bir yol gerekir, yoksa sahiplik insanların sessizce ödemeyi reddettiği bir vergiye dönüşür.

Yaygın Tuzaklar

Birkaç hata biçimi tekrar tekrar ortaya çıkar; her birinin somut bir çözümü var.

• Miras alınan kodu anlamadan yeniden yazmak. Çiti kaldırmadan önce neden orada olduğunu öğrenin.
• Sahipliği arkasında hiçbir şey olmayan bir wiki’de ilan etmek. Sahiplik CODEOWNERS’ta veya katalogda yaşamalı ve bir pager taşımalıdır.
• Bir sonuç için beş kişinin “hesap veren” olması. Tam olarak bir hesap veren ekip; geri kalanı sorumludur.
• Hesap verebilirliği suçlamayla eş anlamlı saymak. Hesap verebilirlik sonucun hesabını verir ve düzeltmeyi yürütür; suçlama ahlaki kusur atar ve nadiren yardımcı olur.
• Ayrılışta servislerin sahipsiz kalmasına izin vermek. Bir sahiplik-devir ritüelini offboarding’in ve her yeniden yapılanmanın parçası yapın.
• Liderlerden açıkça “bunu kim bozdu?” sorusu. Sağlıklı soruyu örnekleyin, suçlamayı üstlenin ve krediyi dağıtın.

Sonuç

Varsayılan neredeyse her şey için geçerlidir. Sahipliği bir ekibe kapsayın, onu CODEOWNERS’ta ve bir servis kataloğunda makine tarafından okunabilir kılın, bir on-call rotasyonuyla destekleyin ve üç kelimeyi ayrı tutun. Sorumluluk onu kimin işlettiğidir, hesap verebilirlik hesabı veren tek ekiptir ve suçlama bir Just Culture incelemesine yönlendirdiğiniz nadir istisnadır. Bireysel sahipliğe yalnızca küçük, düşük kritiklikteki kodda başvurun ve “you build it, you run it” ilkesini döşenmiş bir yolla eşleştirin ki sahiplik tükenmişliğe dönüşmesin.

Bu yazıdan sonra tek bir şey yapacaksanız, en çok miras aldığınız servisi açın ve bir kayıtta adlı, canlı bir sahibi olup olmadığını kontrol edin. Yoksa asıl bug budur ve bu, kodu her kim yazdıysa onun isminden çok daha işe yarar bir bulgudur.

Kaynaklar

• A Conversation with Werner Vogels (ACM Queue, 2006) - “You build it, you run it” ifadesinin birincil kaynağı; kalite kaldıracı olarak geliştiricinin operasyonel sorumluluğu.
• Responsibility assignment matrix (RACI) — Wikipedia - Sorumlu-hesap veren ayrımının kanonik tanımları; görev başına bir Hesap Veren, Sorumlu paylaşılabilir.
• Atlassian — RACI chart - Ekipler için sorumlu ve hesap veren ayrımının pratik, tarafsız bir yeniden ifadesi.
• Amy Edmondson — The Fearless Organization (HBS) - Psikolojik güvenlik tanımı; dürüst sahipliğin ön koşulu.
• The American Chesterton Society — “Taking a Fence Down” - “The Thing” (1929) eserinden Chesterton’ın Çiti; henüz anlamadığınız şeyi kaldırmayın.
• Fundamental attribution error — SimplyPsychology - Ross’un aşırı atıf yanlılığının, başkalarının işini okumaya uygulanmış erişilebilir tanımı.
• Lee Ross (1977) — orijinal makale (PDF) - Temel atıf hatası için birincil kaynak.
• Egoless programming — Wikipedia - Weinberg’in 1971 kavramı: “biz kodumuz değiliz”; kişiyi artefakttan ayırmak.
• GitHub Docs — About code owners - CODEOWNERS dosyasının konumu, söz dizimi ve otomatik inceleme davranışı.
• Backstage — Descriptor format (catalog-info.yaml) - spec.owner zorunluluğu; sahiplik doğruluk kaynağı olarak servis kataloğu.
• Software Engineering at Google — Ch. 2: How to Work Well on Teams - Deha Miti, bus factor ve ekip özelliği olarak sahiplik.
• Extreme Ownership — liderlik ilkeleri (özet) - Willink ve Babin’in “kötü ekip yoktur, yalnızca kötü lider vardır” fikri; burada sistem düşüncesiyle gerginlik için alıntılandı.
• Platform Engineering — Whose cognitive load is it anyway? - “Sen işletirsin” tükenmişlik ve bilişsel yük eleştirisi, artı golden-paths karşı argümanı.
• Martin Fowler — Code Ownership - Güçlü, zayıf ve kolektif kod sahipliği modelleri ve dengeleri.
• Suçsuz Postmortem: Bir Model ve Kopyala-Yapıştır Şablon - Bu yazının olay-inceleme tamamlayıcısı; kusur gerçekten söz konusu olduğunda ne yapılacağı.