Kodu bilen tek kişi ayrıldı: tek kişi bağımlılığı nasıl kırılır?

Yazılımınızı tek kişi biliyorsa asıl risk o kişinin ayrılması değil, ayrılana kadar kimsenin bunu bir mesele saymamasıdır. Bu duruma literatürde otobüs faktörü deniyor: projenin durması için kaç kişinin aynı anda ortadan kaybolmasının yeterli olduğu sayı. Çoğu şirkette cevap bir. İyi haber şu ki çözüm "aynı işi bilen ikinci bir geliştirici tutmak" değil; bilgiyi kişinin kafasından çıkarıp sistemin okunabilir bir parçası haline getirmek yeterli. Devredilmesi gereken üç şey var: çalışan sisteme erişim, alınmış kararların gerekçesi ve rutin işlerin adımları. Kod zaten sizde duruyor, eksik olan kod değil.

Rakamlar bu tablonun istisna olmadığını gösteriyor. Avelino ve ekibinin GitHub'daki 133 popüler uygulamayı incelediği çalışmada projelerin %46'sının otobüs faktörü 1, %28'inin 2 çıktı. Yani dörtte üçü, bir ya da iki kişinin çekilmesiyle sahipsiz kalıyor. Üstelik bunlar herkesin okuyabildiği, katkıya açık projeler. Kapalı kurumsal kod tabanlarında durumun daha iyi olduğunu düşünmek için bir sebep yok. Stack Overflow'un 2024 geliştirici anketinde katılımcıların %61'i günde yarım saatten fazlasını cevap aramakla geçirdiğini, %30'u bilgi siloları yüzünden haftada on ya da daha fazla kez verimliliğinin düştüğünü söylüyor. Kayıp birisi ayrıldığında tek seferde yaşanmıyor. Her gün azar azar ödeniyor.

Bağımlılık kodda değil, üç yerde birikir

Kod okunabilir bir metindir ve yeterli zaman verilen bir geliştirici onu çözer. Çözemediği şeyler başka yerde duruyor.

Birincisi erişim. Alan adının kimin hesabına kayıtlı olduğu, bulut faturasının hangi karttan geçtiği, mağaza hesabının iki adımlı doğrulama kodunun hangi telefona düştüğü. Bunların hiçbiri kod deposunda yazmaz. İkincisi kararların gerekçesi: neden bu veritabanı, neden kuyruk yerine doğrudan çağrı, neden bu alan hâlâ metin tipinde tutuluyor. Kod kararın sonucunu gösterir, sebebini göstermez; sebep bilinmediğinde yeni ekip ya dokunmaya korkar ya da bir yıl önce bilinçli olarak kapatılmış bir kapıyı yeniden açar. Üçüncüsü rutin. Yayın nasıl alınır, geri alma nasıl yapılır, yedekten dönüş nasıl denenir, gece üçte alarm çaldığında ilk hangi ekrana bakılır. Bu üçüncü grup genelde hiç yazılmaz, çünkü yapan kişi için düşünmeyi gerektirmeyen bir alışkanlıktır.

Önce erişim envanteri, sonra kod

Erişim devri, bilgi devrinin en kolay ve en çok ertelenen parçası. Bir öğleden sonra sürer. Ertelendiğinde en pahalıya patlayan kısım da odur, çünkü ilişki bozulduktan sonra telafisi yoktur. Envanterde şunlar bulunmalı:

• Alan adı kaydı, DNS yönetimi ve sertifika yenileme
• Bulut hesabının kök kullanıcısı, faturalandırma ve kimlik yönetimi
• Kod deposu organizasyonunun sahipliği ve yönetici hakları
• CI/CD hattı ve hattın içinde tutulan sırlar
• Uygulama mağazası geliştirici hesapları ve imzalama anahtarları
• Ödeme sağlayıcı, e-posta ve SMS servisleri
• İzleme, alarm ve hata takip araçları
• Üçüncü taraf API anahtarları ve entegrasyon hesapları
• Veritabanı yönetici erişimi ve yedek deposu

Envanteri doldururken iki kuralı uygulayın. Her hesap kurumsal bir e-posta adresine bağlı olsun ve iki adımlı doğrulama şirketin kontrolündeki bir kanala düşsün. Kişisel Gmail hesabına kayıtlı bir alan adı ya da tek bir çalışanın telefonuna bağlı bir mağaza hesabı teknik bir eksiklik değil, ticari bir rehindir. Ayrılık gerçekleştiğinde paylaşılan tüm sırları döndürün; kişinin kullanıcı hesabını kapatmak ortak API anahtarını güvenli hale getirmez. Anahtarların koda gömülmesi ayrı bir başlık, onu sır yönetimi yazımızda ayrıntılandırmıştık.

Kararların gerekçesi: bir sayfalık karar kaydı

Michael Nygard'ın 2011'de yayımladığı "Documenting Architecture Decisions" yazısı bu soruna bugün hâlâ kullanılan en pratik cevabı verdi: mimari karar kaydı (ADR). Fikir sade. Önemli bir karar alındığında kod deposunun içine numaralandırılmış bir metin dosyası açarsınız ve beş başlık yazarsınız: başlık, durum (geçerli mi, sonradan değiştirildi mi), bağlam (o gün hangi kısıtlar vardı), karar (ne yapmaya karar verildi) ve sonuçlar (bunun bedeli ne oldu). Bir sayfayı geçmez, kodla aynı depoda yaşar, kodla birlikte gözden geçirilir.

ADR'nin kimsenin açmadığı 60 sayfalık mimari dokümandan farkı, kararla aynı anda ve kararı alan kişi tarafından yazılması. Geriye dönüp kırk kararı belgelemeye kimse oturmaz, buna gerek de yok. Mevcut sistem için pratik başlangıç şu: ekibe "yeni gelen biri neden böyle yapılmış diye sorsa şaşırırdı" dediğiniz on kararı saydırın, sadece onları yazın. İki gün sürer ve bir sonraki devir teslimde en çok işe yarayan belge o olur.

Rutin işler için işletim rehberi

İşletim rehberi (runbook), bir işi ilk kez yapacak kişinin adım adım izleyebileceği kısa bir metindir. Asgari kapsamı bellidir: yeni sürüm nasıl yayına alınır, yayın nasıl geri alınır, yedekten geri dönüş nasıl yapılır ve en son ne zaman denendi, sertifika yenilemesi otomatik mi elle mi, yeni bir ortam değişkeni nasıl eklenir, bilinen her alarm için ilk üç adım ne. Uzun olması gerekmiyor, doğru ve güncel olması gerekiyor.

Rehberin tek geçerli testi şudur: yazan kişi odada yokken bir başkası onu uygulayabiliyor mu. Bunu yılda bir kez planlı biçimde deneyin ve sonucu rehbere işleyin. Yedeği hiç geri yüklemediyseniz yedeğiniz olduğunu varsayamazsınız; bu cümle klişe ama pek çok şirket bunu ilk kez gerçek bir olay sırasında öğreniyor. Kriz anında ilk saatlerin nasıl yönetileceğini olay müdahale planı yazımızda ele almıştık.

Otobüs faktörünüzü tahmin etmeyin, ölçün

Git geçmişi cevabı zaten içeriyor. Kritik bir modül için son bir yılın yazar dağılımını görmek yeterince öğretici:

git log --since="12 months ago" --format='%an' -- src/payments/ | sort | uniq -c | sort -rn

Bunu ödeme, kimlik doğrulama, faturalama ve entegrasyon katmanları için tek tek çalıştırın. Bir modülün son on iki aydaki değişikliklerinin ezici çoğunluğu tek isimden geliyorsa o modül o kişiye bağlıdır, ekibin geri kalanının aynı dizine ara sıra dokunmuş olması bunu değiştirmez.

Ölçümden daha sert bir test de var: sessizlik tatbikatı. Belirlediğiniz kişi iki hafta boyunca hiçbir teknik soruya cevap vermez, sadece izler ve not alır. Ekibin takıldığı her nokta, kapatmanız gereken boşluğun listesine yazılır. Tatil dönemi bunun için doğal bir fırsat, tek şartla: tatildeki kişinin telefonu gerçekten kapalı olacak.

Belgelendirme masraf değil, çarpan

Belgeleme çoğu ekipte "vaktimiz olursa" işi olarak kalır, çünkü getirisi doğrudan görünmez. DORA'nın belgelendirme kalitesi araştırması bu getiriyi ölçtü ve fark beklenenden büyük çıktı: belgelendirme kalitesi ortalamanın üzerinde olan ekiplerde sürekli entegrasyonun örgütsel performansa katkısı %750 seviyesine çıkarken, ortalamanın altındaki ekiplerde aynı uygulama iki haneli yüzdelerde kalıyor. Aynı pratik, aynı araçlar, farklı sonuç. Sebep tahmin edilebilir: belgelenmemiş bir pratiği ekip kısmen uygular, tutarsız uygular ve ilk baskı anında bırakır. Bu ilişki teknik borcun neden birikip durduğunu da açıklıyor, o tarafı teknik borç yazımızda anlatmıştık.

Yapay zeka asistanları bu boşluğu kapatır mı

Kısmen. Bir dil modeline kod tabanını verip "bu servis ne yapıyor" diye sorabilirsiniz ve makul bir özet alırsınız; bu, yeni gelen geliştiricinin ilk haftasını gerçekten hızlandırıyor. Ama modelin bilemeyeceği şey tam da eksik olan şey: kararın neden alındığı. Kodda yazmayan gerekçe modelde de yok, model onu ancak tahmin eder ve tahmini kendinden emin bir dille sunar. DORA'nın 2024 raporu, yapay zeka benimsenmesindeki %25'lik bir artışın belgelendirme kalitesinde tahminen %7,5'lik bir iyileşmeye karşılık geldiğini hesaplıyor. Yani model belge yazma maliyetini düşürüyor, belgeyi ısmarlama ve doğrulama işi hâlâ insanda. Üretilen metnin ve kodun nasıl gözden geçirileceğini yapay zeka ile yazılan kodu gözden geçirme yazımızda ele aldık.

Yazılımı dışarıya yaptırdıysanız

Tek kişi bağımlılığı şirket içinde olabileceği gibi şirket dışında da olur, üstelik o hali daha tehlikelidir çünkü müzakere gücü sizde değildir. Sözleşmeye dört madde koyun. Kod deposu sizin organizasyonunuzda durur, tedarikçi oraya davetle girer. Üretim ortamı sizin bulut hesabınızda çalışır ve fatura size gelir. Teslim edilebilirler listesinde çalışan yazılımın yanında karar kayıtları ve işletim rehberi de yer alır. Fesih ya da sözleşme sonu durumunda en az otuz günlük bir devir penceresi ve canlı bir devir toplantısı tanımlıdır. Mülkiyet ve emanet düzenlemeleri için kaynak kod mülkiyeti, bakım tarafındaki maddeler için bakım ve destek sözleşmesi yazımıza bakabilirsiniz.

Bu hafta atılabilecek üç adım var ve üçü birlikte bir geliştiricinin gününü almaz. Erişim envanterini bir tabloya çıkarın ve her satırda "bu hesabın sahibi kim, kurtarma kodu nereye düşüyor" sorusunu yanıtlayın. Kritik üç modül için git geçmişinden yazar dağılımını alın. Bir sonraki mimari kararı, alındığı gün bir sayfalık bir dosyaya yazın. Wedevit olarak devraldığınız ya da devretmek üzere olduğunuz sistemlerde bağımlılık haritasını çıkarıyor, erişim ve belge devrini planlıyor, ekibinize bunu sürdürülebilir kılacak asgari düzeni kuruyoruz. Tüm çalışma uzaktan yürür.