Yazılım dünyasında beş yıl, hem hâlâ gelişime çok iyi hazırlanmış bir sistemi hem de her geçen ay daha fazla maliyet çıkaracak teknolojik bir sorunu ifade edebilir.
Ancak bir uygulamanın yaşı tek başına onu değiştirmek için bir neden değildir.
Bu, en başta söylenmesi gereken en önemli şeylerden biridir.
Bir uygulamayı sıfırdan yeniden yazmak için evrensel bir eşik yoktur. Onlarca yıldır çalışan, hâlâ makul bir mimariye, güncel bağımlılıklara, iyi bir dokümantasyona ve kanıtlanmış bir dağıtım sürecine sahip sistemler vardır. Bunun yanında, kötü mimari kararlar, test eksikliği, kontrolsüz bağımlılıklar ya da art arda gelen hızlı düzeltmeler nedeniyle gelişimi zorlaşmış çok daha genç uygulamalar da vardır.
Dolayısıyla sorun yıl sayısı değildir.
Sorun, sistemin değişmeye devam edebilme kapasitesidir.
En önemli soru şu değildir: "Uygulama eski mi?"
Daha iyi soru şudur: "Bir sonraki değişiklik bize ne kadara mal oluyor?"
Yeni bir özellik eklemek giderek daha fazla saat, birkaç ekibi dahil etmeyi, manuel testleri ve eski mimarinin kısıtlarını aşmayı gerektiriyorsa, sistem yalnızca kodda görünmeyen bir maliyet üretmeye başlar.
Bu, artan technical debt'in pratik belirtilerinden biridir.
Technical debt, önceki teknik kararların sonucunda gelecekte yapılacak değişikliklerin maliyeti olarak anlaşılabilir. Martin Fowler bunu, sistemin iç kalitesi geliştirmeyi zorlaştırdığında, üzerinde yapılan ek çaba olarak tanımlar.
İşte bu yüzden bir uygulama hâlâ düzgün çalışırken, aynı zamanda geliştirilmesi giderek zorlaşabilir.
10 özellik sonra sistem tamamen farklı görünür
Bir projenin başlangıcı çoğu zaman basittir.
Bir MVP oluşturulur.
Sonra yeni gereksinimler gelir:
- CRM entegrasyonu,
- çevrimiçi ödemeler,
- yönetim paneli,
- mobil uygulama,
- yeni kullanıcı rolleri,
- raporlama,
- otomasyonlar,
- API,
- harici hizmetlerle entegrasyonlar,
- yeni dil sürümleri.
Her bir değişiklik tek başına haklı görülebilir.
Sorun, mimari böyle bir gelişim yönü düşünülerek tasarlanmamışsa ortaya çıkar.
O zaman sonraki özellikler artık stabil bir yapıya eklenmez.
Önceki istisnalara, geçici çözümlere ve ödünlere eklenir.
Bir sistemin yaşlanmaya başladığı nasıl anlaşılır?
Tam bir arızayı beklemeye gerek yoktur.
Uyarı işaretleri çok daha erken ortaya çıkar.
1. Yeni özellikler giderek daha uzun sürer
Eskiden bir özellik birkaç gün sürerdi. Bugün benzer bir değişiklik birkaç hafta gerektiriyor.
Bu, ekibin yavaşladığı anlamına gelmek zorunda değildir.
Mevcut sistemi anlamanın ve değişikliğin etkilerine karşı onu korumanın giderek daha fazla zaman aldığı anlamına gelebilir.
2. Her değişiklik domino etkisini tetikler
Bir modülde yapılan değişiklik birkaç başka yerde sorunlara yol açar.
Bu, bileşenlerin aşırı sıkı bağlandığını ya da aralarındaki sorumluluk sınırlarının yanlış tanımlandığını gösterir.
3. Testler çoğunlukla manueldir
Her büyük değişiklik onlarca özelliğin elle kontrol edilmesini gerektiriyorsa, dağıtım maliyeti artar.
Sorun otomasyonun olmaması değildir.
Sorun, bir değişikliğin bir şeyi bozup bozmadığına dair güvenilir bilgiyi hızlıca elde etme imkânının olmamasıdır.
4. Ekip, sistemin belirli parçalarına dokunmaktan korkar
Bu çok pratik bir göstergedir.
Eğer programcıların kaçındığı modüller varsa, çünkü "değişiklikten sonra tam olarak ne olacağını kimse bilmiyor", teknik risk artık gerçek bir iş maliyetidir.
5. Sistem eski teknolojilere bağımlıdır
Eski bir framework tek başına sorun demek değildir.
Sorun şu durumlarda ortaya çıkar:
- artık desteklenmiyorsa,
- uzman bulmak zorsa,
- bağımlılıklar güvenli biçimde güncellenemiyorsa,
- çalışma ortamı sorunluysa,
- yeni çözümlerle entegrasyon zorlaşmışsa.
O zaman teknoloji iş imkânlarını sınırlamaya başlar.
Uygulamayı her zaman baştan mı yazmak gerekir?
Hayır.
Bu, legacy software yaklaşımındaki en yaygın hatalardan biridir.
Tam yeniden yazım haklı görülebilir, ancak yüksek riskli bir girişimdir.
Eski bir sistem çoğu zaman, dokümantasyonda yer almayan onlarca ya da yüzlerce iş kuralı, istisna ve davranış içerir. Onu sıfırdan yeniden yazarak, teknolojik olarak yeni ama iş açısından eksik bir sistem oluşturmak çok kolaydır.
Bu yüzden birçok durumda daha iyi çözüm aşamalı modernizasyon olur.
Sistemin bir bölümü aktif kalır, diğer alanlar ise kademeli olarak yeni bileşenlerle değiştirilir.
Bu yaklaşım, diğer adıyla Strangler Fig deseni olarak bilinir. Sistemi adım adım modernize etmeye, değeri daha erken sunmaya ve tek seferlik tüm çözüm göçünün riskini azaltmaya olanak tanır.
Modernizasyon ne zaman anlamlıdır?
Şu durumlarda değerlendirmeye değerdir:
- sistem hâlâ önemli iş süreçlerini yürütüyorsa,
- mimari işlevselliğin en azından bir kısmını ayırmaya izin veriyorsa,
- veriler güvenli biçimde taşınabiliyor veya entegre edilebiliyorsa,
- sorun tüm yapıyı değil, belirli alanları etkiliyorsa,
- uygulama değer üretiyorsa ve tamamen değiştirilmesi riskliyse,
- sistem aşamalı olarak modernize edilebiliyorsa.
Bu, özellikle sistemi birkaç ay boyunca kapatmanın mümkün olmadığı durumlarda çok iyi bir çözümdür.
Modernizasyon ne zaman anlamlı olmayabilir?
Eski sistemi kurtarmaya devam etmenin ekonomik olmaktan çıktığı durumlar da vardır.
Örneğin:
- mimari mevcut gereksinimlerle temelden uyumsuzsa,
- kritik teknolojiler desteklenmiyorsa,
- sistemin güvenilir testleri ve dokümantasyonu yoksa,
- güvenlik kapsamlı bir yeniden yapılanma gerektiriyorsa,
- her büyük değişiklik neredeyse tüm sisteme müdahale etmeyi gerektiriyorsa,
- çalışma şeklini anlayan insan sayısı yetersizse,
- bakım ve geliştirme maliyetleri, sistemi kullanmaya devam etmenin değerini aşıyorsa.
O zaman yalnızca modernizasyon maliyetini değil.
Ayrıca mevcut çözüme bağlı kalmanın maliyetini de hesaplamak gerekir.
En pahalı uygulama her zaman bakımı en pahalı olan değildir
Aylık bakım maliyeti görece düşük olan bir sisteminiz olabilir.
Aynı zamanda her yeni özellik, olması gerekenden kat kat daha pahalıya mal olabilir.
İşte bu yüzden yalnızca hosting, sunucu ya da destek faturası teknolojinin ne kadara mal olduğunu söylemez.
Bir sistemin gerçek maliyeti şunları da kapsar:
- geliştirme süresi,
- test süresi,
- hata maliyeti,
- dağıtım süresi,
- kesinti maliyeti,
- işe alım zorluğu,
- güvenlik riski,
- bilgi kaybı maliyeti,
- yeni özelliklerde gecikme,
- teknolojinin yarattığı iş kısıtlamaları.
Bir noktada teknoloji, işi destekleyen bir araç olmaktan çıkar.
İşin kısıtlayıcısı olmaya başlar.
Karara nasıl yaklaşmalı?
"Sıfırdan yazıyoruz" kararı verilmeden önce, teknik bir denetim yapmak gerekir.
En az şunları kapsamalıdır:
Mimari - sistemin nasıl bölündüğü ve bileşenlerinin nasıl iletişim kurduğu.
Kod - kalite, karmaşıklık, tekrar eden yapı ve bakımı özellikle zor olan noktalar.
Bağımlılıklar - framework'ler, kütüphaneler, sürümler ve bunların desteği.
Güvenlik - açıklar, erişim yönetimi biçimi ve eski bileşenlerden kaynaklanan riskler.
Testler - otomasyon kapsamı ve değişiklikleri güvenle yapabilme imkânı.
CI/CD - uygulamanın derlenme, test edilme ve dağıtılma şekli.
Veriler - veritabanı yapısı, migrasyonlar, entegrasyonlar ve bağımlılıklar.
İzleme - dağıtımdan sonra sistemde neler olup bittiği biliniyor mu.
Geliştirme süreci - bir sonraki özelliği teslim etmenin gerçekte ne kadara mal olduğu.
Ancak bu temel üzerinden üç senaryo makul biçimde değerlendirilebilir:
- korur ve geliştiririz,
- kademeli olarak modernize ederiz,
- yeni bir sistem kurarız.
Tek doğru bir cevap yoktur. Ancak cevaba ulaşmanın doğru bir yolu vardır.
Teknoloji gelişimi mümkün kılmalı, onu engellememelidir
İyi mimari, sistemin modern görünmesi demek değildir.
İşin gerektirdiği anda değiştirilebilmesi demektir.
Bu yüzden uygulamaya sadece bugün çalışıp çalışmadığı açısından bakmak yeterli değildir.
Ayrıca, bir, iki ya da beş yıl sonra yeni özellikler eklemenin ne kadara mal olacağını da kontrol etmek gerekir.
Çünkü çalışan ama sağlıklı geliştirmeye izin vermeyen bir sistem, sadece modernizasyon gerektiren bir sistemden çok daha büyük bir sorun olabilir.
