Diğer tasarım prensipleri için “Tasarım Prensipleri” bölümüne bakınız.

EOF (End Of Fun)
Özcan Acar

Danışman, teknik ekip lideri ve programcı olarak çalışmış olduğum bu 10 aylık zaman diliminde, Corebanking projesindeki faaliyet alanlarım şu şekilde oldu:

• Test güdümlü yazılımın proje genelinde kullanımı
• Continuous Integration ve Continuous Deployment gibi çevik metotların projeye entegrasyonu
• Yazılım sürecinin iterasyon bazlı organizasyonu (Extreme Programming)
• Build işlemlerinin otomatize edilmesi (Ant,Maven)
• Lokal yazılım geliştirme işlemi için Websphere uygulama sunucusunun devre dışı bırakılması ve uygulama sunucusu kullanmak zorunda kalmadan test güdümlü yazılım yapılabilmesi
• Lokal testler için gerekli referans verilerinin cachelenmesi ve uygulama sunucusunun start-up zamanının optimize edilmesi
• Veri tabanı üzerindeki yükü azaltmak için proje genelinde bir caching mekanizmasinin implementasyonu (hazelcast)
• Maven kullanılarak tüm Corebanking projesinin modüler bir yapıya geçirilmesi
• Nexus kurulumu ve otomatik dependency yönetimi
• Performans analizi ve logmalası için AOP (Aspect Oriented Programming) kullanımı
• Performans testlerini yapılması ve performans testlerinde ortaya çıkan problemlerin lokalizasyonu ve eliminasyonu
• Ekibin çevik süreç, çevik metotlar ve tasarım prensipleri konusunda eğitimi
• Code ve architecture review
• Açık sistemler ile Mainframe arasındaki komunikasyonu sağlamak için REST tabanlı bir mimarinin oluşturulması (JBoss EasyREST)

İlk çalışma alanlarımdan birisi build ve deployment işlemlerini otomatize etmek oldu. Bunun için gerekli Ant skriptleri oluşturdum ve build işlemlerinin merkezi bir yerden tetiklenmesini sağladım.

Bir proje bünyesinde kodun sürekli entegre edilmesi (Continuous Integration) önemli ve gerekli bir işlemdir. Bu şekilde entegrasyon problemlerini zamanında lokalize etmek mümkündür. Bu amaçla Corebanking projesi için Cruise Control kullanarak bir sürekli entegrasyon serveri oluşturdum. Bu server programcıların yaptığı her commit sonunda otomatik olarak tüm kodu Clear Case’den alarak derliyor ve mevcut testleri kosturuyor. Altta yer alan resimlerde de görüldüğü gibi bir build monitörü kullanarak, projelerin entegrasyon işlemlerinin ne durumda olduğunu takip etmemiz mümkün. Herhangi bir kırılma olması durumunda gerekli programcılar email aracılığı ile uyarılıyor. Bunun yanısıra entegrasyon monitörü herkesin gözü önünde olduğundan, entegrasyon sürecinin hangi safhada olduğunu görmek her zaman mümkün.

Diğer bir faaliyet alanım performans testleri esnasında performans ölçümünde kullanılabilecek metriklerin oluşturulması idi. Bu amaçla AspectJ (Java’da Aspect Oriented Programming yapmak için kullanılan bir framework) kullanarak perfomans aspektleri oluşturdum. Bu aspektleri kullanılan teknolojiye göre (Webservice, Rest, JDBC) metot bazında işlem tamamlama süresini ölçecek şekilde programladım. Tüm proje bu aspektler kullanılarak derlendikten sonra, kod bazında bir değişiklik yapmak zorunda kalmadan, işlem tamamlama sürelerini ölçmek mümkün oldu.

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect("perthis(execution(public * com.kurumsaljava.core.restapi.*Resource.*(..)))")
public class RestPerformanceMonitor extends  AbstractPerformanceMonitor
{
    @Before("execution(public * com.kurumsaljava.restapi.*Resource.*(..))")
    public void before()
    {
    	startMonitor();
    }

    @After("execution(public * com.kurumsaljava.restapi.*Resource.*(..))")
    public void after()
    {
    	stopMonitor("[performance:rest]");
    }
}

Çevik süreçleri kullanarak iterasyon bazlı proje yönetimi yapabilmek için kullanıcı hikayelerinin (user story) oluşturulması gerekiyor. Corebanking bünyesindeki bir projenin yazılım sürecini hikaye kartları (story card) kullanarak yapılandırdık. Hikaye kartları üzerinde kullanıcı hikayeleri yer aldı. Aşağıdaki resimlerde görüldüğü gibi çalışma alanımızın bir duvarını hikaye kartlarını barındıracak biçimde şekillendirdik.

Son dört aylık çalışmamın temelini, Corebanking projesinin daha modüler ve geliştirilebilir bir alt yapıya geçirilmesi işlemi oluşturdu. Corebanking uygulamaları, oluşturduğum ve Corebanking Next Generation (CBNG) ismini verdiğim bu yeni alt yapı ile şimdi İşbankasi’nın production sistemlerinde deploy ediliyor.

Neden CBNG’ye gerek duyulduğunu sizlere kısaca aktarmak istiyorum. Başlangıçta tek bir uygulama olarak yola çıkan Corebanking projesi, zaman içinde büyüyerek, bünyesinde üç ve daha fazla uygulama barındırmaya başlamış. Prensipte birbirlerinden bağımsız olan bu projeler ne yazık ki aynı kod köklerine sahip olduklarından, birbirlerinden bağımsız olarak deploy edilmeleri mümkün olmuyordu. Yaşadığımız en büyük sorun, hazır olmayan ve test edilmemiş kodun, Corebanking bünyesindeki herhangi bir uygulamanın test ya da production sistemlerine çıkmayı istemesi durumunda, bu projeyle beraber gitmek zorunda olmasıydı, çünkü tüm Corebanking uygulamaları bir EAR dosyası olarak deploy ediliyordu. Bir başka sorun ise, proje yöneticilerinin sürekli kendi test ya da production çıkışlarını diğer projelerle koordine etmek zorunda olmaları idi. Bu şartlar altında yeni Corebanking uygulamalarının geliştirilmesi, yani binanın üzerinde yeni katlar çıkılması imkansız bir hal alıyordu.

Buradan yola çıkarak mimari ekip / teknik lider toplantılari bünyesinde Corebanking Next Generation alt yapısına geçiş fikri oluştu ve kısa bir zaman sonra bu yeni alt yapıyı oluşturmak için çalışmalara başladım.

Prensip olarak yeni alt yapının “Programming in the large” modeline göre tasarlanması gerekiyordu. Bu modele göre proje bünyesindeki birçok alt proje, ufak ekipler tarafından, birbirlerini etkilemeden, versiyonlanmış modüler ve komponentler kullanılarak geliştirilebilir hale geliyor.

Yeni alt yapı büyük bir gökdelen inşa etmek yerine, bir site oluşturarak, bu site içerisinde 2-3 katlı villalar kurulmasına izin veriyor. Her bir villayı bir proje olarak düşünürsek, ekipler birbirlerinden bağımsız olarak kendi villalarını oluşturabiliyorlar.

Kulağa hoş gelen bu model, ne yazik ki 2 senelik bir kod tabanına sahip bir projeden yola çıkıldığında uygulaması çok zor bir hal alabilir. Karşılaştığım en büyük problemlerden birisi, her proje tarafından kullanılan ortak sınıfların lokalize edilmesi ve her proje tarafından kullanılabilir bir modül haline getirilmesi oldu. Bunun yanısıra sınıflar arasında sirküler bağımlılıkların (circular dependency) olması, ortak kullanılabilir modüllerin ortaya çıkmasını zorlayan bir durumdu. Yer yer DRY (Do not repear yourself) prensibine uyulmadığı için aynı özellikleri taşıyan sınıfların birden fazla lokasyonda bulunması ve konsolide edilmesi karşılaştığım diğer bir sorundu.

İşe mevcut tüm projeleri Maven projesi olacak şekilde yeniden yapılandırarak başladım. Daha sonra Corebanking bünyesindeki en ufak çaplı projeyi seçerek, bu projeyi yeni modele uygun şekilde yeniden yapılandırdım. Bu esnada diğer projelerinde kullanabileceği ortak modüller şekillenmeye başladı. Bu şekilde adım adım ilerleyerek ilk Corebanking uygulamasını CBNG konform hale getirdim. Bu işlemin ardından projenin tüm testlerini (1000 üzerinde acceptance testleri) koşturarak, yeni yapıyı test ettik. Testler yüzde yüz çalışır hale gelinceye kadar yeni alt yapıyı rekonfigüre ettim. Bu işlemler tamamlandıktan sonra yeni alt yapıyı programcı ekibe teslim ettim. Bu şekilde yeni alt yapı sahada yayılmaya başladı. Bu noktadan itibaren iki Corebanking uygulaması, eski ve yeni dünya olarak paralel yaşamaya başladı. Tüm projeyi durdurup, 1-2 ay yeni alt yapıyı oluşturmak için ayıramayacağımız için bu şekilde bir seçim yapmak zorunda kaldık.

Kısa bir zaman sonra ilk CBNG uygulaması bir EAR dosyası olarak production sistemlerinde deploy edildi. Akabinde diğer bir Corebanking uygulamasını aynı şemayi takip ederek eski alt yapıdan yeni alt yapıya uyarladım ve sahada kullanılır hale gelmesini sağladım. Bu sürecin sonunda Corebanking tamemen transform edilmiş ve CBNG olarak hayatını sürdürmeye devam ediyor olacak. Bu gerçekleşene kadar eski ve yeni alt yapı iki değişik EAR olarak yanyana yaşamaya devam edecek.

Lokal repository olarak Nexus serverini kurdum. Bu server bünyesinde ortak kullanılan tüm modüller versiyonlanmış JAR dosyalar olarak yer aldı. Nexus ve Maven bağımlılıkların otomatik yönetimini ve kod birimlerinin ortak ve yeniden kullanımını sağlayan alt yapı komponentleri. Bu şekilde herhangi bir CBNG projesi ihtiyaç duydugu bir modülü Nexus‘dan temin edebilir. Aynı şekilde bu proje diğer projelere sunmak istediği modülleri versiyonlanmış bir Jar dosyası olarak Nexus bünyesine katabilir.

Benim için şüphesiz en heyecan verici faaliyet alanı CBNG oldu. Geliştirme plarformu olarak kullandığımız RAD 7 (Eclipse 3.2) mümkün olan tüm engelleri ortaya koyarak, yaptığım işin hergün heyecan verici kalmasını sağladı En büyük sorunlardan birisi RAD‘ın eski bir Eclipse versiyonu olduğu için M2Eclipse pluginini aktüel versiyonunda kullanamıyor olmamdı. Eski ve birçok bugı olan bir M2Eclipse plugin versiyonu ile çalışmanın ne kadar ve heyecan verici olabileceğini düsünebilirsiniz Oluşan birçok problem için birçok workaround bulmak zorunda kaldım. Bu kadar sorunla karşılaşacağımı önceden biliyor olsaydım, acaba CBNG‘yi hayata geçirmeye kalkarmıydım? Beni tanıyanlar bu sorunu cevabını biliyor

Corebanking Next Generation (CBNG) hakkında yazabileceğim sayfalar dolusu anılarım var. Lakin banka bünyesinde olup bitenleri çok detaylı bir şekilde anlatmak doğru olmaz. Danışman ya da banka çalısanı olarak dikkat etmemiz gereken en önemli konulardan birisi, gizlilik prensibine uymaktır.

Corebanking projesi bünyesinde birçok yetenekli programcıyla çalışma fırsatı buldum. Bilgi alışverişine açık bir ortamda çalışmak gerçekten çok zevk vericiydi. Bu programcı arkadaşlara bu vesile ile buradan kucak dolusu selam ve sevgilerimi gönderiyorum.

EOF ( End of Fun)

Özcan Acar

Özcan Acar

Sunum dosyasını PDF olarak aşağıdaki linkten edinebilirsiniz.
Note: There is a file embedded within this post, please visit this post to download the file.

EOF (End Of Fun)
Özcan Acar

Özcan Acar

Sunum dosyasını PDF olarak aşağıdaki linkten edinebilirsiniz.
Note: There is a file embedded within this post, please visit this post to download the file.

EOF (End Of Fun)
Özcan Acar

Detaylar için bakınız >>

Bir Java Champion nedir? Bu konu hakkında detaylı bilgiyi Java Champion websayfasından edinebilirsiniz. Java Champion Sun tarafından hayata geçirilmiş ve desteklenen bir proje. Java Championlar Sun tarafından seçilmemektedir. Java Champion adayları, mevcut Java Championların kendi aralarında yaptıkları oylama sonucunda bu ünvanı kazanırlar. Java Championlar Sun firmasından bağımsız olarak çalışan, Java platformunun gelişmesine katkıda bulunan yazar, eğitmen, senior mimar ve yazılımcılardır.

Resim 1

Resim 1 de resmi Java Champion websayfasında konu hakkındaki haber yer almaktadır.

Yeni Java Championlar listesinde ismimi görebilirsiniz.

Özcan Acar
Java Champion

Aşağıda yer alan fotografları Devoxx’da çektim.

Resim 1

Resim 1 de Agile Mythbuster konulu sunumu yapan Scott Ambler yer almakta. Çevik süreçlerde oluşan bazı efsaneleri tematize eden bu sunumda Scott Ambler bazı efsanelerin nasıl oluştuğunu ve nasıl çürütüldüğünü istatistikler üzerinde dinleyicilere aktardı. En çok hoşuma giden efsane ise, çevik süreçlerde sertifikasyonun çok önemli olduğu idi. Scott Ambler’e göre 3 sene doktora yapmış bir şahıs ile 2 günlük bir seminer ardından sertifika almış bir şahısı aynı kefeye koymak çok mantık dışı Ben de kendisiyle aynı fikri paylaşıyorum. Sertifika peşinde koşmaktansa, konuyu derinlemesine araştırıp, anlamak ve uygulamak çok daha faydalı olacaktır.

Resim 2

Resim 3

Resim 4

Resim 4 de Architecting Robust Applications for Amazon EC2 konulu sunumu yapan Chris Richardson yer almakta. Chris Richardson POJO in Action konulu kitabın yazarı. Bu kitap yazılımcı kariyerimde beni en çok etkileyen kitaplardan birisidir. Chris Richardson ustayı Devoxx da dinleme firsatı bulmak benim için büyük bir şerefdi.

Resim 5

Resim 5 de Java’nın babası James Gosling ve ben yer alıyorum.

Resim 6

Resim 6 da programcılar için hazırlanan anketlerden birisi yer almakta. Resim 6 da yer alan ankette, programcılara kullandıkları yapılandırma (build tool) aracı sorulmuş. Çoğunluğu maven ve ant yapılandırma aracı oluşturmakta. Benim son zamanlardaki favorim maven.

Resim 7

Resim 7 de değişik ülkelerde faaliyet gösteren JUG (Java User Group) liderlerinin katıldığı toplantıdan bir resim yer almakta. Bu toplantıda JUG liderleri Java hakkındaki sorularını Java’nın babası James Gosling’e yönelttiler. Bu toplantıda bir çok JUG lideri ile tanışma firsatı buldum. Türkiye’de de bir JUG kurmanın zamanı geldi. Kısa bir zaman sonra JugTR.org adresinde Türkiye’nin ilk resmi JUG’u faaliyete geçecek. Bu konudakı çalışmalarım devam etmekte.

Resim 8

Resim 9

Resim 10

Resim 11

Resim 12

Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki etkilerini bir örnek üzerinde aktarmak istiyorum. TDD ile birlikte oluşan tasarım, kendiliğinden oluşan birşey değildir. Testler şekil aldıkça, oluşturmak istediğimiz tasarımın modeli de gözümüzde canlanmaya başlar. Oluşturduğumuz testler, programın gelecekteki kullanıcılarını (client) simule ettiği için, programın nasıl kullanılacağını testler bünyesinde gözlemlemek kolaylaşmaktadır. Bu süreç, sınıfların ve metotların kullanıcı gözüyle (client) tasarlanmasını sağlar. Bu sayede basit ve kullanışlı API (Application Programming Interface)’ler oluşur. Test güdümlü yazılım tasarımı devamlı zorlar ve yetersiz kaldığı yerlerde refactoring yöntemleriyle yenilenmesini sağlar. Bu süreç sayesinde kendisini devamlı yenileyen ve yeni gereksinimlere cevap veren bir tasarım oluşur.

Bu yazıyı PDF olarak edinebilirsiniz.

EOF (End of Fun)
Özcan Acar