Programlamada Geçici Çözüm: Nedir, Türleri Nelerdir ve Nasıl Çalışır

Programlamada Geçici Çözüm Nedir?

Geçici Çözüm, işlevsel olarak doğru ancak teknik olarak optimal olmayan bir yazılım çözümü için kullanılan bir argo terimdir. Bu tür kod çalışır, testleri geçer ve hatta üretime kadar ulaşır, ancak okumak her şeyi sıfırdan yeniden yazma isteği uyandırır. İngilizce konuşulan ortamlarda workaround, kludge (kluge), hack veya quick-and-dirty fix terimleri kullanılır.

Terim, evsel bir benzetmeden gelir: bir sandalye bacağı kırılırsa, bantla bağlanabilir — sandalye tekrar çalışır, ancak çözüm geçici ve çirkin. Programlamada da aynı şey geçerlidir: bir hata hardcode, zaman aşımı geçici çözümü veya belgelenmemiş bir API üzerinden geçici çözüm ile düzeltilir. Kod derlenir, uygulama çökmez, ancak çözüme kaliteli denemez.

Önemli bir fark: hata (bug) — kodun beklendiği gibi çalışmamasıdır. Geçici çözüm — kodun çalışması ancak kötü tasarlanmış olmasıdır. Geçici çözüm her zaman geliştiricinin bilinçli bir seçimidir: “Bunun çirkin olduğunu biliyorum, ama şu anda sorunu çözüyor.”

Stripe'a (2024) göre, geliştiriciler ortalama olarak haftada 17 saat teknik borç ve geçici çözümlerle uğraşmaktadır — bu çalışma sürelerinin neredeyse yarısıdır. Bu, ekip üretkenliğinde doğrudan bir kayıptır.

Geçici Çözümler Ne Zaman ve Neden Ortaya Çıkar

Birinci ve ana neden son teslim tarihleridir. Yayınlamaya bir gün kala ve kritik bir hata henüz düzeltilmemişse, ekip doğru çözüm yerine hızlı çözümü seçer. Bir değeri hardcode etmek, bir kontrolü devre dışı bırakmak, sleep() eklemek — son teslim tarihi geçici çözümlerinin klasik örnekleri. Deneyimli bir geliştirici bu tür yerleri her zaman TODO veya FIXME ile işaretler.

İkinci neden API uyumsuzluğudur. Üçüncü taraf bir kütüphane veya framework belgelendiği gibi davranmaz. Framework gerekli sınıfı dışa aktarmaz, bir yöntem kullanımdan kaldırılmış olarak işaretlenmiştir ve alternatifi yoktur. Geliştirici yansıma (reflection), dahili API veya geçici bir çözüm kullanmak zorunda kalır. Java'da bu, setAccessible(true) aracılığıyla erişim olabilir; Swift'te — @objc ve performSelector.

Üçüncü neden eski koddur. Bir geliştirici, framework'ün eski bir sürümünde 5-10 yıl önce yazılmış bir projeyi devralır. Tüm modülü yeniden yazmak için zaman veya bütçe yoktur, bu nedenle yeni işlevsellik geçici çözümler aracılığıyla eski koda “yapıştırılır.” Yavaş yavaş o kadar çok katman birikir ki modül “büyük bir çamur topu”na (big ball of mud) dönüşür.

Dördüncü neden test eksikliğidir. Test olmadan yeniden düzenleme tehlikelidir: mimariyi değiştirmek çalışan işlevselliği bozabilir. Test olmadığında, geliştirici kararlılığı riske atmaktansa çalışan kodun üzerine bir geçici çözüm eklemeyi tercih eder. Google Testing Blog'a (2024) göre, testi olmayan ekipler geçici çözümleri 3 kat daha fazla kullanır.

Geçici Çözüm Türleri

Geçici çözümlerin sınıflandırılması, ekibin ne tür bir teknik borçla karşı karşıya olduğunu anlamasına ve doğru ortadan kaldırma stratejisini seçmesine yardımcı olur. Ana türleri inceleyelim.

Hardcode — en yaygın tür. Yapılandırma, kaynak veya parametre yerine kodda sabit bir değer kullanılır. Örnek: sabit kodlanmış sunucu URL'si, 5 saniyelik zaman aşımı, 16pt yazı tipi boyutu. Hardcode, kodu ölçeklenemez hale getirir ve herhangi bir değişiklik için yeniden derleme gerektirir.

Kopyala-yapıştır — ortak mantığı çıkarmak yerine küçük değişikliklerle kod parçasını çoğaltmak. Klasik belirti: projede bir satırda farklılık gösteren 3 benzer yöntem vardır. Kopyala-yapıştır, görev anında kod yazmayı hızlandırır ancak gelecekte bakımı 10 kat yavaşlatır — düzeltme bir yerine 3 yerde uygulanmalıdır.

Boş try-catch — hiçbir şey yapmayan veya hatayı işlemeden sadece günlüğe kaydeden bir catch bloğu. Bu geçici çözüm istisnayı “sessize alır” ancak nedenini çözmez. Uygulama çalışmaya devam eder, ancak veriler bozulabilir ve kullanıcı geri bildirim alamayabilir.

Kodda Uyku (Sleep) — bir olay veya geri arama olması gerektiğinde beklemek için Thread.sleep(500) veya DispatchQueue.main.asyncAfter. Bu kod güvenilir değildir: yavaş bir cihazda 500 ms yeterli olmayabilir; hızlı bir cihazda bekleme gereksizdir. CountDownLatch, Semaphore veya uygun zamanlamayla async/await kullanın.

Uyumluluk bayrakları — işletim sistemi sürümünü, cihaz modelini veya özellik kullanılabilirliğini kontrol eden if-else basamakları. 3-4'ten fazla bayrak olduğunda kod spagettiye dönüşür. Çözüm — Strategy deseni veya yapılandırma yoluyla Feature Flags.

Geçici Çözüm vs Teknik Borç

Birçok geliştirici geçici çözüm ve teknik borcu karıştırır. Fark ölçek ve farkındalıkta yatar. Geçici çözüm — yerel, belirli bir çözümdür (bir yöntem, bir sınıf). Teknik borç — bir modülün veya tüm uygulamanın mimarisini etkileyen sistemik bir sorundur.

Ward Cunningham'ın (Teknik Borç teriminin yaratıcısı) benzetmesi: teknik borç, bankadan kredi çekmek gibidir. Evi daha hızlı inşa etmek için şimdi para alırsınız, ancak daha sonra faiz ödersiniz. Geçici çözüm — çivi tabancası yerine çekicle çivi çakmak gibidir: iş yapılır, ancak daha az verimli.

Bir geçici çözüm teknik borç yaratmaz. Ancak bir modülde 50 geçici çözüm = mimari borçtur. Bu nedenle, ekip kuralı: her geçici çözüm kod incelemesinde veya görev takipçisinde kaydedilir ve ekip düzenli olarak (sprint başına bir kez) birikmiş geçici çözümleri gözden geçirir.

Spotify Engineering'e (2023) göre, kodda geçici çözümleri takip eden ekipler (özel bir TODO etiketi veya özel ek açıklama aracılığıyla) yeniden düzenleme süresini %30 azaltır — çünkü sorunlu yerleri aramak için saatler harcamazlar.

Geçici Çözümlerden Nasıl Kurtulunur

İlk adım — envanter. Kod tabanında anahtar kelimeleri arayın: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Modern IDE'ler bunları ayrı bir renkle vurgular. GitHub ayrıca Pull Request arayüzünde TODO'yu gösterir. Tüm geçici çözümlerin bir listesini öncelikle birlikte yapın.

İkinci adım — önceliklendirme. Tüm geçici çözümler hemen düzeltilmelidir. Öncelik = dosyadaki değişiklik sıklığı × kritiklik. Bir dosya yılda 2 kez değişiyorsa, geçici çözüm bekleyebilir. Bir modül her sprinte dokunuluyorsa — geçici çözüm ilk önce düzeltilmelidir.

Üçüncü adım — testlerle yeniden düzenleme. Asla test olmadan bir geçici çözümü yeniden düzenlemeyin. Önce mevcut davranışı (geçici çözümle birlikte) doğrulayan bir test yazın, sonra yeniden düzenleyin, ardından testin geçtiğinden emin olun. Bu olmadan, bir geçici çözümün yeniden düzenlenmesi, onun yazıldığı işlevselliği bozabilir.

// Before: Sabit kodlanmış URL geçici çözümü
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// After: BuildConfig aracılığıyla yapılandırma
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

Dördüncü adım — otomasyon. Belirli geçici çözüm desenlerini yasaklayan bir linter kurun. Örneğin, Kotlin için Detekt, üretim kodunda Thread.sleep()'in olmamasını kontrol edebilir, ESLint projede console.log'u yasaklayabilir. Bu, aynı türde yeni geçici çözümlerin ortaya çıkmasını önler.

Geçici Çözüm Ne Zaman Haklıdır

Terimin olumsuz çağrışımına rağmen, bir geçici çözüm haklı bir çözüm olabilir. Ana koşul: geçici çözüm geçicidir, açıkça işaretlenmiştir ve bir değiştirme planı vardır. Her büyük projenin üretim kodunda yüzlerce haklı geçici çözüm vardır.

Durum 1: üretimde acil düzeltme (hotfix). Kritik bir hata tüm kullanıcıları etkiler. Ekibin bir saat içinde bir düzeltmeye ihtiyacı vardır. Doğru yaklaşım: hatayı herhangi bir şekilde düzeltin, acil düzeltmeyi dağıtın. Ardından, ertesi gün, uygun çözümü yazın ve bileti kapatın. Bir acil düzeltme, 48 saatten fazla yaşamıyorsa haklı bir geçici çözümdür.

Durum 2: yeni kütüphane sürümünü beklemek. Bir framework, master'da düzeltilmiş ancak yayınlanması 2 hafta sonra olacak bir hata içerir. Karmaşık geçici kod yazmak yerine, ekip “REMOVE after library 3.2” notuyla bir geçici çözüm ekler. 3.2 yayınlandığında, geçici çözüm kaldırılır.

Durum 3: bir startup veya MVP'yi kapatma. MVP aşamasında hız, mimariden daha önemlidir. Başlangıçta geçici çözümler normaldir. Sorun, startup bir ürüne dönüşmediğinde ancak geçici çözümler kaldığında ortaya çıkar. Öneri: fonlama turundan sonra, kritik teknik borcu ödemek için bir sprint ayırın.

Ana prensip: “Eski kod, testi olmayan koddur” (Michael Feathers). Bir geçici çözüm bir test tarafından kapsanıyorsa ve açıkça belgelenmişse — yönetilebilir. Unutulmuş bir modülde 2 yıl boyunca yorumsuz asılı kalmışsa — bu artık bir geçici çözüm değil, mimari bir sorundur.