Programcı, Developer, Architect (Mimar), Bilgisayar Mühendisi ve Yazılım Mühendisi – II

Bir önceki yazıda programcı ve developerdan bahsettik, konumuza devam edelim.

Architect ya da mimar, geliştirilecek olan yazılım sisteminin yüksek seviyeli tasarımını yapan kişidir. Mimar, yazılım bileşenleri ile temel özelliklerini, aralarındaki iş bölümünü ve iletişimi, katmanlar ve aralarındaki ilişkileri, kullanılacak teknolojileri, donanım altyapısı vb. sistem özelliklerini, performans, güvenilirlik (reliability) gibi fonksiyonel olmayan ihtiyaçları yerine getirecek şekilde belirler. Bu açıklamadan da anlaşılacağı gibi mimar, fonksiyonel yapıları, her türlü detayıyla tasarlayan kişi değildir. Bu anlamda yazılım mimarı, mimari olarak kritik olan fonksiyonel yapılar üzerinden hareket eder, sistemin yüksek seviyeli özelliklerini ve haritasını bu kritik fonksiyonel yapıları kullanarak belirler, detaylı fonksiyonel tasarıma girmez.

Böyle bir pozisyon, açıklamasından da anlaşılacağı gibi, öyle pat diye bir-iki senede elde edilecek tecrübe ile doldurulamaz. Kaldı ki sadece tecrübe ile de doldurulacak bir pozisyon değildir yazılım mimarlığı. Soyut ve sistem bazında düşünme becerileri çok önemlidir. Örneğin bileşenlerin API tasarımını yapmak, ön bellek kullanımı (caching) kurgulamak, transactional yapılara karar vermek, kullanılacak teknolojilerin mesela performans açısından en iyi kullanımları (best practices) belirlemek, alınan kararların UML gibi formal bir yolla dokümante etmek ve yaygınlaştırmak vs. bu anlamda mimarın yapması gereken işlerdendir. (İşin açıkcası kurumun ve projenin büyüklüğüne göre, veri, integrasyon, uygulama vb. konularda ayrı ayrı mimarlara ihtiyaç duyulabilir. Bu durumda kurumsal mimarinin (enterprise architecture) farklı vechelerinden bahsediyoruz demektir. Burada ele aldığımız daha çok uygulama ya da çözüm mimarıdır.) Yazılım mimarı, yüksek seviyeli bu gibi kararların alınmasında öncü durumdadır ama muhtemelen etrafındaki developerlarla çalışarak ilerler. Aldığı kararların tüm yazılım geliştirme takımı tarafından benimsenmesi ve sürekli bir şekilde uygulanması için takım ile iletişimini sürekli olarak korur. Bu anlamda yazılım mimarı bürokratik olarak yazılım geliştirme biriminde olmasa bile projede takımın bir parçası olur. Hatta benim gözlemlediğim, ülkemizdeki pek çok yazılım projesinde çalışan mimarlar, yazılım da gelişiren, kritik ve öneli bileşenlerin geliştirme sorumluluğunu üzerinde tutan kişilerdir.

Ülkemizde bildiği iki teknolojiyi bir araya getirip yazılım geliştiren herkes kendini mimar yerine koyuyor. Böyle bir algı, yazılım mimarisi kavramını sadece teknoloji seçimine indirgeme basitliğinin bir sonucudur. Yani örneğin Java EE teknolojilerinden hangilerinin kullanılacağına karar vermek, mesela web tarafında JSF, orta katmanda Spring, arkada, veri tabanı iletişiminde JPA kullanmaya karar vermeyi, yazılım mimarının tek yapacağı iş olarak görmenin sonucudur. Halbuki mimarlık programcılıktan farklıdır ve sadece zamanla elde edilecek bir sıfat da değildir. Sonuçta iyi mimarlar iyi programcılık geçmişine sahip kişilerdir ama her programcı hayatının ilerleyen zamanlarda otomatik olarak mimar olacak demek değildir. Bu anlamda malesef bu ülkede yazılım mimarlığı, programcılığın ya da developerlığın tabi bir uzantısı olarak görülüyor. Bu roller, pek çok ortak yönleri olsa ve birbirlerine çok yakın çalışsalar da sonuçta farklı yetki ve görevleri olan kişiler. Ben senelerce belli teknolojilerde uzmanlaşmış ama soyut düşünce yeteneklerini geliştirmeye ağirlık vermemiş, teknolojsini ve iş alanını çok iyi bilen kişilerle tanıştım ve çalıştım.

Yazılım projelerinde iyi-kötü bir mimari yapının kurgulanması ve tüm takım tarafından uygulanması, o yazılımın daha tutarlı, daha yeknesak, birlikteliğinin (cohesion) daha yüksek olmasını sağlar. Merkezi olarak alınmayan kararlar nihayetinde yazılım sisteminin aynı şeyi pek çok yerde tekrarlayan, bileşenleri arasında kaotik bir iletişime sahip hale getirir. Mimari kararların, farkında bile olmadan sadece developer/programcılar tarafından alındığı bir yerde sistemin sonunda değişemez, performans, scalability gibi açılardan çıkmaza girmiş hale gelmesi kaçınılmazdır.

“No Silver Bullet” isimli makalesinin sonunda F. Brooks, yazılımın asli zorluklarına çözümler ya da “silver bullet” (gümüş kurşun ya da daha anlamlı bir Türkçeyle ifade etmek istersek, sihirli değnek) önerirken “great designers” yani “mükemmel tasarımcılar”dan bahseder. Makalenin yazıldığı 1987 yılında tasarımcı, mimar vb. ayırımların henüz çok farkında değildik, bu yüzden bu ayırıma takılmadan Brooks’un “mükemmel yazılım mimarları”ndan bahsettiğini iddia edebiliriz. Yazılım geliştirmenin yaratıcılık gerektiren bir süreç olduğunu, dolayısıyla en iyi uygulamaları bilen kişilerin, doğru kavramsal modelleri ortaya koyabileceklerini ifade eder Brooks. Sonra da mükemmel mimarların, mükemmel yöneticiler gibi çok az bulunduğunu vurgular. Bu yüzden Brooks, kurumlara, bünyelerindeki “mükemmel tasarımcı” adaylarını erkenden bulup, onları yetiştirmelerini tavsiye eder.

Kariyerine yazılım mimari olarak devam etmek isteyen arkadaşların yazılım mimarisi kitaplarını okumaları, uygulama, veri, entegrasyon vb. konulardaki mimari yaklaşıkmları bilmeleri, farklı seviyelerde tasarım çalışmalarında bulunmaları, tasarım ve mimari kalıpları özümsemeleri, kullandıkları dilleri ve bu dillerdeki bileşen ve çerçeve (framework) yapılarını, bu teknolojilerin en iyi uygulamalarını iyice öğrenmeleri, performans, ölçeklenirlik gibi mimari konular üzerine çalışmaları ve soyut tasarım çalışmalarını ifade etmek için gerekli UML gibi formal yapıları ögrenmeleri gereklidir.

Kaliteli yazılımlar için kaliteli yazılım mimarlarına ihtiyacımız var.

Toplam görüntülenme sayısı: 1702