Batunet'in bilgi tabanı.
Blog yazıları değil, somut mühendislik sorularına sağlam yanıtlar. Bir soru, bir sayfa, bir yanıt.
Varlık grafiğinin statik bir haritası: her varlık bir düğüm, her ilişki bir kenar; kümeler türe göre gruplanmış.
Bilgi grafiği →Tüm bilgi tabanı, tek bir yerde.
Konuya göre arayın ya da içerik türüne ve kategoriye göre filtreleyin.
İçerik türü
Kategori
60 sonuç
On yıl sonra hâlâ çalışan yazılım
Hangi mühendislik kararları yazılımı on yıl boyunca ayakta tutar — bağımlılık (coupling), geri alınabilirlik, işletim, standartlar. Pazarlama yerine ödünleşimlerle.
Öngörüden önce geri alınabilirlik
Geleceği öngöremezsiniz; bu yüzden ona bahse girmek yerine değişikliği ucuz tutun. Hangi kararlar yavaşlatılmalı ve geri alınabilir biçimde kurulmalı.
İş mantığı controller'a ait değildir
İş kuralları neden controller'a değil, framework'ten bağımsız bir domain katmanına aittir: belirtiler, bakım maliyetleri, test edilebilirlik, migrasyon.
Kalıcı veri modellemesi
Veri modeli framework'ü, arayüzü ve veritabanını aşar: Neden alan modellenir, değişim için tasarlanır ve yanlış bir model neden bu kadar pahalıdır.
Üretim sistemlerinde yapay zeka — demo değil, mühendislik
Yapay zeka demosundan güvenilir bir üretim sistemine uzanan uzun yol: değerlendirme, hata modları, guardrail'ler — olasılıksal olanı deterministik olanla çevrelemek.
Bir mimari özellik olarak güvenlik
Güvenlik sonradan eklenen bir fonksiyon değil, tasarımın bir özelliğidir: tehdit modellemesi, en az yetki, derinlemesine savunma, güvenli varsayılanlar.
Hata durumu için tasarlamak
Hata modları bilinmeyen bir sistem bitmiş değildir: hataları önlemek yerine sınırlamak, güvenle yeniden denemek, zarifçe kademelendirmek, hata durumunu prova etmek.
Uzun ömürlü kurumsal sistemler için Symfony
Symfony'nin açıklığı, bileşenleri ve istikrar kültürü neden uzun ömürlü kurumsal sistemleri taşır — ve Laravel nerede daha uygun tercih olarak kalır.
Modüler monolit mi, mikroservisler mi?
Bir inanç savaşı değil, karmaşıklığın nereye dağıtılacağına dair bir karar: Modüler monolit nedir ve mikroservisler ne zaman nesnel olarak daha iyidir?
Yapay zeka ne zaman yanlış çözümdür
Yapay zeka geliştiren bir şirketten: yapay zeka ne zaman yanlış tercihtir. Bir problemin hangi biçime ihtiyaç duyduğu, bir kuralın neden çoğu zaman üstün olduğu, yanlış yerdeki yapay zekanın neye mal olduğu.
Yenilikten önce olgun teknoloji
Modaya uymadan teknoloji seçimi: Olgunluk neden başkalarının hataları çoktan bulmuş olması demektir — yeni olan neyi gizler, buna rağmen ne zaman doğrudur. Bağlam ve kullanım ömrü.
Build, Buy ya da Configure — özel yazılım ne zaman kârlıdır
Kendin geliştir, satın al ya da yapılandır — cevap 'satın al' olsa bile dürüstçe. Ölçüt: farklılaşma ve ömür, gizli maliyetler.
Güvenilir yapay zeka yanıtları — bağlam ve kaynaklar için mimari
Bir yapay zeka yanıtı güvenilir, güncel bağlama ve izlenebilir kaynaklara nasıl dayandırılır; böylece yalnızca akıcı değil, doğru ve kanıtlanabilir olur.
Uzun ömürlü sistemler için PostgreSQL mi MySQL mi
Her iki veritabanı da olgundur ve bir sistemi yıllarca taşır. Ortak yanları, gerçekte nerede ayrıştıkları — sıralamaya göre değil, verinin biçimine ve ekibe göre karar vermek.
Yazılım projeleri gerçekte neden başarısız olur
Yazılım projeleri nadiren teknoloji yüzünden başarısız olur; mühendislik kararları, problem anlaşılmadan önce geri dönüşsüz hâle geldiği için başarısız olur.
Sunucu taraflı render mı, SPA mı
Sunucu taraflı render mı, SPA mı — on yıllık bakım kolaylığını belirleyen frontend seçimi. Modaya göre değil, etkileşim düzeyine ve ömre göre.
Kurumsal sistemler için Laravel
Laravel, uzun ömürlü ve iş açısından kritik sistemler için ne zaman doğru seçimdir — ve ne zaman değildir: mimari, sürdürülebilirlik, ölçeklenmenin gerçekleri, işletim, ekip.
Uzun ömürlü sistemler için Laravel yükseltmeleri
Bir Laravel sistemini sıçrama korkusu yaşamadan yıllarca güncel tutmak: ertelenen yükseltmeler bir tehlike olarak, sıçrayarak değil sürekli ilerlemek, testler bir güvenlik ağı olarak.
Dağıtık sistemlerde idempotency
Dağıtık sistemler neden mükerrer mesajlara dayanmak zorundadır ve onları nasıl mükerrer işlemleri önleyen (idempotent) hâle getirirsiniz: idempotency key'ler, yeniden denemeler, outbox ve inbox.
Uzun ömürlü sistemler için API tasarımı
Kullanıcılarının sistemlerini bozmadan yıllarca ayakta kalan API'ler nasıl tasarlanır: sözleşmeler, uyumluluk, sürümleme, hatalar, evrim.
REST, GraphQL mi, RPC mi: API stilinin seçimi
API stilini modaya göre değil uyuma göre seçmek: REST, GraphQL ve RPC'yi neyin ayırdığı, hangi problem biçiminin hangi stile uyduğu ve her birinin bedeli.
Müşterileri kırmadan API sürümleme
Müşterilerin sistemlerini kırmadan bir API yıllarca nasıl geliştirilir: uyumlu genişletmek, düzgün sürümlemek, bir süreç olarak deprecation.
Big bang olmadan legacy modernizasyonu
Canlı bir sistem yeniden yazım yerine artımlı ve geri alınabilir biçimde nasıl değiştirilir: Strangler Fig, Anti-Corruption Layer, veri taşıma, paralel işletim.
Bir legacy sistemi devralmak — ilk 90 gün
Sizin geliştirmediğiniz bir sistemi devralmak: değiştirmeden önce anlamak, ilk müdahaleden önce güvenlik ağları, sistemin haritası, davranışı kayıt altına almak.
Rewrite ne zaman yanlış karardır
Bir rewrite neden gömülü bilgiyi çöpe atar ve hareketli bir hedefin peşine düşer, yeniden yazım ne zaman yine de doğrudur — ve kademeli yenileme neden neredeyse her zaman daha iyidir.
Agentic Coding — yazılım geliştirme orkestrasyona dönüştüğünde
Agentic coding, yazılım geliştirmedeki darboğazı kaydırır: kodu yazmaktan, işi tanımlamaya, doğrulamaya ve sorumluluğunu üstlenmeye.
Testler ne zaman gerçekten karşılığını verir?
Getirisi değişen bir yatırım olarak test: Testler nerede değer yaratır, nerede faydadan çok bakım yükü üretir? Kapsam dogması olmadan.
Observability bir mimari meselesidir
Davranışını açıklayamayan bir sistem neden güvenle işletilemez — observability bir araç değil, bir mimari özellik olarak.
Kesintisiz veritabanı migrasyonları
Üretimdeki veritabanları durdurulmadan nasıl geliştirilir: Expand/Contract, geriye dönük uyumlu şema evrimi, deploy sırası, backfill'ler, geri alma.
Caching bir performans özelliği değildir
Caching bir optimizasyon değil, bir mimari karardır — gecikmeye karşı tutarlılık. Asla önbelleğe alınmaması gerekenler, invalidasyon, katmanlar, hata modları.
5000 satır kopyala-yapıştır
Bir Mühendislik Hikâyesi: Yaklaşık 5000 satırlık kopyalanmış kod nasıl oluştu, tekrarın pahalı hâle geldiği anı neden kimse fark etmedi — ve kodu yaklaşık onda birine indirmek bize DRY hakkında ne öğretti.
Bu iş çabucak yapılır.
Bir Mühendislik Hikâyesi: Tek bir cümle neden güvenilir bir uyarı işaretine dönüştü ve Batunet bu şekilde başlayan projeleri bugün neden bilinçli olarak reddediyor. Atlanamayacak analiz ve mimarinin değeri üzerine.
Bir kez kopyalamaya başlayınca.
Kopyalamanın kendi dinamiği üzerine bir Mühendislik Hikâyesi: Savunulabilir bir ilk kopyadan nasıl yaklaşık 5000 satır neredeyse aynı kod ortaya çıktığı, tehlikeli kararın neden ilk kopya değil, ikincisinde verilmeyen karar olduğu — ve kodu yaklaşık onda birine indiren konsolidasyonun bize doğru zamanlama hakkında ne öğrettiği.
Yeniden yazmadan gerçek zamanlılık
Bir Mühendislik Hikâyesi: Yıllar içinde büyümüş bir sistemin birden gerçek zamanlı güncellenmesi gerekiyordu — mimarisinin hiç tasarlanmadığı bir gereksinim. Cevabın neden yeniden yazım değil, tek bir veri akışının hedefli olarak yeniden kurgulanması olduğu. Yerel bir gereksinim ile küresel bir yeniden yapılanma arasındaki fark üzerine.
Yönü erken değiştirmek
Bir Mühendislik Hikâyesi: Plan, mevcut bir sistemi genişletmekti. Çalışma sırasında her yeni işlevin karmaşıklığı artıracağı görüldü. Plana bağlı kalmak yerine yön değiştirildi ve işlevler bağımsız API'ler olarak ayrıştırıldı. Geçerliliğini yitirmiş bir planı savunmanın maliyeti üzerine.
Ürün olmayan prototip
Bir Mühendislik Hikâyesi: Bir müşteri yalnızca bir fizibilite kanıtı istedi. Ortaya kullanılabilir bir arayüz çıktı. Ardından proje durduruldu. Fizibilite çalışması ile ürün geliştirme arasındaki fark ve bu farkın neden en baştan adının konması gerektiği üzerine.
Migrasyon bir güven sorunudur
Bir Mühendislik Hikâyesi: Birden fazla sunucuyu, veritabanını, yedeği ve bir sağlayıcı değişikliğini kapsayan büyük bir altyapı migrasyonu. Asıl zorluk teknik değil, hiçbir şeyin unutulmadığından emin olmaktı. Bir güven sorunu olarak migrasyonlar üzerine — ve güveni ummak yerine nasıl inşa edeceğiniz üzerine.
Arayüzler, implementasyonlardan uzun yaşar
Bir Engineering Story: Harici bir API sağlayıcısı değiştirildi. Milyonlarca mevcut kayıt, uyumsuz yeni bir yapı — ardından eşleme, taşıma ve doğrulama geldi. Neden kalıcı olanın arayüz, geçici olanın ise arkasındaki implementasyon olduğu.
Yazılım asla bitmez
En uzun süredir devam eden müşteri projesinden bir Mühendislik Hikâyesi: Gereksinimler sürekli değişir, yazılım asla bitmez — ve buna verilebilecek tek sağlam yanıt, değişikliği ucuz kılan bir mimaridir. Bir son durum fikrinden vazgeçmek üzerine.
Karmaşıklık eklemek yerine kaldırmak
Bir Engineering Story: Harici API bileşenleri monolitin içine gömülüydü. Bunlar ayrıştırılıp bağımsız API'lere dönüştürüldü — sonuç daha net bir mimari ve bağımsız ölçeklenme oldu. Çıkarmanın neden çoğu zaman eklemekten daha değerli olduğu.
Şema ile model birbirinden uzaklaştığında
Bir Mühendislik Hikâyesi: Birden fazla ekibin çalıştığı büyük bir projede bir hata inatla sürdü. Nedeni küçüktü — veritabanı şeması değişmiş, ORM eşlemesi değişmemişti. Veritabanı ile model arasındaki küçücük uyumsuzlukların neden orantısız büyük sorunlar yarattığı.
İyi araçlar güçlendirir
Bir Mühendislik Hikâyesi: Yapay zeka günlük mühendislik işlerine entegre edildi — küçük bir yardımcı olması beklenirken üretkenlikte köklü bir iyileşme olarak deneyimlendi. Heyecana kapılmadan bakıldığında: İyi araçlar neden mühendislerin yerini almak yerine onları güçlendirir — ve bu neden muhakemenin değerini düşürmez, artırır.
En iyi mimari bileşenleri kaldırır
Bir Mühendislik Hikâyesi: Araya yerleştirilmiş yüzlerce API sunucusunun yerini bir proxy mimarisi aldı. Altyapı daha güçlü değil, daha basit hâle geldi. En iyi mimarinin neden çoğu zaman yeni bileşen eklemek yerine bileşenleri kaldırdığı.
Neden çoğunlukla modüler bir monolitle başlıyoruz
Çoğu sistem için modüler monolit daha ekonomik bir tercihtir — ta ki somut bir sınır dağıtık servisleri gerçekten zorunlu kılana kadar.
Erken soyutlama neden karmaşıklık yaratır
Soyutlamalar tekrar eden, somut durumlardan doğmalıdır — bir gün gerekecekleri beklentisinden değil.
Observability neden mimarinin bir parçasıdır
Bir sistemin gözlemlenebilir olup olmadığı tasarım aşamasında belirlenir — ilk incident'te değil.
ADR-001: Başlangıç noktası olarak modüler monolit, kanıt varsa mikroservisler
Dağıtık sistemler gerçek problemleri çözer — bağımsız ölçeklendirme, bağımsız deployment — ancak beraberinde ağ sınırları, eventual consistency ve operasyonel yük getirir. Fayda bu maliyetleri ne zaman haklı çıkarır?
ADR-002: Kritik yolun dışında senkron işleme yerine kuyruk
Senkron yan etkiler yanıt süresini dahil olan en yavaş sisteme bağlar ve bir yan etki başarısız olduğunda isteğin de başarısız olmasına yol açar. Asenkron işleme ayrışma sağlar, ancak beraberinde eventual consistency ve teslimat semantiği getirir.
ADR-003: PostgreSQL içinde JSONB yerine normalize tablolar
JSONB cazip biçimde esnektir, ancak yapıyı ve bütünlüğü veritabanından uygulama koduna taşır. Normalize tablolar yapıyı zorunlu kılar, ancak sık şema değişikliklerinde daha az esnektir.
Legacy bir monoliti modernize etmek
Zamanla büyümüş eski bir sistemi işletimi riske atmadan değiştirmek — big bang yerine adım adım.
Herkese açık bir API tasarlamak
Bir API'yi uzun ömürlü bir sözleşme olarak tasarlamak — sürümlenmiş, belgelenmiş ve kullanıcıları için istikrarlı.
Asenkron işlemeye geçiş
Yan etkileri kritik yanıt yolundan ayırmak — dayanıklı, izlenebilir ve mükerrer işlemleri önleyen (idempotent) biçimde.
Laravel mi, Symfony mi
İki PHP framework'ünün dürüst bir mimari karşılaştırması — kazanan yok, bağlam var.
İdempotans
Birden çok kez çalıştırıldığında da bir kez çalıştırılmış gibi aynı sonucu veren işlem.
OIDC (OpenID Connect)
Kimlik doğrulama ve single sign-on için OAuth 2.0 üzerine kurulu bir kimlik katmanı.
Çoklu kiracılık (multi-tenancy)
Tek bir yazılım örneği, verileri ayrı tutulan birden fazla müşteriye hizmet verir.
Event Sourcing
Durum, güncel bir değer olarak değil, değiştirilemez olayların dizisi olarak saklanır.
DRY (Don't Repeat Yourself)
Her bilgi biriminin sistemde tam olarak tek bir yetkili temsili olmalıdır.
Belirsizlik konisi (Cone of Uncertainty)
Bir efor tahmininin aralığı, projenin başında en geniştir ve ancak anlayış arttıkça daralır.
Üç kuralı (Rule of Three)
İki tekrar tesadüf olabilir; üçüncüsünde benzerlik bir kalıba dönüşür — ve birleştirme zamanı gelir.
On bir alan. Tek bir standart.
Her kategori bütünlüklü bir bilgi kümesidir — temellerden ekiplerin gerçekten verdiği kararlara kadar.
Nereden başlamalı.
Önem sırasına göre — önce temeller, ardından bunların üzerine inşa edilenler.
Projenizi konuşalım.
Satış odaklı sunumlar yok. Doğrudan kurucu ve yönetici ekiple birinci elden iletişim.
