Mimarinin Evrimi -3. Yeniden Düzenleme ya da Yeniden Yazma

Prag

Bir önceki yazıda “Teknik borç nasıl ödenir?” sorusuna cevap aramış ve yeniden düzenleme ile teknik borcun ödeneceğinden bahsetmiştik. Yeniden düzenleme kod seviyesinde olabileceği gibi mimari seviye de olabilmektedir.

Proje başında yeterince yeterince kalite öz niteliği analizi yapılmamış ise örneğin güvenlik ile ilgili ihtiyaçlar analiz edilmeden geliştirme yapıldı ise bu ileri ki aşamalarında bunu teknik borç olarak karşımıza çıkacaktır. Diğer bir durumda siz her ne kadar projenin başında en ideal tasarımı yapmış olsanız da projenin ileri ki aşamalarında takvim sıkışıklığı, yazılımcı değişikliği gibi faktörler ile mimari kararlar doğru şekilde yazılıma aktarılmaz ya da mevcut bir özellik istenmeden bozulur. Mimari Erozyon dediğimiz bu durumda da teknik borç oluşmaktadır. Son olarak teknolojilerin gelişmesi, kullanılan kütüphanelerin eskimesi, kullanılan donanımın artık üretilmemesi gibi sebeplerle de teknik yeniden düzenleme gerekebilmektedir.

Kod teknik borçları genelde sonar qube, cppcheck gibi araçlar ile ya da kod eşdeğer gözden geçirmesi ile tespit edilir ve paket, sınıf ya da yordam seviyesinde çözümlenir. Kod yeniden düzenlemede bileşenlerin yapısı ve birbiri ile ilişkilerine dokunulmaz.

Mimari yeniden düzenlemede ise amaç sistemin değiştirilebilirlik, performans, test edilebilirlik, değiştire bilirlik,bakım yapılabilirlik ve süreklilik gibi kalite öz niteliklerini iyileştirmek olacaktır.

Mimari yeniden düzenleme,

• Bileşenler arası bağımlılıkları kırma,
• Yeni bileşen ayıklama,
• İhlal edilmiş mimari prensipleri yeniden uygulama,
• Görev (thread) yapısını iyileştirme,
• Eskiyen bir teknolojiyi yeni teknoloji ile değiştirme,
• Kullanılan bir kütüphanenin yeni versiyonuna geçme,
• Güvenlik ile ilgili kabiliyetler ekleme,
• Loglama altyapısını iyileştirme ve tüm bileşenlerde aynı prensiplerle uygulama,
• Standartlara uyum amacı ile veri modeli ve iletişim arayüzünü değiştirme,
• Maddi olarak külfetli olan 3. parti kütüphane ve teknolojilerden kurtulma,

gibi teknik işleri içerir.

Günümüzde birçok firma mevcut ürünün daha modern, daha yönetilebilir olduğu için mikro servis mimarisine geçiriyor. Kimi firma mevcut sistemi aşama aşama yeniden düzenleyerek mikro servis mimarisine geçiş sağlıyor. Kimisi ise mevcut yapıyı terk edip yeniden geliştirme ile mikro servise geçiş sağlıyor. Martin Fowler yeniden düzenleme ile aşamalı bir şekilde geçişi öneriyor. “Büyük patlama şeklinde yeniden yazma bir büyük patlamaya sebep olur” şeklinde vecize ile konuyu anlatmış. Yapısı itibari ile geçiş bir mimari yeniden düzenleme yaklaşımıdır.

Mikro servis mimarisine geçişte önerilen yaklaşımlar aşağıda sıralanmıştır:

1. Yeni servisler:Yeni geliştirilecek kabiliyeti mikro servis olarak geliştirip mevcut mimari ile entegrasyonunu sağlamasını temel alır. Bu şekilde ekip mevcut yazılımı en az riske atarak aşamalı olarak geçiş yapar. Bu şekilde teknoloji ve yeni yapılara aşinalık kazanılır.
2. Kullanıcı arayüzü ile uygulama bileşenlerini ayırma: Bu yaklaşımda öncelikle kullanıcı arayüzü ile algoritmaları ayırmayı temel alır. Bu iki bileşen arasında REST vb. iletişim kurulur. Bu kalıcı değil ara bir çözüm olarak karşımıza çıkar.
3. Ayıklama: Mevcut bütünleşik mimaride mikro servis olmaya aday bir iş alanını mikro servis olarak geliştirme ve onu mevcut yazılımlarla birlikte çalıştırma yöntemidir. Aşama aşama bütünleşik eski mimarideki yazılım mikro servise geçecektir.

Yeniden Düzenleme Nasıl Yürütülür

Bu faaliyet kod yeniden düzenlemede olduğu gibi sadece yerel bir bileşen içerisinde olmadığından analiz, tasarım, planlama, gerçekleştirme ve test gibi temel süreçleri içerir.

Analiz

Mimari yeniden düzenleme üstten aşağı (top down) yapılan bir çalışmadır. Bileşen bölümlenmesi, bileşenler arası arayüzler ve bağımlılıklar ile ilgilidir. mimari yeniden düzenleme yapmak için mevcut durumdaki hem teknolojiyi hem de iş alanını daha iyi bildiğimiz içi proje başındaki mimari kararları tekrar gözden geçirmeyi önerir.

Mevcut mimariyi iyice anlamak için üst seviye mimari çizimleri incelemek bu çizimler yok ya da güncel değil ise yeniden çizmek gerekir. Bileşenler arası bağımlılık matrisi yapmak ta önerilen bir yaklaşımdır. Böylelikle sistemi ve neleri değiştirmen gerektiği daha kolay anlaşılır

Planlama

Yazılım mimarisi eğitiminin ilk dersinde mimariyi tanımlarken değiştirilmesi zor kararları içerir demiştik. Bu durumda yeniden düzenleme faaliyetinin de belli bir zorluk getireceği baştan kabullenilmeli ve mümkünse devrimsel değil evrimsel bir yaklaşımla yeniden düzenlemeler tekrarlı olarak yapılmalıdır.

Hangi mimari değişiklikleri yapacağına karar ver. Teknik ve bütçesel limitleri dikkate alarak hangi iyileştirmelerin yapılacağına karar ver. Yatırımın getirisini ölçülebilir metrikler ile belirle. Eğer yeniden düzenleme çok fazla ise geçiş planlaması yap. Yeniden düzenleme çalışmasını çok kişiye yayma.

Mimari yeniden düzenlemeyi döngüler biçiminde planla. Senaryo yaklaşımına göre yazılımın mevcut durumu ve her döngüde geçireceği evrimleri planla. Döngünün amacını belirle. O tekrarda elde edeceğin faydayı belirle,

Her seferinde bir eski bileşenleri yenisi ile değiştirmeyi temel alınabilir. Bu yaklaşımda yeniden düzenlenen bileşene diğer bileşenlerin adaptasyonu sağlanır.

Adaptasyon yaklaşımında ise ilgili modülü tamamen yeniden yazma yerine yeniden düzenlemeyi içerir. Bu yaklaşımla ilgili bileşeni kullanan diğerlerinin değişmesi gerekmez.

Mimari yeniden düzenlemeye karar verdikten sonra bunun üst yönetime sunumunu yap. Mevcut yazılımın neden hatalı olduğunu tartışacağına yeni çözümün faydalarını ve bu yeniden düzenlemeden alacağı faydaları öne çıkart. Asla mevcut mimari çok kötü deme! Amacınız ürünü iyileştirmek yapılanı eleştirip kendinizi ön plana çıkartmak olmamalı. Her yazılım tasarımının oluşturulduğu zamandaki kısıtlamalar, bilgi birikimi ve teknik olanaklar ile oluşturulduğunu unutma.

Gerçekleştirme

Mimari yeniden düzenleme tecrübe gerektiren bir faaliyettir. Geliştiriciler yapılacak değişikliği ve sistem mimarisini iyice anlamalıdır. Yazılım mimarı takım ile toplantı yaparak yeniden düzenlemenin amacını ve hassas noktalarını ortaya koymalı. İşin başında en son erişilmesi planlanan mimari ile ilgili vizyon ortaya açık şekilde konulmalı.

Bu yeniden düzenlemeyi yaparken diğer kalite öznitelikleri gereksinimlerini kıramadığından emin ol. Örneğin değiştirilebilirliği arttırmak için alt bileşenlere böldüğünde sistemden beklenen performansı hala karşıladığından ve güvenlik ile ilgili açık vermediğinden emin ol.

Yeniden düzenleme de en etkili silahlardan biriside tekrarlı koşulabilir testlerdir. Bu testler ile yeniden düzenleme sonrası mevcut özelliklerin korunduğu garanti edilebilir.

Yeniden düzenleme ile birlikte tasarım dokümanını güncellemeyi unutma.

Yeniden Geliştirme

Firmalar bazen mevcut yazılımı yeniden düzenleme ile iyileştirmektense oturup yeniden yazmayı tercih edebiliyor. Bu eğer mevcut mimari düzeltilemeyecek kadar karmaşık hale gelmişse (teknik iflas) bu durumda yeniden geliştirme anlamlı olabilmektedir. Benzer şekilde yazılımın teknolojisi ve bağımlı olan kütüphaneler ve donanımlar artık desteklenmiyor ve bize büyük yük oluşturuyor ise yeniden yazma anlamlı olacaktır.

Yeniden yazmak eğer bir önceki yazılımdan alan bilgisini yeni projeye kolayca aktarabilecek isek, bir önceki projede öğrenilen dersleri dikkate alıyor isek anlamlı olabilmektedir. Bir önceki projede teknolojiyi iyi bilmediğimiz için ideal mimariyi oluşturamadığımızı varsayalım. Yeniden geliştirmeye karar verdiğimizde önümüzde olan çekici ve yeni moda teknolojileri ne kadar iyi biliyoruz ve bunlar bizim iş alanımızın problemlerini çözme konusunda ne kadar başarılı olacak bu konuda emin olmamız gerekiyor. Bütün dünya bu teknolojileri kullanıyor o zaman bu iyi bir şey olmalı somut bir cevap değildir. Benzer şekilde bir önceki mimarideki kalite öznitelikleri gereksinimlerini yeterince iyi biliyor ve yeni mimari ile bunları karşılıyor olmamız beklenir. Hatta daha önceki mimaride dikkate alınmamış yeni kalite öz niteliklerini dikkate almak ve çözüm üretmek başarı şansımızı arttıracaktır.

Yazılımcılar her zaman mevcut yazılımı anlayıp yeniden düzenleyeceklerine yeniden yazmayı tercih edeceklerdir. Fakat yeniden geliştirilen yazılımın bir önceki kadar teknik borcu olmayacağının garantisi nedir. Bu sefer daha kısıtlı zaman ve kaynakla aynı yazılımı tekrar geliştirmeniz beklenecektir.

Yeniden geliştirmede hedefimiz nedir. Mevcut özellikleri yeni programlama dili ve teknolojileri ile yeniden yazmak mı yoksa gelişen ihtiyaçlara göre daha kabiliyetli bir yazılım mı geliştirmek? Bu sorunun cevabı da yeniden geliştirme kararı sırasında cevaplanmalıdır.

Yeniden geliştirmenin riski çıkacak sonucun tam olarak bilinmemesidir. Yeniden yazma sonrası elde edeceğimiz ürünün başarısız olma riski nedir bunu analiz etmeliyiz. Yeniden geliştirme başarısız olursa ya da istenilen zamanda bitmez ise bir B planımız olmalı. Belki paralelde eski sistem sadece kritik problemleri çözülerek kullanmaya devam edilmeli.

Ayrıca yeniden geliştirilen ürünün kullanıma sunulduğunda olgunlaşması ve hatalarının düzeltilmesi için geçecek döneme hazırlıklı olmalıyız. Üst yönetim ve müşteriler bu sürecin bilincinde olmalı ve buna hazırlıklı olmalarıdır.