Artırımlı Modüler Tasarım: Asıl Mesele Modül Sınırıdır
Büyük bir projeyi küçük parçalara bölmek kimseye zor gelmiyor. Zor olan, parçaların sınırını doğru yerden geçirmek. Yanlış çizilmiş bir sınır, en küçük değişiklikte üç modülü birden açmanıza yol açar ve modülerlikten beklenen bütün kazancı yer. Artırımlı modüler tasarım bir parça sayısı meselesi değil, bir sınır meselesidir.
Yöntemin söylediği şey
Artırımlı modüler tasarım, büyük bir işi bağımsız modüllere bölüp her modülü kendi başına teslim edilebilir bir adım olarak geliştirmektir. Kökeni yazılımdaki artırımlı geliştirme pratiğidir, ama kentsel projelerden sağlık programlarına kadar taşınmış durumda. Üç şart üzerine kurulur: paydaşların ortak bir hedef listesi üzerinde anlaşması, her modülün girdi ve çıktısının açıkça tanımlanması, her teslimden sonra sonucun ölçülüp bir sonraki adımın ona göre şekillenmesi.
Bu şartlardan ikincisi diğer ikisini taşır. Girdi ve çıktı belli değilse modül bağımsız değildir, sadece ayrı bir klasördedir.
Sınırı nereden geçirmeli
Modül sınırını genelde veri sahipliğine göre çizerim: bir veriyi kim yazıyorsa o veri onun modülünde durur, geri kalan herkes okumak için kapıyı çalar. Ekran, ekip ya da takvim üzerinden bölmek kolay görünür ve hepsi aynı sonuca çıkar, iki modülün aynı tabloya yazması. O noktadan sonra bağımsızlık iddiası biter.
İkinci ölçüt değişim hızıdır. Ayda bir değişen bir bileşenle yılda bir değişen bir bileşeni aynı modülde tutarsanız, yavaş olanı hızlının temposuna mecbur edersiniz. Farklı hızlar farklı modüllere gider.
Artırımlılık ile bağımsızlık arasındaki gerilim
Bu iki ilke aynı anda savunuluyor ama birbirini çekiştirirler. Bağımsız modül için arayüzü erken sabitlemeniz gerekir; artırımlı ilerlemenin bütün amacı ise erken aşamada henüz bilmediğiniz şeyi öğrenmek. İlk teslimden sonra öğrendiğiniz şey çoğu zaman arayüzün yanlış yerde olduğudur ve tam da sabitlediğiniz için değiştirmek pahalıdır.
Buna bir de sayı problemi ekleniyor. Modülleri çoğaltmak karmaşıklığı azaltmaz, sadece yer değiştirir: on modülün birbirine bakabileceği ikili ilişki sayısı en kötü halde 45'tir, yirmi modülde 190. Yani n(n-1)/2 hızıyla büyür. "Karmaşıksa daha küçük parçalara böl" tavsiyesi bu yüzden bir yerden sonra ters çalışır. Parça sayısını artırmadan önce arayüz sayısını sınırlayan bir kural koymak gerekir; her modülün yalnız komşularıyla konuştuğu bir katman düzeni bunu yapar.
Pratik çözüm arayüzü sabitlemek değil, sürümlemek. Eski sözleşme bir süre daha yaşar, yeni modüller yenisini kullanır, geçiş bittiğinde eskisi kaldırılır. Bu, yazılımda uzun süredir bilinen bir alışkanlık ve yazılım dışı projelerde de aynı işi görür.
Küresel ölçekli işlerde neden tercih ediliyor
İklim, kentsel dönüşüm ya da sağlık gibi alanlarda tek seferde teslim edilen bir çözüm yok, çünkü koşullar bölgeden bölgeye değişiyor. Modüler kurgu burada iki somut şey sağlıyor: aynı iskeleti koruyup yerel gereksinime göre yalnız ilgili modülü uyarlayabiliyorsunuz, ve fon sağlayıcıya soyut bir vaat yerine ölçülmüş bir ara sonuç gösterebiliyorsunuz.
İkincisi göründüğünden ağır basıyor. Bütçe kararları çoğu zaman tamamlanmış küçük işlerin görünürlüğüne bakılarak veriliyor, projenin bütününe olan inanca değil.
Ne zaman işe yaramaz
Problem gerçekten ayrışmıyorsa modüler tasarım fayda getirmez. Bileşenlerin sürekli aynı veriyi aynı anda güncellemesi gereken işlerde modül sınırı yapay kalır ve her adımda senkronizasyon maliyeti olarak geri döner. Kapsamı baştan belli, değişme ihtimali düşük işlerde de artırımlı ilerlemek gereksiz yüktür; orada tek parça tasarlayıp bir kere teslim etmek daha ucuzdur.
Yöntemin karşılığını verdiği yer belli: gereksinimlerin öğrenilerek netleştiği, birden fazla ekibin paralel çalıştığı ve teslimatın uzun sürdüğü projeler. Bunların dışında modülerlik çoğunlukla bir mimari tercih değil, bir organizasyon şeması taklidi oluyor.