Fiori İçin Kod Kopyalamak

Fiori danışmanı bir arkadaşım, gittiği bir projede yaşadığı durumu anlattı.

Klasik ABAP ile yazılmış karmaşık bazı programları, Fiori ile Web ortamına açmaları gerekmiş. Proje yöneticisi, “Çalışan programa dokunmayın” yaklaşımıyla; programlardaki kodları kopyala & yapıştır ile çoğaltarak RFC fonksiyonlarına çevirtmeye başlamış.

Bu hikayede o kadar çok kırmızı alarm var ki, nereden başlayacağımı bilemiyorum.

Öncelikle; en baştan Object Oriented ABAP kullanılsaydı ve en basit Design Pattern olan MVC uygulansaydı, söz konusu programların motor kısmı birer sınıf haline gelmiş olacaktı. Bu sınıfları, (ideal durumda) noktasına bile dokunmadan RFC’lerin içine dahil etmek ve Fiori ekranlarında kullanılmasını sağlamak mümkün olacaktı.

Hikayedeki durumda; uygulama mantığı SE38’e hapsedildiği için, yeniden kullanılamaz hale gelmiştir.

Fiori projesi başladığında, ilk iş olarak mevcut programların önce Object Oriented hale getirilmesi, akabinde Fiori işine geçilmesi mimari açıdan daha doğru bir yaklaşım olacaktı. Ancak; muhtemelen zaman / maliyet / “çalışıyorsa dokunma” yaklaşımından ötürü, kodların kopyalanması yaklaşımı seçilmiş.

Bu yaklaşım günü kurtarıyormuş gibi gözükse de; uzun vadede uygulama mantığında herhangi bir değişiklik olduğunda iki tarafa birden (SE38 / Fiori) müdahale edilmesi gerekecek. Bu da iki katı destek maliyeti demek. İki müdahale arasında ABAP’çı hatasından ötürü fark çıkması durumunda, kullanıcılar “SAP GUI’den şöyle, Fiori’den böyle çalışıyor” gibi trajik hatalarla uğraşmak zorunda kalacak; bu da emek israfına yol açacaktır.

Dün Web Dynpro vardı, bugün Fiori var, yarın bambaşka bir teknoloji daha çıkabilir. O zaman o yeni teknoloji için kodlar tekrar mı kopyalanacak? Halbuki elde Object Oriented bir ABAP kütüphanesi olsa, aynı motor ileride yeni teknoloji için de tekrar kullanılabilecektir.

Görüldüğü üzere; geliştirmelerde Object Oriented ABAP kullanılmaması ve Design Pattern bilen tecrübeli bir mimarın bulunmaması, şirketlere uzun vadede gereksiz yere çok büyük maliyetler çıkarabiliyor.

Bu maliyetleri önleyebilecek birkaç örnek Pattern vermek gerekirse;

• MVC: Uygulamanın motor kısmıyla kullanıcı arayüzünü tamamen izole etmeyi sağlar. Böylece yeni bir arayüz geldiğinde, motor olduğu gibi tekrar kullanılabilir.
• Data Access Object: Farklı veri kaynakları söz konusu olduğunda, veri okuma mantığıyla iş mantığını izole ederek kod tekrarını önler.
• Strategy: Aynı girdi – çıktıya sahip alternatif algoritmalar söz konusu olduğunda, bu algoritmaların izole Z’li sınıflar içerisinde yazılmasına olanak sağlar. Bir sınıftaki olası hata diğer sınıfları etkilemez, ve Z’li algoritmalar canlıya birbirinden bağımsız olarak atılabilir.
• Chain of Responsibility: Onay stratejisine benzer kuralların öncelik mantığında uygulanmasını sağlar. Her bir kural bir Z’li sınıf ile ifade bulduğundan, tak-çıkar mantığında yeni Z’li kodlar eklenebilir ve birbirinden izole olarak canlıya atılabilir.
• Multiton: Aynı anahtara ait nesnelerin tekrar tekrar okunmasını önleyerek, hafıza ve performans iyileştirmesi sağlar.
• Decorator: Aynı veri üzerinde birden fazla değişiklik yapılması gerektiği durumlarda kullanılır. Bu değişikliklerin tamamını ana programa veya merkezi bir sınıfa kodlamak yerine; tak-çıkar mantığındaki mikro sınıflara kodlama prensibine dayanır.

Daha fazlası için, Design Patterns in ABAP Objects adlı kitabıma göz atabilirsiniz.

Design Pattern’lerin faydalarının farkında olup, mimari rolün ABAP’çı / modülcü arasında erimesine göz yummayan firmalar da var tabii. Bu yaklaşımın Türkiye’de de endüstri standardı haline gelmesi dileğiyle…

Advertisement