惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
腾讯CDC
爱范儿
爱范儿
Google DeepMind News
Google DeepMind News
V
V2EX
Blog — PlanetScale
Blog — PlanetScale
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI
量子位
F
Fortinet All Blogs
G
Google Developers Blog
T
The Blog of Author Tim Ferriss
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Hugging Face - Blog
Hugging Face - Blog
Last Week in AI
Last Week in AI
T
Tailwind CSS Blog
J
Java Code Geeks
S
SegmentFault 最新的问题
D
Docker
博客园 - 司徒正美
The GitHub Blog
The GitHub Blog
Jina AI
Jina AI
M
MIT News - Artificial intelligence
博客园 - 【当耐特】

Yusuf Aytas

When Code Is Cheap, Does Quality Still Matter? Why Crouching Tiger, Hidden Dragon Is a Masterpiece Why We Ignore Advice The Mirror Is Part of the Machine When Too Many Maps Overlap on One Person The Work Runs on Different Maps Your Work Introduces You Trial By Fire The Dude Why Headcount Math Lies Capacity Is the Roadmap The Roadmap Is Not the System Torres del Paine W Trek Escaping Status Theater Incentives Drive Everything Scaling Culture Without Dilution What Good Looks Like Why Airport Security Feels Random Why Politics Appear How to Work with Me The Janus Protocol Multi-Horizon Delivery Framework What Good Execution Looks Like Managing Your Manager Why Kingdom of Heaven’s Director’s Cut Is Better AI Broke Interviews Most of What We Call Progress Managers Have Been Vibe Coding All Along Stop Wasting Brainpower Why Over-Engineering Happens
Yazılım Mimarisi
Yusuf Aytas · 2009-12-27 · via Yusuf Aytas

Published · 3 min read

Yazılım mimarisi şemasıYazılım mimarisi şeması

Mimari denildiğinde insanın aklına gelebilecek ilk konu değildir yazılım. Ama nasıl köprüler, barajlar gibi büyük yapıtların bir mimariye ihtiyacı varsa, geniş kapsamlı yazılım projelerinin de mimariye ihtiyaçları vardır. Çünkü projeler büyüdükçe bunların üstesinden gelmek zorlaşır. Dolayısıyla, karmaşık ve büyük çapta sistemleri tasarlamak için aslında olaylara çok basit noktalardan bakmak gereklidir. Bu noktada detaya fazla girmeden size neden ve nasıl yazılım mimarisi yapıldığından bahsedeceğim. Örneklerim biraz olağan dışı olursa beni mazur görün.

Öncelikle, neden mimariye genelde ihtiyaç vardır sorusunun yanıtını vererek başlayalım. Düşünün ki bir sürü inşaat işçisi duvar yapabiliyor. Hepsini bir araya getirsek ve Taç Mahal yapmalarını istesek bu yapıtı inşa edemeyiz. Ancak bir mimar yapıtın mimarisini çıkarırsa ve daha sonra bu mimarinin mühendisliği yapılırsa bu şekilde planlı ve programlı şekilde ilerlenir, dolayısıyla ortaya eşsiz eserler çıkarılabilir. Aynen bu şekilde de yazılımlarda bu sistem geçerlidir. Mesela bir oyun yapılacak ya da Facebook gibi bir site. Şimdi siz bu siteye salt bakamazsınız. Sebebi, çok iyi bir mimarisi olmaz ise sistem yeni gelen teknolojileri ya da yazılımları kabul etmeyecektir. Sadece o değil, nereden başlayacağınızı da bilemezsiniz. Çünkü sistem o kadar karmaşık ki planınız olmadan üstesinden gelinemez. Bu noktada amaç geliştirilebilir, yeniliklere açık, uygulanabilirliği kolay ve sağlam sistemler oluşturmaktır. Bu durumda da mimari artık kaçınılmazdır.

Eğer sizi yazılımların da mimariye ihtiyacı olduğuna ikna ettiysem size yazılım mimarisinin nasıl yapıldığına dair yüzeysel bilgiler vereyim. Genel olarak yaptığınız yazılımlar 2 parçaya ayrılabilir. Birincisi kullanıcıların görüp kullandığı görünüm arayüzü (Graphical User Interface), ikincisi de bu arayüzün planlayıcısı ve kontrol mekanizması olan bir mantık ünitesidir. Şimdi mimari bu noktada başlıyor. Görünüm arayüzünü o kadar iyi ayırırsınız ki alttaki mantık ünitesinden, iki kısım da birbirinden etkilenmez. Buna şöyle bir örnek vereyim. Şimdi Facebook yeni bir tema oluştursa kendisine, sizce var olan her şeyi değiştirir mi? Tabii ki hayır. Var olan temayı başka bir temayla rahatça değiştirebilecek bir sistemleri vardır. Bunu da mimarileriyle başarmışlardır. Peki bu mimari dediğimiz şey bu iki üniteyi sadece birbirinden ayırmak mıdır? Hayır, değildir. Maksadımız sistemi yukarıda saydığımız özelliklere kavuşturmaktır. Sistemi öyle yapmak istiyoruz ki her şeyin yerine yenisi çıkarılıp takılabiliyor olsun. Tabii bu hiçbir zaman tamamı ile başarılabilecek bir durum değildir. Bu da bilgisayar ve yazılım mühendislerinin çalıştığı alanlardan biridir.

Şimdi bilgisayar mühendisi ve bilgisayar bilgisi iyi olan arkadaşlara yönelik kısıma geldik. Bu kısımda size yazılım mimarisinde kullanılan birkaç şablondan (pattern) bahsedeceğim. Öncelikle hepinizin bildiği pattern Model-View-Controller en çok bilinen ve yaygın olarak kullanılan mimari şablonudur (architectural pattern). Bunun yanı sıra oyun şirketlerinin çok kullandığı Peer-to-Peer yaygın bir şablondur. Bu şablonda internet üzerindeki kullanıcıların aynı anda hem sunucu (server) hem de alıcı (client) olabileceği düşünülerek tasarlanmıştır. Bundan başka Pipe and Filter diye bir şablonumuz var ki bu da genelde derleyiciler (compiler) için kullanılmaktadır. Bu mimaride yapılacak işlemi parçalara ayırma güdülmüştür. Bunu şöyle açıklayabilirim. Mesela bir kodu derleme işlemini şu şekilde yapar bu tür sistemler. İlk önce bir syntax analizi yapar, burada hata varsa durur, sonra array'in sınırlarını kontrol eder. Daha sonra başka bir takım işlemlerden geçirdikten sonra kodunuzu derlemiş olur. İşte bu tür sıralı işlemlerde bu şablon kullanılmaktadır. Son zamanlarda çok yaygın olan bir diğer şablon ise Service-Oriented-Architecture'dır. Bu mimaride ise temel olarak bir sistem üzerinde birden fazla küçük sistemin uyumlu şekilde çalışması güdülür. Örnek verecek olursak, Facebook üzerinde FarmVille'in çalışması gibi. Şu an açıklamadığım ama merak edeceğiniz diğer önemli mimari şablonlarını ise sıralıyorum: Multitier Architecture, Implicit Invocation, Blackboard System, Naked Objects.

Bu kadar çok konuşup başınızı ağrıttıktan sonra yazımı burada tamamlamak istiyorum. Kısaca karmaşık işlerin çözümü basitten başlamaktan geçer. Bundan dolayı da mimari yazılımda gerekli olan çok önemli bir kavramdır.