Devraldığın Sistem: İlk 90 Gün

Sahadan: dört satırlık README, üç haftalık pencere

İlk refleksim kodu okumaktı. İki gün boyunca servisleri dolaştım, sınıf isimlerini not aldım, veri modelini çıkarmaya çalıştım. Üçüncü günün sonunda elimde epeyce not vardı ve hâlâ tek bir satır değişikliği canlıya çıkaramıyordum.

Asıl hatayı üçüncü gün fark ettim: yanlış şeyi öğreniyordum. Kod zaten duruyor, istediğim zaman okurum. Kaybolmak üzere olan şey koddaki bilgi değildi, kişideki bilgiydi ve üç haftalık bir penceresi vardı.

O günden sonra sıralamayı tersine çevirdim: önce sistemin nasıl işlediğini, sonra ne yaptığını öğrendim. Kalan üç haftayı da kod okuyarak değil, o kişinin yanında oturup soru sorarak geçirdim.

Birinci hafta: tek hedef

İlk haftanın tek bir hedefi var ve kod anlamak değil: zararsız bir değişikliği baştan sona kendi başına yapabilmek. Bir log satırı ekle, PR’ını aç, incelemeden geçir, canlıya çıkar, sonra geri al.

Kulağa önemsiz geliyor ama bu tek alıştırma şunların hepsini aynı anda öğretiyor:

kodu degistir   -> repo yapisi, hangi servis nerede, derleme nasil
PR ac           -> kim inceliyor, sahiplik tanimli mi, CI'da ne kosuyor
canliya cikar   -> pipeline adimlari, onay var mi, ne kadar suruyor
canlida dogrula -> log nereye gidiyor, dashboard nerede
geri al         -> geri alma yolu var mi, kac saniye suruyor
                   (yoksa ilk bulgun bu: geri alinamayan bir sistem)

Bunların hiçbiri koda bakarak öğrenilmiyor. Ve hepsi, ilk gerçek sorun çıktığında ihtiyacın olacak şeyler. Geri alma yolunun kaç saniye sürdüğü sorusu, aslında sürüm yönetimi yazısında anlattığım ölçünün ta kendisi — devraldığın sistemde ilk hafta öğrendiğin şey oluyor.

Yazacağın tek doküman

Hafta sonunda tek bir şey yaz: “Buradan canlıya nasıl çıkılır?” Adım adım, hiçbir şey bilmeyen birine anlatır gibi.

Bunu yeni gelenin yazması şart, çünkü ekipteki herkes o yolu biliyor ve bildiği için yazamıyor; hangi adımın açıklanması gerektiğini göremiyorlar. Sen göremediğin tek kişisin — bu yüzden en iyi yazar sensin, ve bu avantaj üç hafta sonra kayboluyor.

Aynı mantık runbook’larda da işliyor: nöbet yazısında anlattığım gölge hafta kuralının sebebi bu. Bir dokümanı en iyi güncelleyen kişi, onu ilk kez okuyandır.

2–4. hafta: haritayı çıkar

Mimari şema istersen sana verirler ve o şema büyük ihtimalle iki yıl öncesini anlatır. Gerçek haritayı üç kaynaktan çıkarıyorum:

# 1) En cok degisen dosyalar = sistemin sicak noktalari
git log --since="1 year ago" --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -30

# 2) En cok alarm ureten servisler = kirilgan noktalar
#    (son 3 ayin alarm kayitlari, servise gore grupla)

# 3) En cok destek talebi gelen ekranlar = kullanicinin acisi

Üçünün kesiştiği yer, sistemin gerçek merkezidir — ve çoğu zaman mimari şemada kenarda duran bir kutudur. Bir de dördüncü bir kaynak var: en az değişen ama her şeyin bağlı olduğu dosya. Kimse dokunmuyor çünkü herkes korkuyor; o dosya, ileride en pahalı işin çıkacağı yer.

Bu haftalarda cevaplamaya çalıştığım sorular şunlar: Veriyi kim sahipleniyor? Hangi dış servise bağlıyız ve o düşerse ne oluyor? Hangi iş gece çalışıyor? Kimse bakmıyor ama sessizce çalışan ne var?

90 gün dokunmama kuralı

Yeni gelen birinin en büyük cazibesi temizlik yapmak. Kod çirkin, isimler tutarsız, üç farklı yerde aynı iş yapılıyor. Elin gidiyor.

Kural şu: bir çitin neden orada olduğunu bilmeden çiti sökme. Garip görünen kodun büyük kısmı, birinin bir gece yaşadığı olayın izi. O if bloğu, tek bir müşterinin bozuk verisi yüzünden eklenmiş olabilir; o gereksiz görünen sleep, bir yarış durumunu örtüyor olabilir.

Test ekleme maddesi özellikle değerli. Anlamadığın bir modülün davranışını teste dökmek, hem öğrenmenin en hızlı yolu hem de ileride değiştirmek istediğinde elindeki tek güvence.

Devreden kişiye beş soru

Bilgi transferi toplantıları genelde ekran paylaşımıyla kod gezmekle geçiyor ve en değerli şeyi kaçırıyor: o kişinin sezgisi. Beş soru yetiyor:

1. Gece seni en çok ne uyandırdı? Sistemin gerçek kırılgan noktası burada.
2. Hangi kısma dokunmaktan çekinirsin, neden? Korkunun nedeni genelde yazılı hiçbir yerde yok.
3. Yazmadığın ama bilmem gereken ne var? Açık uçlu, ve en çok cevap veren soru bu.
4. Bir sonraki büyük sorun sence nereden çıkar? Çoğu kişi bunu şaşırtıcı bir isabetle biliyor.
5. Yerimde olsan ilk neyi düzeltirdin? Ve genelde hiç düzeltilmemiş olmasının bir sebebi vardır; onu da sor.

Cevapları kaydet ve karar kayıtlarına bağla. “Şu kısma dokunmayız çünkü...” cümlesi, yazıya dökülmediği sürece bir sonraki devirde yeniden kaybolur.

Ne izlemeli?

Bende işe yaramayanlar

• Baştan sona kod okumak. İlk iki günümü buna harcadım. Bağlamı olmayan kod okuması hiçbir şey öğretmiyor; aynı kodu bir sorunu kovalarken okuduğumda yarım saatte anladım.
• Büyük bir “mevcut durum analizi” raporu yazmak. Otuz sayfa yazdım, üç kişi okudu, hiçbir aksiyon çıkmadı. İşe yarayan şey, bulguları tek tek küçük iş maddelerine çevirmek oldu — ayrı bir rapor listesi yaparsan o liste ölüyor; aynı dersi postmortem yazısında da ödemiştim.
• İlk ayda büyük bir iyileştirme sözü vermek. “Üç ayda şu modülü yeniden yazacağız” dedim. Üçüncü ayda o modülün neden öyle olduğunu yeni anlamıştım ve plan tamamen değişti. Söz vermeden önce haritayı bitir.

Kontrol listesi

Sonuç

O üç haftayı kod okuyarak geçirseydim, bugün hâlâ bilmediğim şeyler olurdu — çünkü o bilgi hiçbir zaman koda yazılmamıştı. Bunun yerine soru sordum, yanına oturdum, o konuştukça yazdım. Ayrıldığı gün elimde dört sayfalık bir not vardı ve sonraki altı ayda o notlara en az on kez döndüm.

Bir sistemi devralmak, onu anlamak değil; onu güvenle değiştirebilir hâle gelmek. İkisi farklı şeyler ve ikincisi çok daha hızlı öğreniliyor.

Doksanıncı günün testi şu: bu sistemde bugün acil bir sorun çıksa, kimseyi aramadan ne kadar ilerleyebilirdin? Cevabın “çoğunu hallederim” ise devir tamamlanmış demektir. “Birini aramam lazım” ise, aranacak o kişi hâlâ oradayken sormaya devam et.