Aşamalı ilerleme yöntemleri çok eskiye dayanmakmaktadır. Aslında çoğu mühendislik biliminde de karşımıza çıkan bir uygulamadır. Ama, yazılım dünyasında çevik diyebileceğimiz algı, 1974 yılında E. A. Edmonds tarafından yayımlanan  uyarlanabilir yazılım geliştirme süreci (adaptive software development process) adlı  makaleye dayanmaktadır. Fakat, çevik yazılımı ortaya çıkmasındaki en büyük etken, klasik mühendislik yöntemlerinin bilgisayar biliminde yeterli olmamasıydı.  Klasik mühendislik methodları, ürünün her bir parçasının geliştirme sürecine girmeden önce tek tek ele alınıp tasarımı yapılıp sonrada üretim bandına sokulmasını öngürür. Halbuki, yazılım dünyasında ürün her an değişebilir nitelikte olmalıdır. Bu durum,  daha dinamik bir yöntem olan çevik yazılım geliştirme kavramını ortaya çıkardı.

Çevik yazılım geliştirme klasik anlayıştan vazgeçerek,   değişime her zaman  ayak uydurmaya dayanan bir anlayış. Çevik yazılım, projenin safhalara bölünerek, her safhada çalışan bir ürün elde etmeyi hedefler. Her bir safha kendine özgü tasarım, kodlama ve test etme faaliyetlerinden oluşur. Safhanın bitiminde elde edilen ürün, varolan gereksinimleri karşılayamıyor yada gereksinimleri değiştiyse bir sonraki safhada düzeltilir. Yeni safhada müşeteri ile müzakere edilerek, safhanın planı yapılır. Ürün tamamlanana kadar bu döngüye devam edilir. Çevik yazılımın etkin bir şekilde uygulanması için aşağıda anlattığımız bir kaç unsurun uygulanması önem taşımaktadır.

İhtiyaçların anlaşılması ve değişikliklerin iyi yorumlanması için müşteri yada çalışma alanında uzman biri(domain expert) ile birlikte çalışılması en önemli unsurlardan biridir. Çünkü, gerekli bilgilerin en doğru ve hızlı aktarımı gereksinimlerin birinci ağızdan duyulmasına bağlıdır. Bu yapılmadığında yazılımcılar kendi anladıklarını hayata geçirerek, bir sonraki safhada geliştirilen ürünü fazlaca değiştirmeye hatta sil baştan yapmaya  sebep olabilir. Dolayısıyla, çevik yazılımda müşteri de yazılım ekibinin bir parçası olmalıdır.

Çevik yazılımda önemli olduğuna inandığım bir diğer unsur takım çalışmasıdır. Projedeki her bir birey, projenin ne doğrultuda olduğunu ve kendisinin ne yaptığını  iyi anlaması gerekir çünkü ekipteki her elamanın farkındalığı ve dinginliği proje için önemlidir.  Ayrıca, proje ekibinde  elemanlar arasındaki farklar gözetilmelidir. Aksi takdirde, yapılan işlerde gecikmeler yada erken bitirme durumları ortaya çıkabilir. Önemli olan görevleri  ekipçe zamanında bitirmektir.

Çevik yazılım, adından da anlaşılabileceği gibi kolay ve çabuk bir şekilde yeni gelen yada değiştirilen gereksinimlere ayak uydurmaktır.  Varolan mühendislik yöntemlerinin, yazılım sektörü için uygun olmayışından ortaya çıkan bir yöntemdir. Ana felsefesi, yazılım sürecinin safhalara bölünerek, her bir safhada çalışan bir ürün elde etmektir. Bu felsefeyi uygularken, takım çalışması ve müşteri etkinliği dikkat edilmesi gereken unsurlardır. Sonuç olarak çevik yazılım, gereksinimlerin sürekli değiştiği yazılım dünyası için güzel bir yaklaşımdır.

Parçaların biri birine bağlı olması, gerçek hayatta karşımıza sıkça çıkan sorunlardan biridir. Çoğu zaman, yazlımın içindeki bağlılıkların(dependency) ortaya çıkmasında başlıca rol oynamaktadır. Bu duruma örnek verecek olursak, bir fonksiyonda güvenlik(security), kayıt düşme(logging) ve veri işleme(transaction processing) bağlılıkları olabilir. Bunları aynı yerde yazmak, yazılımın çok karmaşık bir yapıya bürünmesine neden olur. Bu durum, önemli bir dez avantaja, yazılım parçalarının yeniden kullanılmasını engel teşkil eder. Aşağıdaki örnekte bu duruma örnek verebileceğimiz bir fonksiyon görebilirsiniz.

public boolean saveStory(String story) throws Exception{
	if (user.isAuthenticatedUser()) {
		if (persister.save(user.id, story)) {
			logger.info("Story for the user has been added.");
			return true;
		} else{
			logger.error("Story is not saved.");
			throw new StoryNotSavedException();
		}
	} else{
		logger.error("User is not authorized.");
		throw new UnAuthorizedUserException();
	}
}

Yazılımdaki kısımların biri birine bağlı olması sorununu AOSD ile etkili bir şekilde çözebiliriz. AOSD bizim asıl fonksiyonu hayata geçirip, yardımcı fonksiyonlardan kurtulmamızı sağlayan bir yaklaşımdır. Yukarıdaki örnek üzerinden gidecek olursak, fonksiyondaki asıl amaç kullanıcı hikayesini başarılı bir şekilde kaydetmektir. Ama hikayeyi kaydederken, hikayenin kaydedildiğine dair kayıt düşme, kullanıcının bu işlem için yetkili olup olmadığına bakma ve veri işleme bizim yardımcı yada destekleyen işlevlerimizdir. AOSD, bizim asıl fonksiyona yoğunlarşıken, dışarıdan müdahale ile(by the help of pointcut) gerekli diğer işlevleri yerine getirmemizi sağlar.

Spring Framework AOSD’ye aspectj paketiyle destek oluyor. Dahası, Spring Framework kendiliğinden bazı cepheleri(aspect) sağlıyor çünkü Spring’in uyguladığı annotation’lar  cepheye yönelik programlamanın parçalarıdır denebilir. Mesela, @Autowired-Spring Bean olan bir nesnenin başka bir nesne içinden kısa yoldan çağrılmasına yarar yada @Component-Sınıfın Spring Bean olduğunu gösterir. Bu tip kullanımlar koddaki bağımlılığı azaltarak, fonksiyonların yada sınıfların daha basit olmasına yardımcı olarak, Spring’in daha basit olmasını sağlıyor.

Cepheye yönelik programlamanın uygulamasını Spring Framework’un AspectJ paketini kullanarak yapabiliriz.  Aşağıdaki kodda size yukarıda verilen fonksiyonun, cephe yardımıyla nasıl kayıt düşme bağlılığından kurtaracağımızı görebilirsiniz. Kısaca bir kaç kavramdan bahsetmek istiyorum. AOSD’de fonksiyonlara erişim noktası pointcut adıyla tanımlanmıştır. Belirli bir erişim noktasıyla, istediğiniz fonksiyona ulaşıp fonksiyonun işleyişine(@AfterReturning) göre işlem yapabiliriz. Bizim örneğimizde within ve execution erişim noktalarını kullanarak fonksiyona ulaşıp, işleyişine göre kayıt düşme işlemini gerçekleştirdik. Kullanım detayları için Spring AOSD referansına bakabilirsiniz.

package com.yusufaytas.ao;
 
import org.apache.log4j.Logger;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
 
import com.yusufaytas.example.StoryNotSavedException;
import com.yusufaytas.example.UnAuthorizedUserException;
 
@Aspect
public class LoggingAspect {
 
	Logger logger = Logger.getLogger(LoggingAspect.class.getName());
 
	@Pointcut("execution(public * saveStory(..))")
	public void saveStory(){}
 
	@Pointcut("within(com.yusufaytas.example.LoggingExample)")
	public void inLoggingExample(){}
 
	@Pointcut("saveStory()&&inLoggingExample()")
	public void saveStoryInLoggingExample(){}
 
	@AfterThrowing(pointcut="saveStoryInLoggingExample()",throwing="ex")
	public void logUnAuthorizedUserException(UnAuthorizedUserException ex){
		logger.error("User is not authorized.");
	}
 
	@AfterThrowing(pointcut = "saveStoryInLoggingExample()",throwing="ex")
	public void logStoryNotSavedException(StoryNotSavedException ex) {
		logger.error("Story is not saved.");
	}
 
	@AfterReturning(pointcut="saveStoryInLoggingExample()",returning="isSaved")
	public void logDatabaseAccess(boolean isSaved) {
		logger.info("Story for the user has been added.");
	}
 
}

Yazılımda öncelikli amacımız, yazdığımız kodun basit ve olabildiğince geliştirilebilir, sürdürülebilir yada rahat bir yapıya sahip olmasıdır. Bu durum göze alındığında, cepheye yönelik programlama, bu ihtiyaçları karşılamak için kullandığımız bir yöntemdir. Bunun haricinde daha öncede bahsettiğimiz, yazılım şablonları yada kullanılan kütüphaneler yine yukarıda saydığımız gereksinimleri karşılamaya yöneliktir. Yazıda sıkça bahsettiğim Spring Framework de sınıfların biri birine bağlanmasını önleyen bir şablonu(inversion of control) hayata geçirerek yazılımcıya basit bir ortam sunarak gereksinimlerimizi karşılamaktadır. Sonuç olarak, cepheye yönelik programlama bazı noktalarda iyi bir yöntem olsa da öncelikli tercihin yazılım şablonları yada kütüphane desteğini kullanmak olduğuna inanmaktayım. Her konuda olduğu gibi değişik yaklaşımlar arasından en iyisini seçmenin yada birden fazla yaklaşıma sahip olmanın fark yaratacağını düşünüyorum.

Karşılaştırmamıza ilk olarak Bayern Munich ile başlıyoruz, en iyi oldukları dönem ise 1974-76. Bu dönemde Bayern, 3 defa o zamanın şampiyonlar ligi kupasını aldı. Bu dönem içinde göze çok güzel bir futbol oynamamalarına rağmen bir çok kupanın sahibi olmayı başarabilmişlerdi. Takımda öne çıkan oyuncu, Almanların gelmiş geçmiş en iyi futbolcusu diye adlandırabileceğimiz Franz Beckenbauer.

Bir sonraki takımımız ise Liverpool. 1975-84 seneleri arasında 4 kere o zamanın şampiyonlar ligi şampiyonu ve 7 defada kendi liglerinde şampiyon olmayı başarmıştı. Çok iyi pas trafiği yapmalarına ve oyun akışını iyi kontrol etmelerine rağmen, başarılarının sırrı çok iyi olan savunmalarında yatıyordu. Hatta defanslarına, istatiksel olarak baktığımızda Ingiltere futbol ligi tarihinin en iyi defansı denebilir. Liverpool bu senelerde takım halinde iyi savunma yapıyordu, öne çıkan futbolcuları yok demek yanlış olmaz.

Ezeli rakibi Real Madrid’te 1953 ile 1960 yılları arasında gerçekten de bir çok başarının altına imza atmıştı. O zamanın şampiyonlar ligi kupasını tam 5 kere kaldırmışlardı. Öyleki Real Madrid hakkındaki tek yorum, bu futbolcular insan olamazdı. Takımın şüphesiz en iyi oyuncusu olan Alfredo Di Stefano, bütün zamanların en iyi futbolcuları arasında gösterilmektedir.

Bir zamanların efsane takımı Ajax ise Barcelona’ya en büyük rakiplerden biri gibi görünüyor. Ajax 1965 ile 1973 yılları arasında her kupayı kazandı. Bu kupaların arasında 3 kere o zamanın şampiyonlar ligi kupası var. Ajax takımhalinde müthiş bir akıcılık içerisinde futbol oynuyordu. Ajax’ın bu dönemdeki futboluna total futbol denildi ve kelimenin tam anlamıyla bir ekol haline geldiler. Gerçekten de bu dönem Ajax’ın ve Hollanda futbolunun çağıydı. Ajax’ın bu dönemdeki en iyi futbolcusu Johan Cruyff’tu. Bu dönemde, Cruyff 3 defa en iyi futbolcu(FIFA Ballon d’Or) ödülünü kazanmıştır.

Şimdi sıra Barcelona’da. Barselona’yı aslında daha iyi inceleyebilmek için bir 5-10 seneye ihtiyacımız var. Rakiplerinin hepsi uzun yıllar istikrarını sürdürebilmiş. Biz de Barcelona’yı değerlendirmek için beklemeliyiz. Hali hazırda, rüya takım olma yolunda ise emin adımlarla yürüyor. Futbolcu bazında baktığımızda, kaleci ve sol bek hariç , her biri mevkilerinde en iyi futbolcular. Takdir edersiniz ki, futbolcu kalitesi takımı başarıya götürebilecek en önemli etkenlerden biri. Futbolcuların kalitesinin yanı sıra, takım olarak da iyi bir görünümdeler. Bütün bunları düşündüğümüzde, Barselonanın rüya takım olma ihtimali çok yüksek.

Şu anki barselona ile saydığımız diğer takımları karşılaştıracak olursak, Barselona’nın rakiplerinden hiçte alta kalır yanı olmadığını görebiliriz. Bence en önemli rakibi olan Ajax ile hemen hemen aynı seviyede diyebiliriz. Çünkü, Ajax’ın oynadığı total futbolu Barselona’da gözlemleyebiliyoruz. Rakip kim olursa olsun, topa sahip olum hücumu düşünen bu anlayış hem göze hitap ediyor, hem de iyi sonuçlar veriyor. Barselona istikrarı yakalarsa, rüya takım olucaktır.

Yazımın başında size Mourinho’yu kısaca tanıtmak istiyorum. Jose Mourinho, 26 Ocak 1963’te Portekiz’in Setubal şehrinde doğdu.  Baby Robson’ın yanında çevirmen olarak başladıktan sonra, kariyerine Barcelona’da devam etti. Burada da futbolcular ile teknik direktörler arasında çevirmenlik yaptı. Daha sonraları Louis Van Gaal’in isteği üzerine Barcelona B’nin teknik direktörlüğüne getirildi. Ayrıca bir kaç maçtada Mourinho’dan yardımcı teknik direktör olarak yararlandı. Mourinho ilk olarak Benfica’da teknik direktörlük görevine getirildi. Burada yaşadığı başarıdan sonra Porto’nun ilgilisini çekti ve Porto’nun teknik patronu oldu. 2003 yılına gelindiğinde, ligde şampiyon olup ueafa kupasınıda kaldırmıştı. Bir sonraki yıl ise şampiyonlar ligi şampiyonu olarak dikkatleri üzerine topladı. Roman Abramovich’in isteği üzerine Chealsea ile el sıkıştı. Ciddi bir transfer bütçesiyle, Didier Drogba, Michael Essien, Ricardo Carvallo gibi önde gelen isimleri kadrosuna kattı. İlk senede ligde şampiyon olup, şampiyonlar liginde de yarı finale kalma başarısını gösterdi. Chealsea’de kaldığı süre boyunca bir çok başarıyı kucakladı. 2008’de Inter’in teknik direktörü olmayı kabul etti. İlk senesinde çok büyük başarılar bekleyen taraftarlara, isteneni kısmende olsa veremedi. İkinci senesinde bir çok transfere imza attı. Ibrahimovic ve Wesley Snejder gibi dünyanın sayılı futbolcularını kadrosuna kattı. 2009-2010 sezonun neredeyse her kupayı müzesine götürme başarısını yaşadı. 2010 yılında Real Madrid  teknik direktörlüğüne getirildi.

Mourninho şimdilerde dünya tarihindeki en iyi teknik direktörleri arasında gösteriliyor. Takma adı olarakta “The Special One” özel biri adıyla anılıyor. Mourinho şimdiye kadar çıktığı maçların 68% yenme oranıyla gerçekten de çok başarılı bir teknik direktör olduğunu gözler önüne seriyor. Kariyerindeki başarılı olmasında en büyük nedenlerden birinin İspanyolca, İngilizce, İtalyanca gibi bir çok dile hakim olmasının önemli bir yer tuttuğunun altını çiziyor. Genel olarak agresif çıkışları ve yüksek egosuyla gündeme gelen Mou, oldukça hazır cevap olduğunu her fırsatta eleştirmenlere gösteriyor.

Mou’yu bu kadar tanıttıktan sonra, neden iyi olduğunu kendimce yorumlamak istiyorum. Bir takımı takım yapan oyuncularıdır. Mourinho yaptığı transferle ile kendisin futbolcuları analiz etmekteki becerisini kantılıyor. Bunlara bir çok örnek vermek mümkün, mesela Mesut Özil, Essien, Drogba, Deco ve daha niceleri. Bu oyuncular bulundukları takımlarda gerçekten iyiydiler ama onların birer yıldız olduğunun farkına varmak herkesin harcı değil. Zaten, yıldızları bir arada oynatabilmekte önemli bir yeti. Mou, ayrıca taktik ve teknik olarak gerçektende çok yetenekli. Bir çok farklı ligde bir çok takımda teknik direktörlük yapıp hepsinde de başarılı oldu. Bu takımlarda uyguladığı taktikler ise birbirinden farklıydı çünkü takım için ideali bulmayı biliyordu. Bu onun taktik bilgisini ve oyuncuları uygulanan taktiğe alıştırma becerisini gösterir. Ayrıca Mou, saha içinde de yaptığı yerinde değişikliklerle de oyun içinde maça hakim olabilmekte, müdahaleleri ile maç çevirip, maç kazanmayı en iyi şekilde başarabilmekte. Dahası Mourinho, büyük maçların adamı. Karşısındaki teknik adamı oynattığı oyun sitili ile ters köşe yapmakta üstüne yok. Bir bakarsınız savunma oyuncusu hücum hattında pres yaptığını görürsünüz yada bir hücum oyuncusu savunmaya olabildiğince yakın oynattığına şahit olursunuz. Mourinho, futbolcularını maça hazırlama ve onlara kazanma hırsını aşılamakta da mükemmel. Cristiano Ronaldo’ya bile pres yaptırabiliyorsa yada takım ruhuyla oynamayı az da olsa öğretebiliyorsa, gerçektende ikna kabiliyeti olarak ve oyuncu yönetme becerisi olarak Mou’yu yüceltmek yersiz olmasa gerek. Son olarak Mou çok istikrarlı bir teknik adam olduğunu yaptığı maçlara ve istatistiklere bakarak görebiliriz. Barcelona belkide gelmiş geçmiş en iyi futbolu oynarken, Real Madrid’te çok büyük işler yaptı;  yapmaya da devam edeceğine eminim.

Yazımın son kısmında olaylara başka bir açıdan bakalım. Ya Mourinho Barcelona’nın başında olsaydı. Eğlenceli bir takım olacağına ve  gücüne güç katacağına kesinlikle eminim. Aslında bildiğimiz gibi Barcelona’ya çok da yabancı değil Mou,  belkide bir gün Barçanın teknik direktörlüğünü yapar. Barcelona’ya katacaklarına gelirsek, bir kere çok iyi transferler yapacağı aşikar. Sonuçta Barcelona bütçesi Madrid’in kadar olmasada, çok da aşağı kalır yanı olduğunu düşünmüyorum. Barçada hali hazırda gayet işleyen bir taktik var bunu belki biraz daha geliştirilebilir ama maçların akışına çok iyi müdahalelerde bulunacaktır. Son olarak, futbolcular zaten hazır durumda ama onlara daha fazlasını verebilirsiniz, bu noktada Mou ciddi anlamda iş görecektir. Kimbilir, belki bir gün Barça’nın teknik adamı olur

Yazımı güncellemek istedim çünkü bir önceki paragrafta Mourinho’nun Barcelona’nın başında olması ile ilgili yazdıklarımı geri alıyorum. Bu kadar ahlaksız bir şekilde futbol oynatan bir adamı Barcelona camiasının hiçbiryerinde olmaması gerektiğini düşünüyorum. Kendi futbol ahlakıda ciddi derece sorgulanmalı. Hem verdiği demeçlerle, hem de yaptığı hareketlerle futbolu katlediyor. Evet Mourinho Barcelona’nın hiç bir yerinde olmamalı.