Bir süre önce Yazılımcı başlıklı bir yazı yazmıştım. O yazının konusu yazılım nedir sorusundan sonra yazılımı gerçekleyen kimdir sorusunun cevabı idi. Junior ve senior yazılımcı kavramları ve şirketlerin ve piyasanın bunlara yaklaşımı üzerine düşüncelerimi yazmıştım. Bu yazı ise o yazıda bahsetmediğim ve master seviyesi dediğim architect yani mimar konusunda olacak. Tabi bilgim ve tecrübem dahilinde piyasada bu kavramın karşılığı hakkında da yazmaya çalışacağım. Üç aşağı beş yukarı benim seviyemde tecrübesi olan yazılımcıların master olmasına doğru giden süreci ele almak ve mimari nedir sorusunu da değerlendirmek istiyorum.
Günümüzde yazılım alanında birçok uzmanlık alanı yani mindset var. Bunları backend, frontend, db, devops ve security şeklinde 5 temel kategoriye ayırabiliriz diye düşünüyorum. Not olarak belirteyim, bu kavramların iç içe geçtiği yerlerde şirket kültürü sakattır. Mobil uygulama dünyasına da bakarsak cihazların özelliklerini veya google ve apple 'ın çıkardığı yenilikleri takip etmek gibi bir skala var orada. Bu uzmanlık alanlarına saygı duyulmamasının getirdiği çıkmaz döngü ise şöyle: Her işe koşmaya çalışan developer -> kötü kod -> çok hata -> çok memnuniyetsizlik -> çok sirkülasyon -> az yenilik -> dinozorlaşma -> çalışsın yetercilik -> her işe koşmaya çalışan developer alımı... Böylece döngü başa dönüyor :) İşte bu anlayış içerisinde junior ve senior kavramları yerli yerince oturamadı sektörde. Architect seviyesi ise günümüzde bazı yerlerde saçmalamanın zirve noktası oldu. Eleştiri olarak söylemiyorum bunu ve mimar konumunda çalıştığını söyleyen hiç kimseye tabi ki sözüm yok. Sıkıntı bizim yaptığımız işte değil tanımlarımızda çünkü.
Benim üniversite yıllarımda (2006 - 2011) architect dediğimizde bir object oriented uygulamanın class 'larını, paketlerini, modüllerini nasıl yazacağımızı bunlar arasında gerekiyorsa nasıl bir design pattern oluşturmamız gerektiğini, veriyi nasıl handle edeceğimizi tasarlayan kişiler olarak söylerlerdi. O zamanlar yazılım anlayışı ağırlıkla monolitik olduğu için ve devops, DB veya frontend gibi uzmanlıklar öne çıkmadığı için kod yazmanın mimarisi vardı. Yazılımı gerçekleştirirken ihtiyaç duyulacak yardımcı kütüphaneleri veya kullanılan dilin derinliklerini bilmek de sizi mimar olarak yükseltebiliyordu. Yazılım geliştirme süreçlerine hakim olmak da benzer şekilde mimar olmanın gerekliliklerindendi.
Sonra benim gördüğüm kadarıyla bir ara geçiş döneminde teknolojiler gelişti ve maven, git, çeşitli db alternatifleri, backend için kullanılabilecek kütüphaneler vs gibi konularda da bilgi sahibi olan ve büyük resmi çizebilen kişiler architect olarak anılmaya başlandı. Bir bakıma yazılım alanında yeniliklere ayak uydurmuş kişilerdi bunlar. Bunlardan bazıları birden fazla yazılım dilinde de tecrübe edinirdi ve proje yöneticisi de olurdu aynı zamanda. Yani yönetimsel beceriler de aranmaya başlanmıştı ve bir taşla iki kuş vurulabiliyordu. Bu dönem fazla uzun sürmedi çünkü yazılım mimari yaklaşımları da ihtiyaçlara binaen hızla değişti. Günümüzde ise benim şahit olduğum 4 farklı mimar anlayışı mevcut. Bunları listeleyip biraz inceleyeceğim.
Bu 4 farklı yaklaşım konusunda eleştireceğim noktalar var. Önceki yazılarda belirttiğim gibi mimar kavramını da insanlar işlerine geldiği gibi kullandılar ve nedir ve ne olması gerekir sorusu epeyce karıştı. Mimar şapkası altında başka şirkette senior developer 'ın yaptığını yapan da var proje yöneticiliği yapan da.
1. kategorideki anlayışa göre sadece ağzınız laf yapıyorsa çok şey elde edebiliyorsunuz. Çünkü mimariyi bu şekilde algılayan ortamlarda bu yazılımsal araçlar konusunda bilgili birileri olmuyor. Zaten bu konularda bilgileri olsaydı kendileri bu kararları alabilirlerdi. 2. kategori ise sizi işe alan kişilerin tehlikeli kişiler olabileceğini gösteriyor. Bu tanımda bir mimar arayan kişiler konu hakkında bilgi sahibi olabiliyor ve size kendi çekemediği yükü yüklemek istiyor genelde. Yazılım alanında az yada çok bilgisi de olduğu için aslında ne istediğini biliyor. İş tanımınız mimar olmasına rağmen bu kişiler size zamanla developer muamelesi yapacaktır.
3. görüş her ne kadar benim kafamdaki architect mantığına çok uymasa da bir projenin doğasına ve business veya domain dediğimiz konseptine göre bir tasarım çıkarmak epeyce tecrübe veya bilgi gerektirecektir diye düşünüyorum. Bu durumlarda muhtemelen en yetkili ağız olacağınız için teoride doğru pratikte yanlış kararlarınız olsa bile yazılımcılar işi yürütebilecektir. Ama hem iş planlamak hem de teknik analiz yapmak proje yönetimi değil midir? 4. tanım ise içinde buluğunduğumuz çağa ayak uyduramamış olan tanımdır. Evet mimar olmak için yazılımda tecrübe kazanılmalı ve bunun için zaman harcanmış olmalı ama 15 yılda günümüzde bir yazılım dili bile doğup ölebiliyor :D Diyelim ki gerçekten bu tanıma uymak istediniz, 2000 'ler yazılım alanında çok hızlı geliştiği için 15 yıl gibi bir sürede sizin öğrenmeniz gereken belki de 5-6 mühendis ölçeğinde bilgi birikmiş olacak. Yıllarca hiç durmadan 4-5 farklı alanda en günceli takip eden, kod yazan ve değişimlere ayak uydurabilmiş 40 yaşında veya üstünde bir insan gördünüz mü çevrenizde? Bu tanım bunu gerektirir ve bana sorarsanız mümkün bile değildir.
Benim de bir tanımım var tabi ki mimar pozisyonu için ve 4 tanımdan da farklı: "Error, definition not found" :) Yani tam manası ile bir cümle ile bir mimar tanımım yok. Çünkü yazılım alanında teknoloji o kadar çeşitlendi ve değişti ki, bütün bunları takip etmemiz ve hepsi ile haşır neşir olmuş detaylarına vakıf olmuş olmamız zaten imkansız hale geldi. Bu yüzden günümüzde mimar olmak gibi bir yükü hakkını vererek kaldırabilecek bir insan yoktur bence. Bu yazılımda geçirilen yıl tecrübesinden ve insan zekasından bağımsız olarak, alanımızın çok genişlemesi yüzünden ortaya çıkmış bir sorundur. Mobil dünyasına girerseniz de mobil cihazlarda uyumluluk ve yeniliklerin takibi gibi durumlar çok kritik konulardır ve ayrıca takip edilmelidir. Bir web uygulamasında projenin doğasına göre kullanacağınız teknolojiler etkilenecektir. Data ile çok yoğun uğraşan bir proje olabilir, güvenlik seviyesi en üst düzeyde olmak zorunda olabilir, anlık 10 binlerce kişi aynı anda işlem yapmak zorunda olabilir, saniyelik bile olsa kayıplar istemeyebilirsiniz, tutarlılık hayâtî önem taşıyabilir ...vs. Eskiden bu kadar çok çeşitlilik ve kısıt yoktu yazılım dünyasında.
İlla ki benden bir mimar title 'ı istiyorsanız şöyle söyleyebilirim. Yazılımda (idealde backend uzmanlık alanında) öğrenme hızı kod yazma hızını geçmiş kişi mimar adayıdır. Team leader + initiator gibi bir kavramdır bu. Bu kişi gerektiğinde ar-ge yapar ve belli bir deadline olmadan senior 'lara yük bindirmeden kendi başına yeni bir teknolojiyi getirir. Bu kişi projeyi, domain 'i ve business 'ı dibine kadar anlar, tek dilde monolitik mi yoksa çok dilde mikroservis mi olmalı sorusuna cevap verir. Modüler ise modülleri ve kullanılabilecek design pattern 'leri belirler. Mikroservis ise orkestrasyon mu koreografi mi kararını verir ve toolset belirler. Kütüphaneler araştırır ve ideal olanı bulmaya çalışır. Projenin değişim ve gelişim göstermesi gereken noktada yol haritasını çizer. Projenin teknik açıdan sahibi ve sözü geçeni olur eğer bu aşamaların hakkını verebilirse. Yazılım geliştirme sürecinde ise proje yöneticisi ile dirsek temasında bulunan kişi olması gerekecektir.
Backend konusunda uzun zaman ve emek harcamış ve kendini bir şekilde geliştirmiş bir senior developer 'ın sanırım bir süre sonra girdi hızı çıktı hızını geçecektir. Bu da mimar olmaya doğru gidebileceğini gösterir. Benim tanımıma göre proje kodlanmaya başladığında mimarın işi bitiyor gibi görünüyor. Ama dediğim gibi bu kadar teknoloji bolluğunda birşeyler muhtemelen hatalı yapılacağı için veya zamanla isterler veya kavramlar değişebileceği için mimarın yenilikleri getiren kişi de olması gerecektir. Projenin kolay ve doğru bir biçimde hayata geçebilmesi için fikirler verebilecek kişi mimardır, tekrar yazılması için yol haritası ve teknik guide sağlayabilecek kişi mimardır. Bunlar her gün yapılmaz ama her projede tekrar yapılır. Yani yenilik ve gelişim gösterdiğiniz sürece gerçekten mimarlara ihtiyaç duyarsınız. Zaten bir mimarı bir projeye gömerek kullanmak da anlamsız olur.
Bir araba tasarlayıp 4 adet lastiği, bir kafesi, gaz ve fren pedalları olsun dediğimizde (bir çocuk seviyesinde) arabanın mimarı mı olmuş oluyoruz? Hayır, araba dediğimiz kavram zaten budur kabaca. Peki bir yazılımı uçtan uca çalışır hale getirmek için gereken bütün tool 'ları bilince mimar mı oluyoruz? Yine hayır. Bunların hangilerini birbirleri ile uyum içinde kullanabileceğimizi bildiğimizde biraz yaklaşıyoruz. Bu durumda da yazılım dünyasındaki sınırlı bilgimiz ile optimal çözüme ulaşamıyoruz. Bu yüzden öğrenme hızı geliştirme hızını geçen birisi en azından neyin eksik olabileceğini arayıp bulabilir, optimale yaklaşabilir. Bu da mimarın işidir. Mimariyi idealize etmek, ederken de tecrübe ile doğru alanlara yönelebilmek ve doğru soruları sorabilmek mimarın asli görevidir.
Corporatization yani kurumsallaşma ekseninde her şirket istediği mühendislik alanına istediği anlamı yükleyebilir. Oturduğum yerden bunu sorgulamak veya eleştirmek yerine bu konuda idealleri arıyor olmak gerekiyor. Bu yüzden "biri gider biri gelir" gibi anlayışlarla çalışıp, bilgi ve tecrübenin kıymetini düşüren ve kavramların içlerini boşaltan günümüz yaklaşımını yanlış bulsam bile oturup şirketler şöyle böyle şeklinde yazılar yazmam. Ama mesleğimin alamet-i farikasının kalifiye olmayanların elinde dezenformasyona uğramasını istemiyorum. Bu yüzden yazılım mühendisliğinde bilgi ve tecrübenin doğru tanımlarla doğru yerde doğru şekilde değerlendirilebilmesi için kendimce bazı çıkarımlar yaptım. Burası benim oyun alanım. Bir sonraki yazıda görüşmek üzere :)
Bir yorum yazabilirsiniz