Mobil Projelerde Çöp Kod ve Karmaşa — Belirtiler ve Refaktoring

Geliştirmede çöp kod nedir

Çöp kod (ayrıca spaghetti code, karmaşa, big ball of mud), yapısını kaybetmiş ve iç içe geçmiş bağımlılıklardan oluşan bir ağa dönüşmüş bir kod tabanı için bir metafordur. Böyle bir kodda, bir yerdeki herhangi bir değişiklik başka bir yeri bozar ve yeni işlevsellik eklemek riskli bir uğraşa dönüşür.

Mobil geliştirmede, çöp kod özellikle kritiktir: bir “karmaşa” üzerine inşa edilmiş bir uygulama yavaşlamaya başlar, eski cihazlarda çöker ve kod incelemesini geçmekte zorlanır. Mimarisi olmayan bir iOS projesi, dengesizlik nedeniyle App Review'dan geçemeyebilir.

Stripe'a göre, geliştiriciler çalışma sürelerinin %42'sine kadarını mevcut kodu okuyarak ve anlayarak geçirir. Çöp kodlu projelerde bu rakam %60'ı aşar ve geliştirmeyi son derece verimsiz hale getirir.

Terimlerin kökeni

Spaghetti code en eski terimdir ve 1970'lere dayanır. Dolaşık spagettiyi andıran kaotik kontrol akışına sahip kodu tanımlar.

Big ball of mud, Brian Foote ve Joseph Yoder tarafından 1997'de net bir mimarisi olmayan ve kaotik bir şekilde büyüyen sistemleri tanımlamak için tanıtılan bir terimdir.

Çöp kod iş için neden tehlikelidir

Çöp kod, yeni özelliklerin pazara sunulmasını yavaşlatır. Ekip, değer yaratmak yerine mevcut kodun nasıl çalıştığını ve hiçbir şeyi kırmamayı anlamaya çalışarak zaman harcar.

McKinsey'e göre, düşük kod kalitesine sahip şirketler ürün bakımına %20-40 daha fazla harcar ve yeni özelliklerin çıkış hızı, yüksek kod kalitesine sahip şirketlere kıyasla 2-3 kat daha düşüktür.

Çöp kod belirtileri ve nasıl tanınır

Çöp kodu tanımak, bazıları otomatik olarak ölçülen bir dizi nesnel gösterge aracılığıyla yapılabilir. Göstergeler ne kadar çok eşleşirse, sorun o kadar ciddidir.

Sektörde, Halstead Karmaşıklığı, Bakım Yapılabilirlik İndeksi ve Teknik Borç Oranı gibi kod kalite ölçütleri kullanılır. Bu ölçütleri bilmek, bir kod tabanının durumunu nesnel olarak değerlendirmeye yardımcı olur.

Kopyala-yapıştır (kod tekrarı)

En yaygın çöp kod belirtisi, tekrarlanan kod bloklarıdır. Ortak bir işlev çıkarmak yerine, geliştiriciler minimum değişiklikle kodu bir yerden başka bir yere kopyalar.

%5'e kadar tekrar seviyesi normal kabul edilir. Tekrar %15'i aşarsa, bu ciddi bir uyarıdır. Simian ve PMD Copy Paste Detector gibi araçlar, kopyala-yapıştırmayı otomatik olarak belirlemeye yardımcı olur.

Uzun metotlar ve sınıflar

100 satırdan uzun bir metot, çöp kodun açık bir işaretidir. Böyle bir metot genellikle çok fazla şey yapar ve Tek Sorumluluk İlkesini (Single Responsibility) ihlal eder.

1000 satırdan fazla koda sahip sınıflar da sorunludur. İlişkisiz işlevler içerirler, bu da kodun test edilmesini, anlaşılmasını ve değiştirilmesini zorlaştırır.

Yüksek döngüsel karmaşıklık

McCabe'in döngüsel karmaşıklığı (Cyclomatic Complexity), koddaki bağımsız yolların sayısını gösteren bir ölçüttür. 15'in üzerindeki bir değer sorunlu kabul edilir.

Karmaşıklığı 30'un üzerinde olan metotlar “felaket bölgesi”ndedir. Çok fazla dal içerirler ve derinlemesine analiz olmadan test edilmeleri ve anlaşılmaları imkansızdır.

Çöp kod nedenleri

Çöp kod “kendiliğinden” ortaya çıkmaz — her zaman ekipteki belirli süreçlerin ve kararların sonucudur. Nedenleri anlamak, gelecekte önlemeye yardımcı olur.

JetBrains Developer Ecosystem 2024'e göre, geliştiricilerin %67'si zaman yokluğu nedeniyle yapabileceklerinden daha kötü kod yazdıklarını kabul ediyor. Teknik borç birikiminin ana nedeni budur.

Acele ve teslim tarihleri

En yaygın neden sıkı teslim tarihleridir. Ekip, sadece teslim tarihine yetişmek için kodu “nasıl olursa” yazar. Refaktoring, testler ve kod incelemesi “sonraya” ertelenir.

Sorun şu ki “sonra” asla gelmez — bir sonraki sprintte yeni teslim tarihleri belirir ve teknik borç kartopu gibi birikir.

Kod incelemesi eksikliği

Kod incelemesi olmadan, her geliştirici kendi tarzında yazar, kendi desenlerini kullanır ve kendi “izlerini” bırakır. Zamanla, kod tabanı tekdüzeliğini kaybeder.

SmartBear 2024 araştırmasına göre, her pull request için zorunlu kod incelemesi yapan ekiplerin üretimde %60 daha az hatası vardır.

Baştan itibaren zayıf mimari

Bir proje net bir mimari olmadan başlarsa, çöp kod kaçınılmazdır. İlk “hızlı çözümler”, üzerinde daha sonra kaliteli bir şey inşa etmenin zor olduğu bir temel oluşturur.

Mobil geliştirmede, mimari seçimi (MVC, MVP, MVVM, Clean Architecture) kod yazmaya başlamadan önce verilmiş bilinçli bir karar olmalıdır, evrimin bir sonucu değil.

Çöp kodla mücadele yöntemleri

Çöp kodla mücadele, tüm ekipten sistematik bir yaklaşım ve disiplin gerektirir. Sorunu çözecek tek bir araç veya uygulama yoktur — bir dizi önlem gerekir.

Ana ilke, çöp kodu yazma aşamasında önlemektir, sonradan düzeltmek değil. Önleme, mevcut bir “karmaşayı” yeniden düzenlemekten her zaman daha ucuzdur.

Kodlama standartları

Birleşik bir kod stili, çöp kodu önlemenin temelidir. Kodlama standartları (Code Style) belgelenmeli ve linter'lar tarafından otomatik olarak kontrol edilmelidir.

iOS için SwiftLint, Android için Ktlint ve Detekt kullanılır. Bir yapılandırma dosyasında kuralları ayarlamak, standartları ihlal eden pull request'leri otomatik olarak reddetmeye olanak tanır.

Düzenli refaktoring

Refaktoring, hata düzeltmek değil, davranışı değiştirmeden kod yapısını iyileştirmektir. Geliştirme sürecinin düzenli bir parçası olmalıdır, ayrı bir proje değil.

Her sprint'in %20'sinin refaktoring ve teknik borç ödemeye ayrılması önerilir. Bu, “karmaşanın” birikmesini önler ve ekibin hızını uzun vadede korur.

Zorunlu kod incelemesi

Her pull request en az bir geliştirici tarafından incelenmelidir. Kod incelemesi yalnızca hataları değil, aynı zamanda mimari ihlallerini, stil sorunlarını ve potansiyel çöp kod kaynaklarını da belirler.

İyi bir uygulama, kopyala-yapıştır, metot uzunluğu, döngüsel karmaşıklık ve test kapsamı kontrolünü içeren bir kod inceleme kontrol listesidir. Kontrol listesi olmadan, incelemeciler sorunların %50'sine kadarını gözden kaçırır.

Kod tabanını temizleme araçları

Modern kod analiz araçları, çöp kodu otomatik olarak algılamaya, teknik borcu ölçmeye ve kaliteyi izlemeye olanak tanır. Bu araçları CI/CD hattına entegre etmek sürekli izleme sağlar.

En az bir statik analizör ve bir ölçüt ölçüm aracı kullanılması önerilir. Ek olarak, kod kalitesi verilerini toplamak için bir platform bağlanabilir.

Statik analizörler

• SonarQube — lider kod kalitesi analiz platformu, 30+ dili destekler ve Teknik Borç Oranı ölçütleri sağlar
• ESLint — JavaScript ve TypeScript için standart, yapılandırma dosyaları aracılığıyla yapılandırılabilir ve IDE'lere entegre edilir
• SwiftLint — iOS projeleri için zorunlu bir araç, Swift Stil Kılavuzu'na uygunluğu kontrol eder

SonarSource'a göre, statik analiz kullanan ekipler, benimsemeden sonraki ilk çeyrekte üretim hatalarını %30 oranında azaltır.

Ölçüt ölçüm araçları

CodeClimate ve Codacy, kod kalitesi ölçütlerini toplayan, eğilimleri izleyen ve “sıcak noktaları” — en yüksek teknik borca sahip dosyaları gösteren platformlardır.

Android projeleri için Detekt, döngüsel karmaşıklık, metot uzunluğu ve kod tekrarı kontrolleri dahil olmak üzere 100'den fazla yerleşik analiz kuralı sağlar.