Android: Clean Architecture-1. Selam millet! Android dünyasında… | by Ramazan PEKER | May, 2024

Mimari ve tasarım, yazılım geliştirme sürecinde birbirini tamamlayan ancak farklı odak noktalarına sahip iki kavramdır.

Mimari, sistemin genel yapısını, bileşenler arasındaki ilişkileri ve bu bileşenlerin nasıl etkileşime gireceğini tanımlar. Örneğin, Android platformunda MVVM (Model-View-ViewModel) veya Clean Architecture gibi mimari desenler, uygulamanın modülerliğini ve katmanlı yapısını belirler. Bu desenler, veri katmanı, iş mantığı ve kullanıcı arayüzü katmanlarının nasıl organize edileceğini ve birbiriyle nasıl iletişim kuracağını tanımlar.

Tasarım ise, bu mimari çerçeve içinde daha ayrıntılı çözümler sunar. Örneğin, bir ViewModel’in, bir Activity veya Fragment ile nasıl etkileşime gireceğini ve LiveData ya da StateFlow gibi araçlarla veri akışını nasıl yöneteceğini belirler.

Yani, mimari büyük resmi çizerken, tasarım bu resmin ayrıntılarını doldurur. Android’de mimari kararlar, genellikle uygulamanın uzun vadeli esnekliği ve ölçeklenebilirliği üzerinde büyük etkiye sahipken, tasarım kararları, günlük yazılım geliştirme sürecinin verimliliği ve kodun okunabilirliği üzerinde daha fazla etkilidir.

Mimarisi olmayan projelerin başarısızlığı, yazılım geliştirme sürecinde sıkça karşılaşılan bir durumdur.

Bu tür projelerde, her yeni özellik eklenişinde veya hata düzeltildiğinde, kod tabanı giderek karmaşık hale gelir ve yönetilmesi zorlaşır. Android platformunda Kotlin kullanarak geliştirdiğimiz bir uygulama düşünelim. Başlangıçta küçük bir ekip tarafından geliştirilmiş olabilir, ancak zamanla büyüdükçe ve yeni özellikler eklendikçe, kodun organizasyonu ve yapısı yeterince düşünülmediğinde, projede bir kaos baş gösterir.

Mesela, Activity veya Fragment’lerde iş mantığının doğrudan tanımlanması, RecyclerView adaptörlerinin şişmesi ve ViewModel’lerin çok fazla sorumluluk alması gibi durumlar ortaya çıkar. Yeni geliştiriciler ekibe katıldıkça, kodun karmaşıklığı ve anlaşılmazlığı, onların verimli çalışmasını zorlaştırır ve her sürümde sorunlar ve hatalar artar.

Bu tür projelerde, geliştiricilerin sayısının her sürümde artması da bir diğer önemli sorundur. Android uygulama geliştirme dünyasında, mimarisi olmayan projelerde yeni bir özellik eklemek veya mevcut bir hatayı düzeltmek için gereğinden fazla geliştiriciye ihtiyaç duyulur.

Örneğin, yeni bir ödeme yöntemi eklemek istediğimiz bir e-ticaret uygulamasında, ViewModel’den doğrudan API çağrıları yapıldığı ve veri katmanının net bir şekilde ayrılmadığı durumlarda, birçok kod parçasının birbirine bağımlılığı nedeniyle, birçok geliştiricinin aynı anda çalışması gerekebilir. Bu, kod karmaşasını daha da artırır ve proje yönetimini zorlaştırır.

Bu kaotik durumdan kaçınmak için, Android projelerinde sağlam bir mimari benimsemek, örneğin MVVM veya Clean Architecture gibi, kodun sürdürülebilirliğini ve geliştirici verimliliğini artırmak için kritiktir. Bu yaklaşımlar, kodun modüler ve test edilebilir olmasını sağlayarak projelerin başarısını uzun vadede güvence altına alır.

İş dünyasında sıkça karşılaşılan bir durum, geliştiricilerin “Şu sürümü bir yayınlayalım, sonra geri dönüp düzeltiriz” söylemidir.

Örneğin, bir fitness uygulaması geliştirirken, kullanıcıların egzersiz rutinlerini kaydetme özelliğini hızla piyasaya sürmek için Activity veya Fragment içinde iş mantığı ve veri yönetimi doğrudan tanımlanabilir. Bu, piyasaya hızlı çıkma baskısı altında çalışan geliştiricilerin ortak bir yanılgısıdır. Ancak, bu özellik yayınlandıktan sonra, geliştiriciler genellikle geri dönüp bu kodu düzeltmek ve daha iyi bir mimari yapıya oturtmak için vakit bulamazlar.

Yeni özellikler eklenmeye devam ettikçe, örneğin bir diyet takibi veya sosyal paylaşım özellikleri, birikmiş teknik borç ve kod karmaşası projeyi daha da zorlaştırır. Bu durum, temiz kod yazmayı ve sağlam bir mimari kurmayı sürekli erteleyen geliştiricilerin, projeler büyüdükçe ve karmaşıklaştıkça geri dönüp düzeltme fırsatı bulamamalarına neden olur.

Sonuç olarak, Android projelerinde temiz kod ve iyi bir mimari yapıyı ertelemek, geliştiricilerin kendilerine söyledikleri bir yalan olarak kalır ve projelerin uzun vadeli başarısını tehlikeye atar.

Test Driven Development (TDD), yazılım geliştirme sürecinde kodun doğruluğunu garanti altına almak ve temiz bir mimari oluşturmak için kullanılan etkili bir yöntemdir.

TDD’nin temel prensibi, önce test yazmak, sonra bu testi geçecek minimum kodu yazmak ve son olarak kodu iyileştirmektir. Bu yaklaşım, geliştiricilerin “Şu sürümü bir yayınlayalım, sonra geri dönüp düzeltiriz” söylemiyle doğrudan çelişir. Çünkü TDD, her adımda kodun test edilmesini ve temiz bir yapıda olmasını sağlar.

Örneğin, bir Android uygulamasında yeni bir özelliği eklerken, önce bu özelliğin gereksinimlerini belirleyip bu gereksinimlere göre testler yazılır. Daha sonra bu testleri geçecek şekilde iş mantığı ve arayüz bileşenleri geliştirilir. Böylece, kodun her aşamada doğru çalıştığı ve temiz bir mimariye sahip olduğu garanti altına alınır.

Bir örnek vermek gerekirse, bir yemek tarifleri uygulaması geliştirdiğimizi düşünelim. Kullanıcıların tarif ekleme ve arama özelliklerini eklerken, öncelikle bu özelliklerin tüm senaryolarını kapsayan birim testler yazarız.

Örneğin, kullanıcıların tarif eklerken doğru formatta veri girmesi, tariflerin kategoriye göre aranabilmesi ve tariflerin doğru şekilde listelenmesi gibi senaryoları test ederiz. Bu testler yazıldıktan sonra, gerekli ViewModel, Repository ve DAO sınıflarını geliştirip testleri geçecek minimum kodu yazarız.

Aynı şekilde, bir haber uygulamasında, kullanıcıların favori haberlerini kaydetme ve çevrimdışı erişim sağlama özelliklerini eklerken de TDD’yi kullanabiliriz. Favori haberlerin doğru şekilde kaydedilmesi, çevrimdışı iken erişilebilmesi ve uygulamanın bu durumlarda düzgün çalışması senaryolarını kapsayan testler yazarız. Bu yaklaşım, kodun her zaman test edilmesini ve temiz bir yapıda olmasını sağlayarak, geliştiricilerin “Sonra düzeltiriz” söylemine gerek kalmadan sürdürülebilir bir kod tabanı oluşturmasını sağlar.

Leave a Comment

Scroll to Top