Polyglot bir kod tabanını sürdürmek: bağlam değiştirme maliyeti

Birkaç yıldır aynı anda PHP, Go ve TypeScript ile çalışıyorum. Farklı günlerde farklı dillerde yazıyorum; bazen aynı gün içinde iki dil arasında gidip geliyorum. Bu pratiğin bilişsel bir bedeli var ve bu bedelin büyük bölümü görünmüyor — toplantı süresi, derleme süresi ya da test geçiş oranı gibi ölçülmüyor. Yine de gerçek.

Bağlam değiştirme maliyeti yazılım dünyasında çoğunlukla görev bazında konuşuluyor: bir özelliği yarıda bırakıp bir hata gidermek, sonra toplantıya girmek. Dil bazındaki bağlam değiştirme daha az konuşulan ama benim deneyimimde daha derin bir kategori.

Dilin düşünme biçimi

Her dil farklı düşünme biçimi dayatıyor. Bu klişe gibi görünüyor ama uygulamada somut sonuçlar doğuruyor.

Go’da hata yönetimi (error handling) deyimsel (idiomatic) kodun merkezinde. Her fonksiyon çağrısının ardından if err != nil kontrolü var; bu doğrusal, açık, sözcük düzeyinde görünür bir akış. PHP’de ise istisna (exception) fırlatma ve yakalama daha yaygın; kontrol akışı daha örtük.

Bir sabah Go’da iki saat yazdıktan sonra Laravel kodu yazmaya geçtiğimde, hata yönetiminde küçük düşünce gecikmeleri yaşıyorum. Deyimsel PHP’ye dönmek bir ısınma süresi gerektiriyor. Aynısı tersi yönde de geçerli — PHP’den Go’ya geçerken birkaç satır yazan parmaklarım, alışkanlıkla yanlış syntax’ı yazıyor.

TypeScript ise bu ikisinden farklı bir katman: tip sistemi daha zengin, IDE entegrasyonu daha güçlü, ama tarayıcı/Node ortamının tuhaflıkları her zaman arka planda. PHP veya Go’dan TypeScript’e geçerken “async her yerde” zihniyetini yeniden yüklemem gerekiyor.

Görünmez maliyet nerede birikir

Üç dilde çalışmanın maliyeti genellikle yanlış yerde aranıyor. “Dil sözdizimini unutmak” yüzeysel bir sorun; gerçek maliyet daha derinde.

Deyimsellik kaybı. Her dilin bir deyimsel tarzı var. Go’da slice’ları range ile gezersiniz, PHP’de array_map/filter/reduce ya da collection pipeline kullanırsınız, TypeScript’te fonksiyonel akışı tercih edersiniz. Bağlam değiştirmek bu tarzları bulanıklaştırıyor. Yazdığım PHP kodu zaman zaman “Go zihniyetiyle yazılmış PHP” gibi görünüyor. Bu, çalışıyor ama kodu okuyan başkasına verimli bir sinyal vermiyor.

Araç hafızası. Debugger kısayolları, IDE yapılandırmaları, paket yöneticisi alışkanlıkları. Go’da go mod tidy, PHP’de composer require, TypeScript’te npm install. Küçük farklılıklar ama yüksek frekansla tekrar eden şeyler birikip zaman çalıyor.

Kütüphane dönüşüm noktaları. Bir problemi farklı dillerde farklı kütüphanelerle çözüyorsunuz. Tarih-saat işlemleri için PHP’de Carbon, Go’da standart time paketi, TypeScript’te date-fns ya da luxon. Hangi API’yi düşünmeniz gerektiğini seçmek de bağlam değiştirmenin bir parçası.

Maliyeti düşürmenin yolları

Birkaç pratik geliştirerek bu maliyeti kabul edilebilir düzeyde tutuyorum.

Dil bloklarıyla çalışmak. Aynı gün içinde diller arasında sık sık gidip gelmek yerine, mümkün olduğunda sabah Go, öğleden sonra PHP gibi bloklar kuruyorum. Her zaman mümkün değil, ama yapılabildiğinde geçiş sürtünmesini azaltıyor.

Her dil için ayrı çalışma alanı. Editör pencereleri, terminal sekmeleri ve hatta bazen tarayıcı profili dil bazında ayrılmış oluyor. Bu küçük fiziksel/dijital ayrım zihinsel geçişi destekliyor.

Deyimsel koda bilinçli özen. Bir dilde yazdığımda o dilin deyimselliğine bağlı kalmak için ekstra özen gösteriyorum. Code review’larda başkalarına baktığımda şunu arıyorum: bu kod, bu dilde yazan biri gibi görünüyor mu?

// Go deyimsel örüntü
users, err := repository.FindActive()
if err != nil {
    return nil, fmt.Errorf("active users fetch failed: %w", err)
}

// PHP deyimsel örüntü
try {
    $users = $repository->findActive();
} catch (RepositoryException $e) {
    throw new ServiceException('Active users fetch failed', previous: $e);
}

İkisi de hata yönetiyor, ama her biri kendi dilinin beklentisini yansıtıyor.

Polyglot’un getirisi hâlâ pozitif mi

Evet. Farklı dillerin problem çözme yaklaşımlarını görmek, tek dilde sıkışıp kalmış bir geliştiricide olmayan bir perspektif kazandırıyor. Go’nun hata yönetimi yaklaşımını PHP’de taklit etmek istemiyorum, ama o yaklaşımı görmüş olmak hata tasarımı hakkında daha net düşünmemi sağlıyor.

Maliyet gerçek, getiri de gerçek. Bağlam değiştirme bedelini görmezden gelmek değil, farkında olmak ve yönetmek gerekiyor. Yönetilemeyen bir maliyet zamanla fark edilmeden biriküyor — çıktının kalitesinde değil, bunu sürdürmek için harcanan enerjide.