2010'da yayımlanan "Just Enough Software Architecture"
(georgefairbanks.com)- George Fairbanks’in Just Enough Software Architecture kitabı, yalnızca dil sözdizimi ya da UML bilgisiyle iyi nesne yönelimli sistemler ve mimariler tasarlamanın zor olduğu probleminden yola çıkar
- Temel fikir risk odaklı mimari tasarımdır: risk küçükken aşırı tasarımdan kaçınır, başarıyı tehdit eden risklerde ise daha titiz teknikler uygular
- Mimariyi yalnızca bazı uzmanların alanı olarak değil, tüm geliştiricilerin anlaması gereken bir yetkinlik olarak ele alır; kısıtların ve küçük değişikliklerin sistem özellikleri üzerindeki etkisini açıklar
- Geliştirme süreci veya organizasyon yönetiminden çok mühendislik tekniklerine odaklanarak, modelleme ve mimari analiziyle orta ve büyük ölçekli problemlerdeki tasarım ödünleşimlerini ele almayı sağlar
- Yapısı, risk odaklı yazılım mimarisi ve mimari modelleme olmak üzere iki bölümden oluşur; domain modeli, tasarım modeli, kod modeli, kapsülleme, bileşenler ve connector’lar gibi soyutlamaları ele alır
Dil ve UML bilgisi tek başına yeterli tasarım yetkinliği sağlamaz
- Yazar, yazılım geliştirmeye başladığında kendisinin ihtiyaç duyduğu kitabı yazma fikrinden yola çıkar
- O dönemde programlama dili veya nesne yönelimli programlama kitapları vardı, ancak tasarımı ele alan kitaplar azdı
- C++ dil özelliklerini bilmek tek başına iyi nesne yönelimli sistemler tasarlamayı sağlamaz; UML bilmek de tek başına iyi sistem mimarileri tasarlamayı sağlamaz
Riske göre ayarlanan mimari tasarım
- Kitabın özü risk-driven architecting yaklaşımıdır
- Risk küçükken ayrıntılı tasarıma gerek yoktur; başarıyı tehdit eden bir risk varken de gevşek bir tasarım yeterli değildir
- Birçok Agile savunucusu, bir miktar ön tasarımın faydalı olabileceğini düşünür; bu kitap “yeteri kadar mimari” yapmanın yollarını ele alır
- “one size fits all” türü süreçlerden kaçınır ve karşılaşılan risklere göre mimari ile tasarım çabasını ayarlamaya yönlendirir
- Çoğu tekniğin yoğunluğu quick-and-dirty seviyesinden son derece titiz seviyeye kadar ayarlanabilir
Mimariyi tüm geliştiricilerin dili hâline getirmek
- Kitap, mimariyi demokratikleştirme hedefi taşır
- Bir organizasyonda yazılım mimarı bulunabilir; okurun kendisi de mimar olabilir
- Birçok mimar, tüm geliştiricilerin mimariyi anlamasını ister
- Geliştiriciler kısıtların nedenini ve küçük değişikliklerin sistem özelliklerine etkisini anlamazsa tasarım kararları zayıflayabilir
- Mimari yalnızca mimarların konusu değil, tüm yazılım geliştiricileri ilgilendiren bir konudur
Prosedürel bilgi ve deklaratif bilgi
- Kitap deklaratif bilgiyi geliştirmeye odaklanır
- Tenis topuna vurabilmek ile neden vurabildiğini bilmek farklıdır; bu, prosedürel bilgi ile deklaratif bilgi arasındaki farka karşılık gelir
- Zaten sistem tasarlayıp inşa eden bir uzmansanız, kitaptaki tekniklerin birçoğunu kullanmış olabilirsiniz
- Kitap, şimdiye kadar yaptığınız işleri daha iyi fark etmenizi sağlar ve kavramlara isim verir
- Bu tür deklaratif bilgi, acemi geliştiricilere mentorluk yapma becerisini artırmaya yardımcı olur
Süreçten çok mühendisliğe odaklanma
- Yazılım sistemleri tasarlayan ve inşa eden kişiler; takvim, kaynak taahhütleri, paydaş ihtiyaçları gibi birçok konuyu birlikte ele almak zorundadır
- Birçok yazılım mimarisi kitabı zaten geliştirme süreçlerini ve organizasyon yapılarını ele alır
- Bu kitap ise onlardan farklı olarak yazılım geliştirmenin teknik kısmına ve sistemin çalışmasını sağlayan mühendisliğe odaklanır
- Modeller oluşturup mimariyi analiz ederek ilkelere dayalı tasarım ödünleşimleri yapmayı mümkün kılar
- Orta ve büyük ölçekli problemler üzerinde akıl yürütmek için kullanılan teknikleri açıklar ve uzman tekniklerin daha ayrıntılı öğrenilebileceği yerleri de gösterir
Birden çok soyutlama seviyesi arasında gidip gelen pratik tasarım
- Kitap, mimariyi pratik bir tasarım faaliyeti olarak ele alır
- Yazılım mimarisi, yazılım tasarımının bir türüdür; tasarım kararları mimariyi etkiler, mimari de tasarımı etkiler
- İyi geliştiriciler, engelleri ayrıntılı biçimde inceleyip anladıktan sonra bu engellerin niteliğini genel mimariyle ilişkilendirir
- Bu drill-down/pop-up davranışını yansıtmak için mimariden veri yapısı tasarımına kadar çeşitli soyutlama seviyelerindeki modelleri ele alır
Yapı ve sunulan formatlar
- Kitap iki bölümden oluşur
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Bazı örnek bölümler tek bir PDF olarak indirilebilir
- E-kitap Google Play üzerinde satılır; DRM’siz ePub, Mobi ve PDF olmak üzere üç format içerir ve fiyatı $9.99’dır
- Ciltli kitap Amazon üzerinde sunulur
- Google Books ve Amazon Search Inside, tam metin araması yapılabilen sürümler sunar
Kapsam ve kapsam dışı konular
- Kitap, yazılım inşasıyla ilgili yazılım mimarisine odaklanır
- Yazılımın mühendislik gereksinimlerini karşılamasını sağlayan teknikleri açıklar
- Mühendislik tekniklerinin kendisi genellikle süreçten bağımsız olduğu için kitap da çoğunlukla süreçten bağımsızdır
- Aşağıdaki gibi yönetim faaliyetlerine yönelik tavsiyeleri ele almaz
- Mimarın politik sorumlulukları
- Belirli türde toplantıların ne zaman yapılması gerektiği
- Paydaşlardan gereksinimlerin nasıl toplanacağı
Part I: Risk Odaklı Yazılım Mimarisi
- Yazılım mimarisini kesin biçimde tanımlamak zor olsa da bazı özellikleri açıktır
- Yazılım geliştiriciler, diğer mühendislik alanlarındaki mühendisler gibi soyutlamalar ve modeller kullanarak büyük ve karmaşık problemleri çözer
- Yazılım mimarisi, sistemin iskeleti gibi çalışır ve kalite özelliklerini etkiler; işlevlerle ortogonaldir ve kısıtlar yoluyla sistem özelliklerini etkiler
- Mimari özellikle şu durumlarda önemlidir
- Çözüm alanı küçük olduğunda
- Başarısızlık riski yüksek olduğunda
- Zor kalite özelliği gereksinimleriyle karşılaşıldığında
- Tasarım yaklaşımı olarak architecture-indifferent design, architecture-focused design ve architecture hoisting arasından seçim yapılabilir
- Risk odaklı modelin temel prosedürü basittir
- Riskleri belirleyip önceliklendirir
- Teknikler kümesini seçip uygular
- Risk azalmasını değerlendirir
-
- bölüm, Home Media Player sistemi örneğiyle risk odaklı modelin uygulanışını gösterir
- Ekip iletişimi
- COTS bileşen entegrasyonu
- Metadata tutarlılığının sağlanması
- Part I, modellerin ve yazılım mimarisinin kullanımına dair tavsiyelerle tamamlanır
- Problem çözmede modelleri kullanmak
- Kısıtları dikkatli eklemek
- Riske odaklanmak
- Mimari yetkinliğini tüm ekibe dağıtmak
Part II: Mimari Modelleme
- Part II, yazılım mimarisinin kavramsal modelini oluşturmaya yardımcı olmaya odaklanır
- Temel model yapıları üç tanedir
- Domain modeli: Gerçek dünyadaki nesnelere karşılık gelir
- Tasarım modeli: İnşa edilmekte olan yazılımın tasarımını temsil eder
- Kod modeli: Kaynak koda karşılık gelir
- Seçilmiş ayrıntıları gösteren ek modeller, yani view’lar oluşturulabilir; bu view’lar viewtype altında gruplanabilir
- Kapsülleme sınırları oluşturmak, yazılım mimarisinin önemli bir tekniğidir
- Bileşen veya modül kullanıcıları iç işleyişi göz ardı edip başka zor problemlere odaklanabilir
- Kapsüllenmiş bileşen veya modülün yazarı, kullanıcıları sarsmadan uygulamayı değiştirme özgürlüğü kazanır
- Bu özgürlük yalnızca kapsülleme etkili olduğunda mümkün olduğundan, kitap bunu güvence altına alan teknikleri ele alır
- Çeşitli kaynaklardan gelen yazılım mimarisi tekniklerini bütünleştirir
- Kalite özelliklerini vurgulayan teknikler
- İşlevleri vurgulayan teknikler
- Etkili modeller oluşturmak için pratik yöntemler
- Modelleri debug etme yöntemleri
- Part II, modelleri etkili kullanmaya yönelik tavsiyelerin yanı sıra bu tekniklerde karşılaşılabilecek tuzakları da ele alır
- Son hedef, soyutlamalar ve ilişkiler hakkında zengin bir kavramsal modele sahip olmak ve bir koçun maçı izlediği gibi yazılım sistemlerini görebilmektir
1 yorum
Hacker News görüşleri
Proje yönetimi riskinin “kilit geliştiricinin otobüs çarpması” ve yazılım mühendisliği riskinin “sunucunun 1000 kullanıcıya ölçeklenemeyebileceği” olduğu durumlarda ikisini ayırmak gerektiği söylenir; ama benim deneyimime göre pratikte bu kadar nadiren ayrı durmuyorlar.
Kod kalitesi ve yapı, testler ve dokümantasyon, standart ve iyi bilinen araçların kullanımı iki tarafa da yardımcı olur.
Bu yüzden meslektaşlarıma veya yöneticilerime birkaç kez “ya otobüs çarparsa?” varsayımını gündeme getirdim; bu, yeniden üretilebilir ve anlaşılabilir yazılım üretmek için bir baskı mekanizması oldu.
Yaralanma ya da ölümün olumsuz çağrışımından kaçınmak için “ya piyango çıkarsa?” demek daha iyi.
“Otobüs çarpması”nın özü, kişilikten bağımsız olarak hazırlanmak için hiç zaman olmaması; bu yüzden bilgiyi bugün paylaşma baskısı doğuyor.
Ne yazık ki aynı anlamı taşıyan olumlu bir ifade henüz bulamadım.
İkisi de yaklaşık bir hafta sonra geri döndüğü için başka bir standart felaket örneğine ihtiyaç doğdu.
Mesajı verirken “sonraki kişi” ifadesini daha sık kullanıyorum.
Daha kötü durum ise tükenmişlik; kişi sayısı aynı kalır ama zihinsel olarak çoktan ayrılmış olurlar.
Kalıcı ayrılık değil; buna bile dayanamayan çok şirket gördüm.
Ya da “otobüs faktörünü artırmak” gibi, tek hata noktasını ortadan kaldırma motivasyonuna odaklanan bir ifade de mümkün.
Kök neden analizi yapıyorsanız “Larry’ye otobüs çarptı / Larry’ye piyango çıktı” noktasında durmamalısınız; asıl sorun bu değil.
Mimari uğruna mimari en kötüsüdür; gereksiz yere karmaşıklığı artırır.
İyi mimarinin nihai hedefi maliyetleri düşürmektir.
Mimari yüzünden kodu geliştirmek ve bakımını yapmak daha fazla zaman alıyorsa, o mimari başarısızdır.
Her zaman bir denge kurma meselesidir.
Bu yüzden tek bir doğru mimari yoktur; seçim duruma bağlıdır ve bazen yeniden değerlendirilmelidir.
Esneklik özellikle faydalıdır, çünkü değişen koşullarda bile mimariyi bir ölçüde ayarlayıp verimliliği korumayı sağlar.
Maliyet düşürme bunlardan biri olabilir.
“Risk odaklı model, geliştiriciyi en acil riskleri azaltmak için asgari mimari teknikleri uygulamaya yöneltir. Israrla şu soruları sorma sürecidir: ‘Riskim nedir? Bunu azaltmak için en iyi teknik nedir? Risk hafifledi mi ve artık kod yazmaya başlayabilir ya da devam edebilir miyim?’ Risk odaklı model üç adımda özetlenebilir: 1. Riskleri belirle ve önceliklendir 2. Bir teknikler kümesi seçip uygula 3. Risk azalmasını değerlendir”
Etkisi düşük tekniklere zaman harcamak da istemezsiniz, projeyi tehdit eden riskleri görmezden gelmek de.
Başarılı bir sistem kurmak için zamanı en etkili kullanan yolu seçmek gerekir; bu da yalnızca risk motive ettiğinde mimari ve tasarım tekniklerini uygulayarak riskleri ele almak anlamına gelir.
Örneğin “mimari”, sunucunun önce davranmadığı, yalnızca istemci isteklerine yanıt verdiği istemci-sunucu stilini kullanmayı da içerir.
Bu yaklaşım soruna iyi uyabilir de uymayabilir de.
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Çok para alan teknik mimarlar pek bir şey yapmadan, teslim tarihi gibi mantıksız kısıtlar altında yazılım mühendislerinin çözmek zorunda kaldığı berbat kalıpları dayatır.
İyi mimari, daha fazla insanın ürüne katkıda bulunabilmesini sağlar.
2010'da yayımlandıysa, o zamandan beri ne kadar ayakta kaldığını merak ediyorum.
“Design It”i seviyorum; paydaşlar veya müşterilerle etkileşim kurması gereken teknik kişiler için iyi atölyeler ve etkinlikler içeriyor.
Danışmanlık rolünde olduğum için daha da ilgili; ayrıca sık değişen belirli teknoloji mimarisi stillerine fazla yaslanmaması da hoşuma gidiyor.
Modadan değil, gerçek ilkeler açısından konuşuyorum.
Yazar zihniyete dair denemelere çok zaman ayırıyor, somut teknikleri ise hafifçe ele alıyor; ama daha fazla okuma için kaynaklar sağlıyor.
Ekibin somut etkinlikler aracılığıyla mimari fikirleri ele almasını sağlıyor ve sonunda neyin önemli olduğunu ortaya çıkarıyor.
Benim kitabım bu büyük fikirleri doğrudan ele almaya çalıştı; fakat konu çok soyut olduğu için pedagojik olarak zor olduğu ortaya çıktı.
2010'dan sonra hangi fikirler ayakta kaldı? Bazı işletim sistemleri mikroçekirdekli, bazıları monolitiktir.
Bazı veritabanları ilişkisel, bazıları belge odaklıdır.
Bazı uygulamalar istemci-sunucu, bazıları eşler arasıdır.
Bu ayrımlar muhtemelen kalıcıdır; 100 yıl sonra geri dönseniz Windows, Oracle, Salesforce gibi örnekler kaybolmuş olsa bile bu tür tasarımlara sahip sistemler görebileceksiniz.
Ayrıca değiştirilebilirlik veya gecikme süresi gibi kalite özellikleri hakkında da hâlâ konuşacağız.
Yazılım mimarisi alanı, bu tür kalıcı soyutlamaları belirleme işidir.
[2]'de kısa bir açıklama var.
“Özet: Yazılım mimarisi, yapmayı planladığımız veya zaten yaptığımız yazılım hakkında akıl yürütmemize yardımcı olan bir soyutlamalar kümesidir. Alanımızda uzun süredir küçük soyutlamalar vardı; ancak kalite nitelikleri, bilgi gizleme, bileşenler ve bağlayıcılar, çoklu bakış açıları, mimari stiller gibi daha büyük soyutlamaların birikmesi onlarca yıl aldı. Bir sistem tasarlarken bu soyutlamaları birbirine örerek niyet zincirini korur ve tasarladığımız sistemin istediğimiz şeyi yapmasını sağlarız. 20 yıl önce Martin Fowler bu dergide etkili ‘Who Needs an Architect?’ yazısını yayımladı. Artık geliştiricilerin yazılım mimarisine yeniden bakmasının ve onu yazılım hakkında akıl yürütmeyi sağlayan bir soyutlamalar kümesi olarak görmesinin zamanı geldi.”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
John Ousterhout'un A Philosophy of Software Design kitabı faydalıydı.
Anlaması kolay, sağlam pek çok tavsiye ve çok sayıda örnek var.
Bu kitabın kendisini bilmiyorum ama yazarın Intellectual Control ile ilgili yazısını biliyorum; çok içgörülü.
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
Önceki şirketimde Simon Brown'ın Software Architecture for Developers kitabı elden ele dolaşıyordu: https://leanpub.com/b/software-architecture
Hâlâ okuma listemde ve o şirketten ayrıldım, ama güçlü bir şekilde tavsiye edilmişti.
O şirket mimariyi C4 modeliyle de belgeliyordu.
Burada okuyan biri var mı merak ediyorum.
Mimari konuşmaları [1] ve atölyeleri özellikle etkili; C4 mimari modelleme dili [2] de pratikte gerçekten ivme kazanıyor.
Benim YouTube videolarım da var [3], ama onunki kadar etkili değiller.
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Bu metodoloji için “riske bağlı” adı çok daha iyi olurdu gibi geliyor.
Programcılar neden “[X]-güdümlü” ifadesini bu kadar seviyor?
Bu mil şu dişliyi çalıştırır, o dişli de tekerleği çalıştırır gibi.
“Bu karmaşık düşünce makinesindeki en güçlü mekanizma nedir?” sorusunun kısaltılmış bir ifadesi.
Birkaç yıl önce şirkette bu kitapla bir okuma grubu yapmıştık; çok tekrarlı bulmuştum.
Önemsiz olmayan bir açık kaynak projesi başlatan biri için bu kitabın iyi bir kaynak olup olmadığını merak ediyorum.
Ya da tek kişilik bir girişimcinin bundan değer elde edip edemeyeceğini; solo geliştiriciler için faydalı kitaplar veya başka kaynak önerileri almak isterim.
Yazılım mimarisi normal mimariye benziyor, ancak yazılımda henüz Isaac Newton gibi biri olmadığı için inşaat mühendisliği yokmuş gibi bir durum var
Şu ana kadarki en yakın kişinin Claude Shannon olduğunu düşünüyorum
Çünkü ölçü birimlerimiz bile yok
Yazılım mühendisliğinde hâlâ “umarız çökmez” aşamasındayız
Bu da öz bildirime dayalı üretkenliği derinden etkiliyor
Örneğin camı açıkken, çok sayıda dur tabelası olan küçük bir banliyö yolunda saatte 30 mil hızla araba kullanmaya kıyasla bisiklet daha hızlıymış gibi gelebilir
Ama genelde sürücü 20 blok ötedeki yere çok daha hızlı varır
Ölçü birimi yoksa herkes bisikletin daha hızlı olduğunu tartışıp durur
Yazılım mühendisliği şu anda tam olarak bu durumda
Yazılım yapmak, köprü ya da gökdelen inşa etmeye hiç benzemez; daha çok bunları tasarlamaya benzer
Büyük mimari projelerde önce tasarım yapılır, sonra inşa edilir; bu tasarım başlı başına muazzam bir iştir
Her şeyi düşünmek, simülasyonlar çalıştırmak, paydaşlarla görüşmek, gereksinimleri ve kısıtları anlamak, malzeme maliyetlerini ve ağırlıkları vb. hesaba katmak gerekir
Büyük inşaat projelerinde yalnızca tasarımı ortaya çıkarmak için aylar ya da yıllar harcanabilir ve ortaya çıkan şey, inşaatın neredeyse tüm yönlerini kapsayan son derece ayrıntılı bir plandır
Aslında bu, yazılım yapmaya oldukça benzer
Bu tür tasarım projelerinde belirsizlik ve risk yüksektir
Yine de çok sayıda insan, beton, çelik gibi pahalı kaynakları kullanmaya başlamadan önce her şeyin yanlış olduğunu öğrenmek daha iyidir
Peki bir mimarın bunu azaltmak için tasarımın tasarımını yaptığını söylediğini hiç duydunuz mu? Böyle bir şey yok
Olsa olsa bir noktada bir eskiz ya da peçeteye çizilmiş bir taslak olmuş olabilir
SpaceX, mühendisliğe yazılım geliştirmeden öğrendiği bazı çevik unsurları dahil etti
Yazılımda tamamlanmış plan çalıştırılabilir durumdadır
Planı oluşturma süreci elle yapılan bir iştir; ancak o plandan yazılım üretme süreci genellikle derleyiciler ve diğer araçlarla otomatikleştirilir ve çok ucuz olduğu için geliştiriciler bunu sürekli yapar
Elbette eskiden bu her zaman böyle değildi
Çalıştırılabilir bir plan oluşturma sürecinde doğal olarak çok fazla risk vardır ve yer yer peçete ya da beyaz tahta tasarımları bulunabilir
Ancak önce eksiksiz bir tasarım, ardından eksiksiz bir uygulama yapma fikri, yani şelale yöntemi, yazılımda da hiçbir zaman düzgün işlemedi
Birkaç istisna dışında genelde planın planı yoktur
Royce’un şelale hakkındaki özgün makalesini okursanız, aslında “şelale” sözcüğünün hiç geçmediğini ve yinelemenin iyi bir fikir olabileceğini üstü kapalı biçimde önerdiğini görürsünüz
En azından bir kereden fazla yapın, der gibidir
İlk tasarımın büyük olasılıkla yanlış olacağını tamamen anlamıştı
Çevik yöntem, çok sayıda yineleme yapıldığında barizleşen, plan için tasarım oluşturma şeklindeki düşük değerli aşamayı optimize ederek ortadan kaldırdı
Sadece belirli alanların dışında bunları büyük ölçüde görmezden geliyoruz
Örneğin bu özet ve içindekiler tablosuna kabaca bakınca performans metriklerinden neredeyse hiç söz edilmiyor gibi, hatta hiç yok gibi görünüyor
Bilgisayarın gerçekte ne yaptığını dikkate almıyorsak mimarinin ne işe yararı var?
Geliştirici üretkenliği ya da kullanıcı arayüzü açısından da, yazılımı geliştirmek, değiştirmek, genişletmek ve daha da önemlisi kullanmak için gereken zihinsel yığını açıklayan matematiksel bir model neden yok?
İster insan ister makine olsun, hesaplama kaynakları bir geliştirici ya da kullanıcı olarak yazılımla etkileşim üzerinde gerçek ve ölçülebilir etkilere sahipken neden bunlar ancak nadiren dikkate alınıyor?
Örneğin Westminster Palace’ta kesinlikle inşaat mühendisliğine ait unsurlar vardır, ancak gösterişli dokular, simgesel saat kulesi, iç yerleşim gibi belirleyici özellikleri çoğunlukla işlevsel ve estetik tercihler yönlendirir
Yazılımın büyük kısmı için de aynısı geçerlidir