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…

Author: Dr. Kerem Koseoglu

Mostly harmless

3 thoughts

  1. Kodlarin oo abap ile yazilmasi ya da hepsinin oo abap’a cevrilmesi de ayri bir maliyet.

    Bir kere butun kodu oo abap yazdiginizda o kodun duzeltilmesi gerektiginde yine oo bilen bir abapci bulmaniz gerekecek.
    Bu abapcilar ise piyasanin belki %0,1’i bile degil, oo alv kullanmayi saymazsak abapcilarin oo olayina mumkun oldugunca uzak durdugu bir gercek. Sdn forumundaki yabanci ornekler de bunu gosteriyor.

    oo tasarimin kendine ozgu bug’lari ya da daha dogru bir ifadeyle programin fonksiyonalitesinde cikan sorunlari (tabloyu update etmemesi, hafiza ve hiz sorunlari) cozmeniz icin sizi ya da sizin seviyede birini cagirmak gerekecek(%1? oran).
    Ya da daha once yapilan mvc tasarimini katledilecek bu da eski emegin cope atilmasi demek.
    Halbuki fonksiyonel yazdiginizda o hatalarla karsilasan milyon tane kisiden yardim alabiliyorsunuz.

    Diger yandan hala duzgun bir editor yok, se38’den yazip gecmek daha az efor gerektiriyor.
    Oo kavramina karsi degilim zaman zaman yaziyorum ama abap ortamiyla cok uyusmadigini dusunuyorum. Abap’i buna zorlamak C diline class method yazmak gibi geliyor.

    1. Korkarım söylediklerinizin çoğuna katılmıyorum.

      Kodların OO ABAP ile yazılması ek bir maliyet değil. OO ABAP bilmeyen biri daha uzun sürede yazdığı için ek maliyet olabilir, ancak bilen biri için geliştirmenin bitme süresi daha uzun değil kısa bile sürebiliyor. Bunu 16 yıllık proje tecrübeme dayanarak söylüyorum.

      Kodların OO ABAP’a çevrilmesi ek bir maliyet bu doğru. Ancak, bu yazıda kısmen anlattığım gelecek maliyetleri önlemesi adına anlamlı bir maliyet.

      OO ABAP bilen ABAP’çıların piyasanın %0.1 bile olmadığını söylemişsiniz, bir sonraki paragrafta da %1 demişsiniz. Bu istatistiklerin hangisi doğru, ve bu bilginin hangi araştırmaya dayandığını da paylaşır mısınız? Yoksa kendi kanaatinizi mi paylaştınız? Zira, sırf 2012’den beri mimarlık yaptığım projelere baktığımda, görüştüğüm kişilerin %30’unun benim kabul edeceğim ölçüde OO ABAP bilgisine sahip olduğunu söyleyebilirim. Bunu bilimsel bir istatistik olarak söylüyorum; kanaat olarak değil. Sizin yakın çevrenizde OO ABAP popüler olmayabilir, ancak kendi kanaatinizi piyasaya hemen genellemeyin diye tavsiye ediyorum.

      SDN forumlarına gelince… Forumlarda edindiğiniz izlenim, piyasanın gerçeğini ve olması gereken ideali mi yansıtıyor sizce gerçekten? Almanya’da bir sene çalıştım ve yeni geliştirmelerde OO ABAP’tan başka bir şey kullanıldığını görmedim. Yine Almanya ekseninde yaptığım iş görüşmelerinde de ön koşul olarak OO ABAP isteniyordu. SAP eski kodları da desteklemek zorunda olduğu için klasik ABAP yazılıyor ve paylaşılıyor olabilir, ancak yeni geliştirmelerde ek fayda getiren yeni yaklaşımları tercih etmek gerekir kanaatindeyim.

      Bir işin doğrusu dururken; “Çoğunluk eğri yapıyor” diye eğri mi yapmalı?

      Düzgün bir editör olmadığı, SE38’in daha kısa sürdüğü, ABAP ortamıyla uyuşmadığı ve zorlama olduğu gibi ifadeler, korkarım ki yine tamamen sizin kişisel kanaatlerinizden ibarettir; objektif gerçekler değil. Editör olarak Eclipse var, ben + tanıdığım pek çok ABAP’çı (Türk / yabancı) kullanıyor. Eclipse’e alıştığımdan beri SE38 / SE24 / SE37 gibi işlem kodlarına adım atmıyorum. ABAP ortamıyla da epey uyuşuyor, SAP’nin OO ABAP ile yazdığı standart kodlardan bunu görebilirsiniz.

      Eski alışkanlıkları sürdürmenin getirdiği rahatlığın ötesinde, yeni yaklaşımlara alışma sürecini göze alıp atlattığınızda; hem size hem de piyasaya daha faydalı olacak sonuçlar elde edilebilir, naçizane tavsiyem…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s