Kısıtların Arasındaki Boşluğu Görmek: “Degrees of Freedom”
Antoine Grondin’in
Kavram fizikten ödünç alınma. Bir sistemin birbirinden bağımsız hareket edebildiği eksen sayısına serbestlik derecesi (degrees of freedom) diyoruz. Bir kapı kolunu duvardan çekip çıkaramazsınız veya sağa sola kaydıramazsınız; bu eksenler kısıtlanmıştır. Ama kolun tek bir serbestlik derecesi vardır: Belirli bir eksende dönebilir. İşi çözmek için o tek serbestlik yeterlidir.
Grondin’in vurguladığı asıl mesele ise bunun bir problem çözme felsefesine dönüşmesi: Bir kısıtla karşılaştığında “bunu yapamam” duvarına çarpmak yerine, kuralın etrafında hâlâ hareket edebileceğin ne kadar alan kaldığını görmek.
Kuralı Çözüm Alanıyla Karıştırmak
Zihnimiz kısıtları olduğundan daha geniş algılamaya meyilli. Basit bir örnek:
“Bu odaya mobilya koyamazsın, çünkü kapının önünü kapatamazsın.”
İlk refleks genellikle "Tamam, bu odaya mobilya koyamıyoruz" olur. Oysa kural kapının önünü kapatmamayı söyler; odanın geri kalanını yasaklamaz.
Kısıt: Kapının önünü boş bırakmak.
Serbestlik: Odanın kalan alanında eşyaları dilediğin gibi konumlandırmak.
Kısıtı mutlak bir yasak gibi okursanız çözümü baştan ıskalarsınız. Doğru model: "İstediğim her yere koyamam ama bazı yerlere koyabilirim."
Yazılımda Kısıtlar ve Çözüm Uzayı
Bir sistem tasarlarken önümüze gelen gereksinimleri düşünün:
Veritabanı kesinlikle X olacak.
Sistem güvenli ve regülasyona uygun kalacak.
Yanıt süreleri düşük olacak.
Mühendis olarak ilk soru genellikle "Ne yapmam gerekiyor?" olur. Grondin’in önerdiği daha kritik soru ise şu:
“Neleri yapmak zorunda değilim?”
Gereksinimler sınırları çizer ama içerideki hacmi doldurmaz. “Veritabanı X olacak” kuralı, mimarinin tamamını X’in varsayılan davranışına teslim etmek demek değildir. Hâlâ onlarca serbestlik dereceniz var:
Araya bir cache katmanı koyabilirsiniz.
Okuma ve yazma modellerini (CQRS) ayırabilirsiniz.
Veriyi bellekte tutup diske asenkron yazabilirsiniz.
Arka plan işlerini kuyruğa (queue) devredip API’yi rahatlatabilirsiniz.
Kısıt, sadece bir ekseni kilitler. Kalan eksenler sizin tasarım kararlarınıza aittir.
“Constraint Relaxation” — Kısıtı Gevşetmek
Bir kısıtla karşılaştığınızda ikili mantıktan (0 veya 1 / yapılabilir veya yapılamaz) çıkıp parametreleri esnetmeyi denemek gerekir.
“İşlem gerçek zamanlı (real-time) olmalı.”
Gerçekten milisaniye seviyesinde mi, yoksa 3-5 saniyelik bir gecikme işi kurtarıyor mu? Kısıtı "anlık"tan "5 saniye içinde"ye gevşettiğiniz an mimari karmaşıklık ve maliyet katbekat düşer.
“Bunu kullanıcı manuel yapmalı.”
Neden? Kullanıcının baştan sona veri girmesi mi gerekiyor, yoksa sadece sistemin hazırladığı taslağa son onayı vermesi mi? İkincisinde işin %95’ini otomatize edebilirsiniz.
Kuralı tamamen kırmak gerekmez; biraz gevşetmek bile devasa bir hareket alanı açar.
Gizli Kapasiteler: Rol ile İmkan Aynı Şey Değil
Yazıda geçen iki örnek durumu çok iyi özetliyor:
Pizza Kuryesi: Kuryeye yalnızca “pizza getiren kişi” derseniz beklentiniz sınırlı kalır. Ancak onun gerçek kapasitesine bakarsanız: Altında aracı olan ve A noktasından B noktasına giden biri. Rol tanımı ile gerçek kapasite aynı şey değildir.
Excel ve VBA: Askeri lojistik tablosu dolduran biri geleneksel bakışta sadece veri giriyordur. Ancak elinde VBA destekli Excel varsa, aslında önünde programlanabilir bir bilgisayar vardır. Sistemin alışıldık amacının dışına çıkarak gizli bir serbestlik derecesi keşfetmiştir.
Sistemlerimizde de böyledir. Kullandığınız bir kuyruk altyapısı, bir CLI aracı veya bir API, resmi dokümantasyonundaki kullanım senaryosundan çok daha geniş bir hareket alanı barındırıyor olabilir.
Zihin Açıcı Birkaç Düşünce Deneyi
Kilitlendiğiniz bir problemde şu soruları sormak serbestlik alanlarını görünür kılar:
“Sistem geleceği bilseydi ne yapardım?”
Cache, tahminleme veya kuyruk tasarımlarındaki gereksiz karmaşıklığı ayıklamak için iyi bir testtir.
“Bunu X olarak yapamıyoruz; peki X' (gevşetilmiş hali) olarak yapabilir miyiz?”
Tamamen otomatik değil de yarı otomatik? Herkes için değil de belirli bir kullanıcı grubu için?
“Hiçbir kural olmasaydı bunu nasıl çözerdim?”
Önce ideal çözümü tasarlayıp, ardından kısıtlı dünyaya dönerek o çözümün %30'unu içeri taşımaya çalışmak.
“Bu kural gerçekten teknik bir zorunluluk mu, yoksa alışkanlık mı?”
Çoğu kurumsal kısıt, geçmişte bir problem için konulmuş ve nedeni unutulmuş reflekslerden ibarettir.
Bir problemi çözerken sadece önünüze örülen duvarlara bakarsanız hareket edemezsiniz. Mühendislik refleksi, o duvarların arasında kalan boşlukları ve kullanılabilir eksenleri aramaktan geçiyor.
Yazının tamamına göz atmak isterseniz:
Yorumlar
Yorum Gönder
Evet şimdi yorumlar ;