Doğrudan yapıp düzeltmeden yazılım tasarlanamaz

• Büyük ölçekli sistemlerde gerçek tasarım katılımı ancak ilgili kodu doğrudan ele alan mühendisler tarafından mümkündür; soyut tavsiyeler çoğunlukla anlamsızdır
• Genel tasarım tavsiyesi (generic design), çoğu zaman kod tabanı bilinmeden yalnızca alan bilgisiyle sunulur
• Gerçek işte somut kısıtlar ve tutarlılığı koruma, tasarım ilkelerinden çok daha önemlidir ve asıl kritik olan kodun mevcut durumunu anlamaktır
• Yeni bir sistem tasarlarken veya şirket genelinin teknik yönünü belirlerken genel tasarım ilkeleri belli ölçüde faydalı olabilir
• Ancak sahadan kopuk, mimar merkezli tasarım yapıları başarısız olmaya yatkındır ve tasarımı öneren kişi sonuçtan sorumlu olmalıdır

---

Genel yazılım tasarımının sınırları

• Büyük ölçekli sistem tasarımında kodun somut ayrıntılarına dair derin bir anlayış zorunludur
  • Soyut tavsiyeler gerçek sorun çözümünde neredeyse hiç yardımcı olmaz
  • Pratikte tutarlılık (consistency), “iyi tasarım”dan daha önemlidir
• Gerçek kod tabanları karmaşıktır ve öngörülemeyen sonuçlar doğurur; bu yüzden güvenli değişiklikler için seçilebilecek uygulama biçimleri sınırlıdır
• Büyük ve paylaşılan kod tabanları, her zaman birden çok tasarımın iç içe geçtiği bir ara durumda bulunur; ideal hedeften çok mevcut kodun nasıl birbirine bağlandığı önemlidir
• Çoğu sistemde tam yeniden yazım (rewrite) mümkün olmadığından, iç tutarlılık ve mühendislerin titizliğine dayanmak gerekir

Somut yazılım tasarımının özellikleri

• Etkili tasarım tartışmaları, sistemi her gün kullanan az sayıdaki mühendis arasındaki konuşmalarda gerçekleşir
  • Tartışmaların konusu genel ilkeler değil, sistemin ayrıntılı yapısı veya veri akışı gibi somut bağlamlardır
• Örneğin mesele “DRY iyi midir?” değil; “Bu özelliği A alt sistemine koyabilir miyiz, B bilgisine C bağlamında erişilebilir mi?” gibi ince teknik tartışmalardır
• Önemli katkılar, küçük yanlış anlamaları veya kod değişikliklerinin ayrıntılı etkilerini düzeltmekten gelir

Genel tasarım tavsiyesinin faydalı olduğu durumlar

• Yeni bir projeyi ilk kez tasarlarken somut kısıtlar henüz oluşmadığı için genel ilkeler faydalıdır
• Birden fazla uygulama seçeneği arasında karar vermek zor olduğunda genel ilkeler karar ölçütü (tie-breaker) işlevi görür
• Şirket genelinde tutarlılığı korumaya da yardımcı olur; bu da resmî yazılım mimarı rolünün görevlerinden biridir
• Bulut vs şirket içi, AWS vs Azure gibi geniş teknoloji seçimlerinde de genel ilkeler referans olabilir; ancak yine de somut kısıtlar göz ardı edilemez

Mimarlar ve ‘yerel minimum’ sorunu

• Birçok şirket, saha deneyimi olmayan mimarların yön verdiği soyut tasarım yapısına saplanır
  • Bu yaklaşım görünüşte verimli olsa da pratikte saha mühendislerinin hayata geçiremeyeceği tasarımlar üretir
• Mimarlar doğrudan uygulama yapmadığı için sonuca karşı sorumlulukları (skin in the game) zayıftır
  • Tasarım başarılı olursa övgüyü alabilir, başarısız olursa suçu uygulama ekibine atabilirler
• Bu yapı, gerçek değerden çok biçimsel tasarım faaliyetlerini güçlendirme eğilimindedir

Sonuç ve öneri

• Faydalı tasarım tartışmaları, kod düzeyindeki somut konuşmalarda ortaya çıkar ve tasarımcının kod tabanına mutlaka hâkim olması gerekir
• Genel mimari ilkeler, yeni sistem tasarımı, mevcut sistemlerdeki ayrıntılı kararlara destek ve şirket çapındaki teknik yönün belirlenmesiyle sınırlı kalmalıdır
• Bir projenin tasarımını öneren kişi, onun başarı ve başarısızlığından sorumlu olmalıdır; tasarımın asli öznesi de gerçekten kodla çalışan mühendisler olmalıdır
• Böylece gerçek sistemi anlayıp dağıtıma alabilen kişiler gerçek tasarımcı olarak kabul edilebilir

[khris]

> Gerçek işte, tasarım ilkelerinden çok somut kısıtlar ve tutarlılığı korumak daha önemlidir; asıl kritik olan da kodun mevcut durumunu anlamaktır.

Bu benim de her zamanki görüşüm, içimi ısıttı doğrusu.

[cshj55]

Demek ki bu yüzden bugünlerde gurular, yeni başlayanların ajanları çok daha iyi kullandığını söylüyor. İnsana uzun süre para kazandıran şeye alışınca, onu bırakıp yeniden öğrenmiyorlar.

[coremaker]

Mimariyi tamamlayan süreci iyileştirirsek, ortaya koyduğunuz sorunları yeterince çözemez miyiz?

[GN⁺]

Hacker News görüşleri

• Bir ekip toplantısında “DRY mi daha iyi, WET mi?” gibi konuşmalar değil de, “Bu özelliği alt sistem A’ya koyabilir miyiz? Hayır, orada B bilgisi yok ve onu açığa çıkarmak için D’yi yeniden yazmak gerekir...” şeklinde karmaşık bağımlılık tartışmalarının sürdüğü bir durum anlatılıyor
  Tanıdık bir manzara diye şaka yollu çeşitli hayali sistem adları sıralanmış ve en sonda bir YouTube bağlantısı eklenmiş

  • “Wingman” demesi komik. Ama hâlâ ISO8601’i desteklemeyen yazılım sayısı çok fazla. Git bile tam uyumlu değil
  • Fazlasıyla gerçekçi bir hiciv gibi. İdeal olarak bir ekibin yalnızca tek bir servisten sorumlu olması gerektiğini düşünüyorum. Ama bugünlerde geliştirici başına dört mikroservis düştüğü bir dönemdeyiz, bu da ciddi yorgunluk yaratıyor
  • Böyle durumlar, programcılar iş sistemi tasarımını da üstlendiğinde sık görülüyor. Tasarıma sistem analistleri öncülük etmeli

• 30 yıldır geliştirme yapıyorum ama gerçekten tasarım ve mimariye tutarlı çaba ayrıldığını neredeyse hiç görmedim
  ‘Mimar’ların çoğu tasarım yapmıyor; yapı genelde kıdemli geliştiricinin tasarlayıp sonrasında geri bildirim alması şeklinde işliyor
  Ortalama görev süresi 2 yıl olunca insanlar sistemi ancak kısmen anlamışken tasarım yapıyor, mimarlar da çoğu zaman sadece onay veriyor

  • John Ousterhout bu sorunu ele alıyor, Stanford’da bununla ilgili ders veriyor ve bunu 『A Philosophy of Software Design』 adlı kitapta genişletmiş. Bir de ders videosu var
  • Geçmişte ‘mimar’ı olan bir projede yer almıştım ama pratikte yaptığı şey sadece toplantılara girmekti. Gerçek tasarım tavsiyesi veren kimse yoktu
  • 2 yıl, bir alt sistemi tamamen değiştirmek ya da mahvetmek için yeterli bir süre. Günümüz yazılımı o kadar hızlı değişiyor
  • 2-3 yılda 50-100 kişilik bir ekip tarafından geliştirilen bir kod tabanını oldukça derinlemesine anlayabilirsiniz. Sonrasında insanlara mimari iyileştirmelere öncülük etme fırsatı verilirse şirket teknik olarak büyüyebilir. Mimarların görevi bu fikirleri koordine etmek ve tutarlılığı korumayı sağlamak olmalı

• ‘Generic Software Design’, uygulama yönünü belirlemede yararlı. Sorun çözmeyi kolaylaştıran ortak bir dil ve çerçeve sunuyor
  Ancak gerçek uygulama plandan farklı gelişebilir. Naur’un programlama kuramında olduğu gibi, sistem hakkındaki gerçek bilgi geliştiricilerin zihninde bulunur

• “Büyük kod tabanlarında tutarlılık, iyi tasarımdan daha önemlidir” sözü, tam da o genelleştirilmiş tavsiyenin tuzağı
  Yalnızca tutarlılığı vurgularsanız kötü alışkanlıklar aynen korunur

  • Bizim şirketteyse tam tersi, aşırı özgürlük sorun yaratıyor. Herkes kendi yöntemine göre yapıyor; bir köşede Redux, başka bir köşede farklı bir sorgu kütüphanesi var. Sonuçta bakım daha da zorlaşıyor
  • Bu sadece kod kalitesi değil, organizasyonun genel verimliliği meselesi. Tutarlılık olduğunda geliştirme hızı artıyor, inceleme ve onboarding kolaylaşıyor. Hatalar da tek seferde düzeltilebiliyor
  • O cümleyi görünce irkildim. Ama yazıyı sonuna kadar okuyunca tutarlılığın özünün birlik ve doğruluk olduğunu görüyorsunuz
  • Tutarlılığı korurken kademeli iyileştirme önemli. Koda her dokunduğunuzda küçük iyileştirmeler yaparak ‘kolay kazanımlar’ biriktirmek iyi olur
  • “İyi tasarımdan çok tutarlılık önemlidir” sözü Boy Scout Rule ile çelişiyor. Sadece tutarlılığı dert ederseniz iş kolayca riskli bir topyekûn refaktöringe dönebilir

• Bir tarafta gerçeklerden kopuk ‘mimar’lar, diğer tarafta sadece ayrıntı optimizasyonuna saplanmış Real Programmer’lar var
  Her iki uç da sorunlu; karar vericilerin hem ayrıntıları hem bağlamı anlaması gerekir
  Bununla bağlantılı olarak The Story of Mel anılıyor

• “Tasarımı yapan kişi projenin başarısı ve başarısızlığından sorumlu olmalı” sözüne katılıyorum
  Bu, geliştirme metodolojisini seçen kişi için de geçerli olmalı. Scrum master, lead engineer kadar sorumluluk hissetmiyor

• İçinde bulunduğum en iyi uygulamaların üç ortak özelliği vardı

  1. Basit ve etkili sistemlere önem veriliyordu
  2. Geliştiriciler gerçek kullanıcı olarak tüm kullanım senaryolarını anlıyordu
  3. Buldukları sorunları hemen düzeltebilecek özerkliğe sahiplerdi
     Bu özgürlük hem geliştirici memnuniyetini hem de ürün kalitesini artırdı

• Benim deneyimime göre, büyük kod tabanlarında tutarlılık takıntısı aslında bir hata
  Her modülün gereksinimleri farklı olduğundan, test stratejileri ve adlandırma da farklı olmalı

• İdeal durumda geliştirici, yaptığı yazılımın gerçek kullanıcısı da olmalı
  Böylece hataları ve kullanım zorluklarını doğrudan hisseder, iyileştirme motivasyonu kazanır

  • Geliştiricilerin müşteri destek aşamasından geçmeden kullanıcı sorunlarını doğrudan görebileceği bir kanal olmalı. Biletler, forumlar, sosyal medya vb. yerlerden gelen içgörüler çok değerli
  • XP’de müşteriyi ekibin içine dahil etmek harika bir fikirdi. Bunun bir iş temsilcisiyle değiştirilmesi, Scrum’un asli günahlarından biri oldu

• Bakım sürecine katılmayan ayrı bir yazılım mimarı fikri gerçekçi değil
  Projeler sürekli değiştiği için uzaktan sadece talimat veren bir rol yardımcı olmuyor

  • Böyle bir rolün olduğu bir şirkette hiç çalışmadım. Karmaşık yazılım, devam eden bir satranç oyunu gibidir. Stratejik ilkeler gerekir ama tahtadaki gerçek durumu bilmeyen tavsiyenin anlamı yoktur