Neden Aynı Mimari Tartışmayı Her Sprint Tekrar Yapıyorduk? (Neden Ayni Mimari Tartismayi Her Sprint Tekrar Yapiyorduk)

Neden Aynı Mimari Tartışmayı Her Sprint Tekrar Yapıyorduk?

İstanbul'da, hızla büyüyen bir teknoloji startup'ında çalışıyordum. Bir öğle arası, ekibin Kıdemli (Senior) Geliştiricisi ile parkta yürüyüşe çıkmıştık. Bana heyecanla yakında çıkacak mobil uygulamanın özelliklerinden, eklenecek yeni modüllerden ve yatırımcı sunumlarından bahsediyordu.

Dinledim ve şu basit soruyu sordum: "Peki mimari diyagram nerede? Bu kararları nerede dökümante ediyoruz?"

Bana gülümseyerek baktı. Bir plan yoktu. Sistemin bir "Software Architecture Handbook"u (Mimari El Kitabı) geçtim, basit bir karalama kağıdı bile yoktu. Yöneticinin gece kafasını yastığa koyup sabah yeni bir fikirle uyanması, bizim o günkü mimarimizi belirliyordu. Müşterinin anlık bir hatası, tüm sprinti çöpe atıyordu. Proje ilerlemiyor, sadece rüzgarda savruluyordu. (Nitekim sonradan o projeye popüler olduğu için bir gecede AI entegre ettiklerini duyduğumda hiç şaşırmadım.)

O gün parkta yürürken, yazılım projelerini batıran şeyin "kötü kod" olmadığını anladım. Projeleri batıran şey; Mimari Bilgi Buharlaşmasıydı (Architectural Knowledge Vaporization). Bir karar alıyorduk, neden aldığımızı unutuyorduk ve 3 ay sonra aynı kararı tekrar tartışıyorduk. Bu, benim teknik bir lider olarak savaş açtığım ilk cephe oldu.

Geleneksel Şirketlerin "Kabile Bilgisi" (Tribal Knowledge) İnadı

Bu kaosu gördükten sonra, girdiğim her mülakatta ilk sorum şu oldu: "Proje yönetim süreciniz nedir ve teknik kararları nasıl alıyorsunuz?"

Birkaç yıl sonra, geleneksel bir üretim firmasının Ar-Ge departmanıyla mülakata girdim. Karşımdaki yönetici, takım elbise giymediğim için benim profesyonelliğimi sorgulayarak söze başladı. (Oysa ben o firmaya dışarıdan daha önce kritik işler yapmıştım, haberi bile yoktu.)

Kendisine Jira, çevik süreçler (Agile) ve teknik dokümantasyon kullanıp kullanmadıklarını sordum. Aldığım cevap, sektörün acı gerçeğiydi: "Biz onları denedik, bize uymuyor. Biz toplantıda bir not defterine kimin ne yapacağını yazıp öyle ilerliyoruz."

İşe alım onaylansa bile o saniye o teklifi reddettim. Çünkü bir projenin mimarisi ve kaderi, birinin toplantı defterindeki silik mürekkeplere emanet edilemezdi.

Karar Tiyatrosu ve Operasyonel Kaos

Daha sonra büyük bir lojistik dönüşüm projesine dahil oldum. Sisteme girdiğimde sadece kimin ne yaptığını anlamam tam 1 ayımı aldı. Proje yönetimi sıfırdı, teknik hafıza sıfırdı.

Hemen kolları sıvadım. Çevik (Agile) iş modelini getirdim, 2 haftalık sprintler kurdum, Jira'yı entegre ettim ve günlük stand-up'ları başlattım. Her şey harika gidiyordu. Ancak özel sektörün bir gerçeği vardır: Siz sisteme şeffaflık ve kurumsal hafıza getirdiğinizde, gücünü "kabile bilgisinden" (sadece kendi bildiği sırlardan) alanlar kendini tehdit altında hisseder.

Mobbing başladı. Yönetimi elimden almaya çalıştılar. O dönem oluşturduğum ADR (Mimari Karar Kayıtları) çıktılarına bakılmıyordu bile. Bir sprint sonra yönetici gelip "Bu veritabanını neden böyle değiştirdik, benim haberim yok!" diyordu. Her şey yazılıydı ama okumuyorlardı. Dökümantasyonumuz bir "Karar Tiyatrosu"na (Decision Documentation Theater) dönüşmüştü.

İşte o zaman anladım: Sadece bir araç (Jira, ADR) kullanmak yetmez. O aracı, şirketin hedef (OKR) damarlarına enjekte etmeniz gerekir.

Proje Kaosunu Bitiren Sistem: ADR (Architecture Decision Record)

Bugün, Lead Developer olarak yönettiğim global e-ticaret platformu altyapısında (6-7 kişilik bir ekiple) bu sistemi kusursuz bir şekilde işletiyoruz. Projeye başladığımda yine bir karmaşa vardı; GitLab'da issue'lar açılıyordu ama "Bunu neden yapıyoruz?" sorusunun cevabı yoktu.

Ekibe Çevik ruhu aşıladım ve en önemlisi Michael Nygard'ın ADR (Mimari Karar Kaydı) prensiplerini doğrudan yıllık çeyrek (Q1, Q2, Q3, Q4) hedefleriyle eşleştirdim.

Peki ADR nedir ve neden her mühendisin hayatını kurtarır? ADR, bir mimari kararın sadece ne olduğunu değil, neden alındığını ve hangi bedellerin (trade-off) kabul edildiğini kodun hemen yanında saklayan değişmez (immutable) kayıtlardır.

Biz şu an bir karar aldığımızda, bunu şu basit ama ölümcül derecede etkili şablonla kaydediyoruz:

Bağlam (Context): Hangi problemle karşı karşıyayız? (Örn: Sepet sorguları veritabanını yoruyor.)

Karar (Decision): Ne yapıyoruz? (Örn: Redis Cache kullanacağız.)

Alternatifler (Neglecting): Neleri eledik? (Örn: Veritabanı scale-up yapmayı maliyetten dolayı eledik.)

Sonuçlar/Bedeller (Consequences): Neyi göze alıyoruz? (Örn: Veri gecikmesi (latency) düşecek ama cache-invalidation karmaşıklığı eklenecek.)

Sonuç: Artık "Neden?" Diye Sormuyoruz

Bugün sprint toplantılarında veya yönetim sunumlarında kimse "Bunu neden böyle yaptık?" demiyor. Çünkü her hedefin altında kapı gibi bir ADR yatıyor.

Eğer yeni bir yazılımcı ekibe katılırsa (Onboarding), ona günlerce mimariyi anlatmıyoruz. Sadece ADR Log'larını veriyoruz. "Tarihçemizi oku, hangi savaşları verdiğimizi ve neden bu silahları seçtiğimizi anla" diyoruz.

Kaosu bitirmenin sırrı; süslü kodlar yazmak değil, o kodların arkasındaki "Neden?" sorusunu kurumsal bir mirasa dönüştürmektir. Belgelenmeyen her mimari karar, gelecekte ödemek zorunda kalacağınız yüksek faizli bir teknik borçtur. Ödemeyi bugünden rasyonelinizi kaydederek yapın.

Değerli Software Architect ve Tech Lead dostlarım; sizin projelerinizde kararlar bir Wiki çölünde mi kayboluyor, yoksa kodun kalbinde mi yaşıyor?

Architecture Playbook Serisi

#1: Neden Aynı Mimari Tartışmayı Her Sprint Tekrar Yapıyorduk? (Okuduğunuz bu yazı)

#2: Bir Software Architect'in Deneyimlerden Çıkardığı Mühendislik Prensipleri (Bir Sonraki Yazı)