Modern yazılım projelerinde teknik borç kaçınılmaz bir gerçek olarak karşımıza çıkıyor. Özellikler geliştirilirken bazı ödünler vermek zorundayız, bu da zamanla kod tabanımızda karmaşık problemler ve mimari yozlaşma yaratabiliyor.
Bu durum bazen tüm yapıyı yeniden yazmayı gerektiren büyük çöküşlere yol açabilir; ancak pek çok senaryoda, daha kademeli ve sistematik bir temizlik sürecine ihtiyaç duyulur. Koca uygulamaların belkizeğ gibi oldukları anlarda sadece küçük iyileştirmeler yapmak bile uzun vadede büyük fark yaratır.
Kurumsal ölçekli projelerde karşılaşılan teknik borcu ele almanın en etkili yollarından biri, iş mantığı refaktörüdür. Bu süreçte amaç, uygulamanın arka planındaki temel iş kurallarını ve uygulamayı oluşturan kod yapısını mimari standartlara uygun hale getirerek birbirinden kopuk parçaların tekrar entegre bir bütün oluşturmasını sağlamaktır.
Temel hedefimiz, kullanıcı arayüzü (UI) katmanından tamamen bağımsız çalışan, temiz ve test edilebilir bir domain kodu oluşturmaktır. Bu sayede uygulamanın farklı bölümlerindeki mimari ihlalleri kökten çözmek ve gelecekteki geliştirmeler için sağlam bir zemin hazırlamak mümkün olur.
Uygulamamız, MVVM (Model-View-ViewModel) gibi modern mimari yaklaşımları kullanıyordu. Bu yaklaşım, verilerin ViewModel üzerinden akmasını ve arayüzün bu değişikliklere göre tepki vermesini gerektiriyordu. Ancak uygulamada bazı kısımlarda tasarım felsefesinden sapmalar gözlemlendi.
Bazı ekranlarda veri akışı için gereksiz katmanlar arasında atlamalar yapılıyordu. Bu gibi hızlı çözümler, kodun uzun vadede bakılabilirliğini zedeler ve test yazmayı son derece zorlaştırır çünkü farklı bileşenler birbirine fazlasıyla bağımlı hale gelir.
Ayrıca iş kuralları genellikle çok karmaşık akışlar içeriyordu. Kullanıcı etkileşimleri üzerinden ilerleyen bu döngüler takip etmesi güçtü, hata ayıklamayı zahmetli kılarken aynı zamanda beklenmedik senaryalarda hatalara (race conditions gibi) neden olma potansiyeli taşıyordu.
Buna ek olarak Fragment ve ViewModel arasındaki sıkı bağımlılık da mimaride büyük bir engel teşkil ediyordu. Bu durum, uygulamanın yeni özelliklerle veya platform güncellemeleriyle uyumlu ilerlemesini engelliyordu. Özellikle binlerce satırı aşan bileşenler bu tıkanıklığı yaratıyordu.
Mimarinin düzeltilmesi tek seferde, devasa bir güncelleme ile yapılabilirdi. Ancak uygulamanın en çok geliştirilen ve aktif olarak kullanılan ekranı olan Ürün Detay Sayfasında (Product Detail Page) bu değişikliği uygulamak bile büyük risk taşıyordu. Bir refaktörleme dalının sisteme dahil edilmesi, diğer özellik geliştirmeleriyle çakışmalara yol açabilirdi.
Bu nedenle kademeli bir yaklaşım benimsendi. İlk adım olarak ViewModel üzerinde bölge blokları oluşturuldu; Veri ve İzlenebilirlik (Data & Observability), Etkileşim ve Dahili Mantık gibi alt başlıklar tanımlandı. Bu sayede karmaşık bileşen üç ana alana ayrıldı.
Geliştirme süreci, doğrudan mimari hataları çözmeye odaklandı: Fragment içerisinde kalan kullanıcı etkileşimi işleyicileri ViewModel fonksiyonlarına taşındı. Dialog yönetimleri durum tabanlı akışlara çevrildi ve navigasyon mantığı tek bir merkezi noktada toplandı. Analitik işlemler gibi ekran dışına bağımlı olan işlemler ise tamamen yeni, test edilebilir sınıflar olarak çıkarıldı.
Bu süreç sayesinde Fragment katmanı kendi işlevine sadık kalarak, sadece arayüzü çizmek ve kullanıcı etkileşimlerini iletmekle sorumlu hale geldi. Tüm iş mantığı (business logic), ViewModel'ın içinde tertipli bir şekilde organize edilmiş oldu.
Discord, oyun sırasında CPU ve GPU yükünü otomatik azaltan Game Mode özelliğini test ediyor.
Henüz yorum yapılmamış. İlk yorumu sen yap!
E-posta adresiniz yayımlanmayacaktır. Gerekli alanlar (*) ile işaretlenmiştir.
