Projeyi Ayakta Tutan Kod Değil: Bilginin Nerede Yaşadığıdır.

Sistem loglarına bakarken ilk fark edilen şey genelde kod değil, insanların bıraktığı iz oluyor. Bir servis çöküyor, dashboard kırmızıya dönüyor ve kimse tam olarak nedenini net hatırlamıyor. En sonunda Slack’te biri “bunu Ahmet biliyordu ama geçen hafta izinliydi” diye yazıyor. O an, sistemin gerçekten ne kadar “sistem” olduğu sorgulanmaya başlıyor.

Bu tür anlar genelde teknik bir problem gibi görünür ama aslında çok daha derin bir şey anlatır: bilgi nerede yaşıyor? Kod tabanında mı, dokümanlarda mı, yoksa birkaç kişinin zihninde mi?

Context ve neden bu konu sürekli geri geliyor

Orta ve büyük ölçekli sistemlerde en büyük kırılma noktası genelde teknoloji değil, bilgi dağılımıdır. Mikroservis mimarisi, event-driven yapı, cloud-native yaklaşımlar… Hepsi teknik olarak çözülmüş problemler gibi görünür ama işin üretim tarafında bambaşka bir gerçek vardır: sistemin nasıl çalıştığını bilen kişi sayısı azaldıkça risk artar.

Dokümantasyon genelde bu boşluğu doldurmak için sahneye çıkar. Ama çoğu ekipte doküman, yaşayan bir şey olmaktan çok “bir kere yazılıp unutulan” bir artefakt haline gelir. Bir API’nin davranışı değişir ama README güncellenmez. Bir edge-case keşfedilir ama sadece bir kişinin notebook’unda kalır. Diğer tarafta analiz var. Yani kararların neden alındığını, hangi trade-off’ların yapıldığını anlatan katman. Bu kısım genelde daha az görünür ama uzun vadede sistemin zihinsel modelini ayakta tutan asıl şey burasıdır. Ve üçüncü değişken: insanlar. En güncel, en doğru, en kritik bilgi çoğu zaman hâlâ birinin kafasında yaşar. Bu da sistemin en kırılgan bağıdır.

Gerçek dünyada bu üçlü nasıl davranıyor

Teoride iyi bir organizasyon şunu hedefler: dokümanlar güncel, analizler erişilebilir, bilgi paylaşımı güçlü. Pratikte ise sistem genelde şöyle çalışır: kritik bilgiler kişilerde başlar, analizlerde şekillenir, dokümanlarda ise yavaş yavaş eskir. Buradaki asıl sorun dokümanın varlığı değil, evrimleşmemesi. Bir sistem tasarımını düşünelim. İlk başta doğru bir analizle karar veriliyor: cache katmanı ekleniyor, event ordering önemli hale geliyor, retry stratejisi belirleniyor. Bu kararların arkasındaki düşünce analiz dokümanında duruyor. Ama zamanla sistem değişiyor. Trafik artıyor, edge-case’ler çoğalıyor, business kuralları evriliyor. Kod güncelleniyor ama analiz çoğu zaman güncellenmiyor. Bir noktadan sonra yeni gelen mühendisler sadece “ne yapıldığını” görüyor, “neden yapıldığını” değil. İşte kırılma burada başlıyor. Çünkü neden kısmı kaybolduğunda, yapılan her değişiklik biraz daha riskli hale geliyor.

Dokümantasyonun sınırı

Dokümantasyon genelde yanlış anlaşılıyor. Birçok ekipte “bilgiyi yazıya dökmek” gibi görülüyor. Oysa iyi doküman aslında bir snapshot değil, bir akışın parçası olmalı. Ama gerçek hayatta şu problem var: doküman yazmak üretim hızına ters bir iş gibi algılanıyor. Sprint baskısı altında “önce çalışsın, sonra yazarız” refleksi devreye giriyor. Sonra o “sonra” hiç gelmiyor. Daha kritik olanı şu: dokümanlar genelde “ideal durum”u anlatıyor, gerçek davranışı değil. Sistem production’da farklı çalışıyor ama doküman staging senaryosuna göre yazılmış oluyor. Bu da zamanla güven kaybı yaratıyor. Bir noktadan sonra kimse dokümana bakmıyor çünkü “zaten doğru değil” varsayımı oluşuyor.

Analizin gerçek rolü

Analiz kısmı genelde göz ardı edilir ama aslında en kritik katman burasıdır. Çünkü analiz sadece “ne yapılacak” değil, “neden bu şekilde yapılmalı” sorusuna cevap verir. İyi bir analiz, sistemin gelecekte nasıl evrilebileceğini de içinde taşır. Örneğin bir caching stratejisi seçerken sadece latency değil, invalidation karmaşıklığı da düşünülür. Bu kararın arkasındaki reasoning kaybolduğunda, ileride aynı hatalar tekrar tekrar yapılır. Burada ilginç bir gerçek var: analiz çoğu zaman koddan daha değerlidir ama en hızlı kaybolan şey de odur. Çünkü kod repo’da yaşar, analiz ise genelde bir PR comment’inde, bir ticket içinde veya bir kişinin notlarında sıkışır.

Peki asıl cevap ne?

Projeyi ayakta tutan şey tek başına dokümantasyon değil. Tek başına analiz de değil. İnsan da değil. Asıl mesele bu üçünün nasıl bir ekosistem oluşturduğu. Eğer analiz güçlü ama dokümantasyon zayıfsa, bilgi bireylerde birikir ve sistem kırılgan hale gelir. Eğer dokümantasyon var ama analiz yoksa, sistem görünürde düzenlidir ama kararların arkasında düşünce eksiktir. Eğer her şey kişilerdeyse, sistem aslında ölçeklenebilir değildir; sadece çalışan bir hafıza koleksiyonudur. Gerçek dayanıklılık, bilginin kişiden bağımsız hale gelmesiyle başlar ama bunun tek başına dokümana yazmakla olmadığını sahada defalarca görürsün. Kod, doküman ve analiz birbirini sürekli besleyen bir döngü haline gelmediği sürece sistemin “bilgisi” aslında sürekli erir.

Son düşünce

Uzun yıllar sonra geriye dönüp bakınca şunu daha net görüyorsun: sistemler genelde teknolojik olarak değil, bilişsel olarak ölür. Yani insanlar ne yaptığını bilmeyi bıraktığında. Ve bu boşluğu doldurmak için yazılan dokümanlar ya da yapılan analizler, eğer yaşayan bir süreç haline gelmemişse sadece geçmişin fotoğrafı oluyor. Belki de soruyu şöyle sormak daha doğru: “Projeyi ayakta tutan şey bilgi değil, bilginin nasıl yaşadığı mı?”