Programlamada Frankenstein — nedir, nedenleri ve önlenmesi

Programlamada Frankenstein Nedir

Frankenstein (Frankenstein kodu, Frankenstein kalıbı), bir yazılım sisteminin birlikte çalışmak üzere tasarlanmamış parçalardan bir araya getirildiği bir anti-kalıptır. Frankenstein'ın canavarı gibi, bu tür kod çalışabilir ancak çirkin, öngörülemez ve en ufak değişikliklerde tehlikelidir.

Terim edebiyattan gelir: Mary Shelley'nin “Frankenstein, ya da Modern Prometheus” (1818) romanında, bir bilim insanı farklı ölü insanların vücut parçalarından canlı bir varlık yarattı. Programlamada, benzetme tamdır — geliştiriciler farklı framework, kütüphane ve dillerin parçalarını alır ve “canlı” olarak birbirine yapıştırarak çalışan ancak canavarca bir sonuç elde eder.

Frankenstein ile spagetti kod arasındaki fark, ölçek ve doğadadır. Spagetti kodu, tek bir teknoloji yığını içindeki dolanık bir yapıdır. Frankenstein, mimari düzeyde eklektizmdir: aynı sistem içinde farklı teknolojiler, uyumsuz paradigmalar, çelişen yaklaşımlar.

Frankenstein vs Mikroservisler

Mikroservis mimarisi, farklı hizmetler için farklı teknolojilerin kullanılmasına izin verir, ancak net sınırlar ve standartlaştırılmış etkileşim protokolleri koşuluyla. Frankenstein sınırsız kaotik bir karışımdır: aynı denetleyicide REST ve GraphQL, aynı modülde iki ORM, aynı varlık için SQL ve NoSQL.

Frankenstein Sendromu Neden Ortaya Çıkar

Teknik bir lider veya mimarın olmaması temel nedendir. Projede mimari bütünlükten sorumlu bir kişi olmadığında, her geliştirici “kendisi için” araçlar seçer. Biri Spring'i sever, diğeri Guice'ı, üçüncüsü özel DI kullanır. Sonuç — mimari bir karışıklık.

Projelerin birleşmesi ikinci yaygın nedendir. İki ekip, farklı yığınlar kullanarak modüllerini bağımsız olarak geliştirdi. Modüllerin tek bir uygulamada birleştirilmesi gerektiğinde, bağdaştırıcılar ve ara katmanlarla basitçe “yapıştırılır”. Sonuç Frankenstein'dır.

Kurumsal satın almalar üçüncü senaryodur. A şirketi B şirketini satın aldı ve ürününü kendi ürününe entegre etmek istiyor. Yeniden yazmak yerine — API'ler, paylaşılan veritabanları ve yamalar aracılığıyla yapıştırma. Bir yıl sonra sistem, kimsenin anlamadığı bir canavara dönüşür.

“Yaratıcılık” Faktörü

Deneyimli geliştiriciler, üretimde yeni teknolojiler denemek ister ve genellikle Frankenstein'ın kaynağı olurlar. Deneyleri izole edilmiş bir modülle sınırlamak yerine, sistemin kritik bölümlerine deneysel kod eklerler.

Gerçek Projelerde Frankenstein Örnekleri

Klasik bir örnek, tek bir uygulamada birden çok ORM kullanılmasıdır. Bazı modüller Hibernate kullanır, bazıları MyBatis ve bazıları doğrudan JDBC sorguları kullanır. İşlemler yönetilemez hale gelir, önbellek tutarsız olur ve yeni bir geliştirici yeni bir özellik için hangi yaklaşımı kullanacağını bilemez.

İkinci bir örnek, mimari stillerin karıştırılmasıdır. Bir REST API denetleyicisinde, SOAP hizmet çağrıları, doğrudan SQL sorguları, dosya sistemi erişimi ve HTML oluşturma bulursunuz. Böyle bir uygulamayı test etmek, genişletmek veya belgelemek imkansızdır.

Üçüncü bir örnek, backend için Python, mikroservis için Node.js, masaüstü istemcisi için C# ve Android uygulaması için Java'nın kullanıldığı, tüm iş mantığının sorumlulukların net bir şekilde ayrılması olmadan aralarına dağıtıldığı bir teknoloji yığınıdır.

// Frankenstein — karışık stiller ve teknolojiler
// callbacks, Promises ve async/await birleşimi

// callbacks
db.query("SELECT * FROM users", function(err, rows) {
  if (err) handleError(err);
  // callback içinde Promise
  fetch("/api/data").then(function(data) {
    // then içinde async/await
    (async () => {
      const result = await processData(data);
      sendResponse(result);
    })();
  });
});

// temiz kod — birleşik async/await stili
async function getUserData(userId) {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);
  const data = await fetch("/api/data/" + userId);
  return await processData(user, data);
}

Veri Düzeyinde Frankenstein

Tek bir veritabanı, aynı anda SQL ilişkisel (normalleştirme ile) ve NoSQL belge odaklı (JSON sütunları ile) olarak kullanılır. Bazı sorgular ORM aracılığıyla, bazıları saklı yordamlar aracılığıyla, bazıları koddan doğrudan SQL aracılığıyla gider. DB şeması belgelenmemiştir, geçişler çakışır.

Frankenstein Kodunun Sonuçları

Oryantasyon karmaşıklığı ilk sonuçtur. Yeni bir geliştirici, sistemin nasıl çalıştığını anlamak için 5 dil, 3 framework, 2 mimari stil bilmelidir. Oryantasyon haftalardan aylara kadar uzar. LinkedIn'e (2023) göre, teknolojik eklektizmli projeler yeni çalışanları 2 kat daha sık kaybeder.

Davranışın öngörülemezliği ikinci sonuçtur. Python mikroservisindeki bir değişiklik, net sözleşmeler olmadan bir veritabanını paylaştıkları için Java modülünü beklenmedik şekilde bozabilir. Bu tür sorunları hata ayıklamak, yığındaki tüm teknolojilerin eşzamanlı bilgisini gerektirir.

Güvenlik üçüncü sonuçtur. Yığındaki her teknoloji, kendi güvenlik yapılandırmasını, kendi yamalarını, kendi izlemesini gerektirir. 5-6 heterojen teknoloji için kabul edilebilir düzeyde güvenlik sağlamak pratikte imkansızdır. Bunlardan biri kaçınılmaz olarak savunmasız olacaktır.

Frankenstein'ın Teknik Borcu

SonarQube teknik borcu ölçebilir, ancak “mimari borcu” — bileşen uyumsuzluğunu ölçemez. Bu borç, linter uyarılarında değil, farklı teknolojilerde yazılmış üç farklı modülü değiştirmeden yeni bir özellik ekleyememede kendini gösterir.

Canavar Yaratmaktan Nasıl Kaçınılır

İlk ve ana adım, teknoloji yığınının bütünlüğünden sorumlu bir mimar veya teknik lider atamaktır. Bu kişi, mimari inceleme olmadan yeni teknolojilerin tanıtılmasına veto yetkisine sahiptir. Demokrasi değil, anahtar teknolojiler hakkında sorumlu tek karar.

İkinci adım, Architecture Decision Record (ADR) sürecini uygulamaktır. Herhangi bir önemli mimari karar (DB, framework, protokol seçimi) kısa bir metin olarak belgelenir: bağlam, değerlendirilen alternatifler, alınan karar, sonuçlar. ADR'ler depoda saklanır ve tüm ekip tarafından kullanılabilir.

Üçüncü adım, “bir görev — bir araç” ilkesini oluşturmaktır. HTTP istekleri için — bir istemci. ORM için — bir kütüphane. Loglama için — bir framework. İstisnalara yalnızca gerekçeli ADR aracılığıyla izin verilir. Projede zaten Axios varsa — fetch eklemeyin, SLF4J varsa — System.out aracılığıyla yazmayın.

• Mimar yeni teknolojiler üzerinde veto hakkıyla
• Architecture Decision Records her önemli seçim için
• Birleşik yığın her görev için — bir HTTP istemcisi, bir ORM
• RFC tüm ekibin tartışmasıyla büyük değişiklikler için
• Teknoloji radarı nelerin benimsenebileceğini izlemek için

Deneysel Teknoloji Politikası

Deneylere izin verilir, ancak izole bir ortamda. Sistemin geri kalanını etkilemeden yeni bir teknolojiyle yeniden yazılabilecek bir modül veya hizmet ayırın. Deney başarılı olursa — ADR aracılığıyla standartlaştırın. Olmazsa — sonuçsuz bir şekilde kaldırın.

Mevcut Frankenstein Nasıl Yeniden Düzenlenir

Envanter — ilk adım. Teknoloji yığınının tam bir haritasını oluşturun: hangi framework, kütüphane, dil, protokollerin hangi modüllerde ve hangi görevler için kullanıldığı. Sorunun boyutunu göreceksiniz: araç tekrarı, çakışan teknolojiler, kullanılmayan bağımlılıklar.

Standartlaştırma — ikinci adım. Her görev için bir araç seçin. Örneğin: ORM için yalnızca Hibernate, loglama için yalnızca SLF4J + Logback, API için yalnızca REST. Standardı ADR'de belgeleyin. Eklektizmin en çok soruna neden olduğu modüllerden değiştirmeye başlayın.

Parallel Run stratejisi — üçüncü adım. Eski ve yeni araçlar, yenisi güvenilirliğini kanıtlayana kadar paralel çalışır. Örneğin, eski HTTP istemcisi ve yenisi aynı anda çalışır, ancak yenisi yalnızca isteklerin bir kısmını işler. Stabilizasyon döneminden sonra eskisi kaldırılır.

// Frankenstein — bir projede üç HTTP yaklaşımı
// Modül A: OkHttp
OkHttpClient client = new OkHttpClient().newCall(request);

// Modül B: RestTemplate (Spring)
restTemplate.getForObject(url, String.class);

// Modül C: java.net.HttpURLConnection
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();

// birleşik yaklaşım: senkron için RestTemplate, reaktif için WebClient
@Autowired
private RestTemplate restTemplate;

public String callApi(String url) {
    return restTemplate.getForObject(url, String.class);
}

Önlemede Teknik Liderin Rolü

Teknik lider, Frankenstein ile mücadelede ana araçtır. Bir yönetici değil, fildişi kuledeki bir mimar değil, kod yazan, PR'ları inceleyen ve mimari kararlar alan uygulamalı bir geliştiricidir. Böyle bir kişi olmadan, proje kaçınılmaz olarak teknolojik eklektizme kayar.

RFC (Request for Comments), açık kaynak topluluklarından ödünç alınmış bir süreçtir. Önemli bir teknoloji tanıtılmadan önce, yazar bir RFC yazar: sorun, önerilen çözüm, alternatifler, uygulama planı. Ekip tartışır, oylar, kabul eder veya reddeder. RFC şeffaflık yaratır ve “sessiz” mimari kararları önler.

Teknoloji Radar (ThoughtWorks Technology Radar) bir sınıflandırma aracıdır: Adopt, Trial, Assess, Hold. Ekip düzenli olarak radarı gözden geçirir ve durumları günceller. Bu, “trendy” olanı “kullanışlı” olandan ayırmaya ve kanıtlanmamış teknolojilerin kritik koda girmesini önlemeye yardımcı olur.

Tutarlılık İlkesi

Mimarinin en önemli kalitesi tutarlılıktır. Proje genelinde kullanılan çok iyi olmayan bir araç bile, yalnızca bir modülde kullanılan en iyi araçtan daha iyidir. Tutarlılık bilişsel yükü azaltır, oryantasyonu basitleştirir ve kodu öngörülebilir kılar.