Clean Architecture Serisi: Design ve Architecture Nedir? — Part 1

Yazılım mimarisini anlayabilmek için Robert C. Martin’in Clean Architecture kitabını adım adım okuyorum. Her bölümden edindiğim notları ve kendi yorumlarımı bu seride paylaşacağım.

Bu yazıda Clean Architecture — Part 1 kısmından aldığım notları yazıya dökeceğim.

Bölüm 1 — What is the design and architecture?

Yazar, yıllardan beri design ve architecture kavramları üzerine anlam kargaşalarının varolduğundan bahsettikten sonra bu kavramlar ile ilgili kendi fikirlerinden bahsediyor. Yazara göre bu iki kavram arasında hiç bir fark yok. Design kavramının alt düzey yapılar için kullanıldığını, architecture kavramının ise daha çok üst düzey yapılar için kullanıldığını belirtiyor. Yazar, alt düzey yapıların üst düzey yapıları oluşturduğunu, dolayısıyla bu iki kavram arasında herhangi bir fark olmadığını söylüyor.

The goal?

Yazar “hedef” tanımını kendince ütopik bulduğu şu cümle ile yapıyor:

“The goal of software architecture is to minimize the human resources required to build and maintein the required system.”

Bir işin tamamlanması ve sürdürülebilmesi için insan kaynaklarının en az şekilde kullanılması yazarın hedef tanımını oluşturuyor. Aslında bu tanım, bana sürdürülebilir bir sistem için gereken disiplinlerin uygulanması sonucu elde edilen bir meyvenin tanım olarak kullanılması gibi geldi, yorum sizin :)

Case Study

Yazar bu kısımda yaptığı hedef tanımına örnek olacak şekilde veriler sunuyor. Bir şirketin artan işe alım grafiğinin gösterimine karşın şirketin üretkenlik konusunda zamanla düşüşü, her bir düzenleme maliyetinin her geçen sürede ne kadar arttığını temsil eden verilerle aslında kendi “The goal” tanımının doğruluğuna atıfta bulunuyor.

Ortadaki bu ters orantılı tablonun sebebini aslında “tavşan ve kaplumbağanın yarışı” ndan örnek vererek açıklıyor. Bir şey yapacakken hızlı davranılması, sonuç odaklı olunması ve bunların sebebiyle oluşan muhtemel problemlerin gözardı edilmesinin bu duruma sebebiyet verdiğini belirtiyor. Yavaş, her şeyi olabildiğince düşünerek hareket edilen, çözüm yerine sürece odaklanılan bir ortamın daha verimli olacağını belirtiyor.

Press enter or click to view image in full size

Verdiği bir grafikte de, kendinden emin şekilde başlanan problem çözümlerinin; yavaş, durum analizi yapılan, gereksinimleri belirlenen ve doğru kararların alınarak çözüme ulaşmanın karşısında ne kadar aciz olduğunu, ve bu acizliğin giderek arttığını belirten bir grafik ortaya koymuş.

Conclusion

Sonuç olarak, aşırı özgüvenli/kendinden emin şekilde hareket etmek yerine içinde bulunduğu durumun analizini yapan, sonuca değil sürece odaklanan ve kaliteyi amaçlayan bir şekilde hareket edilmesini söylüyor, ve bu güzel mimari/tasarımın nasıl oluşturulacağı ile ilgili gerekli konuların bu kitapta anlatılacağını belirtiyor.

Press enter or click to view image in full size

Bölüm 2 — A tale of two values

Yazara göre bir sistem iki şeyi sunmalı: Behavior ve Structure. Bu iki değerin olabildiğince yüksek tutulması gerektiği, fakat yazılımcıların bu iki değerden birine daha fazla ağırlık vermesinden dolayı sistem değerinin düştüğü bahsediliyor.

Behavior

Behavior, yazara göre sistemin yetenekleridir. Bu yeteneklerin sisteme kazandırılması konusunda “ilk önce yapalım, sonrasında hata oluşursa düzeltiriz” gibi yaklaşımların ne yazık ki yanlışlıktan ibaret olduğunu belirtiyor.

Architecture

Yazar, architecture kısmına software kelimesindeki “soft” kısmıyla başlıyor. Yazılımların soft olmasını, dolayısıyla yazılımın kolay değiştirilebilir olması gerektiğini belirtiyor. Yazılıma yapılacak bir değişikliğin zorluk derecesinin, o değişikliğin kapsamıyla doğru orantılı olması gerektiğini söylüyor. Bu orantının lineer şekilde ilerlemesi ise, sistemin sağlıklı ve olması gerektiği gibi çalıştığının bir göstergesi gibi geliyor bana.

Bu değişikliklerin de uygulamanın mimarisine uygun şekilde yapılması gerektiği vurgulanıyor. Yapılan her değişikliğin veya geliştirmenin, yazılımın esnekliğine ve tepkiselliğine olumsuz etki etmemesi gerektiğinin altı çiziliyor. Ayrıca, yazılımcıların ve yöneticilerin olası değişim senaryolarında bu kriterlere özellikle dikkat etmeleri gerektiği belirtiliyor.

The Greater Value

Asıl değer sizce nedir? Sisteminizin yapısı mı yoksa sisteminizin yetenekleri mi? Yazara göre bu soru yönetici ve yazılımcılara sorulduğunda sistemin o anki ihtiyaçları karşılayabilmesinin daha çok tercih edildiğini söylüyor. Bu düşüncenin yanlışlığını da şu cümleler ile kanıtlıyor:

• If you give me a program that works perfectly but is impossible to change,
then it won’t work when the requirements change, and I won’t be able to
make it work. Therefore the program will become useless.
• If you give me a program that does not work but is easy to change, then I
can make it work, and keep it working as requirements change. Therefore
the program will remain continually useful.

Eisenhower’s Matrix

Bu matrixi illaki duymuşsunuzdur. Bu matrixe göre işlem önceliklerimizin şu sıra ile düzenlemesi gerektiği belirtiliyor:

1. Urgent and Important
2. Not Urgent and Important
3. Urgent and Not Important
4. Not Urgent and Not Important

İşlem önceliklerinin, bu sıraya göre oluşturulmasının ideal olduğunu belirtiliyor. Yazar, bu önceliklendirmenin herhangi bir mimari değerlendirme kapasitesi olmayan bir yönetici tarafından yapılmasının, sistemin kötüye götüreceğini, bu sebeple yazılım geliştiricilere özelliklerin aciliyetinden ziyade sistem mimarisi öneminin vurgulanmasını tavsiye ediyor.

Fight For The Architecture

Yazar, “yazılımcıların özellik yerine mimariyi vurgulaması” konusunun hep sancılı olacağından, aynı zamanda da bu durumun sürekli olması gerektiğinden bahsediliyor bu bölümde. Şirketteki her departman kendine göre haklı düşüncelerini vurgular, bu alışkanlık iyi ürün geliştirmeye yarar. Bu sebeple yazılımcıların, özellikle de yazılım mimarlarının sistem mimarisinin önemi hakkında ekstra vurgular yapması gerektiği belirtiliyor.

Bu yazıda Clean Architecture — Part 1 kısmından anladıklarımı yazıya döktüm. Diğer bölümlerde görüşmek üzere.