On yıl sonra hâlâ çalışan yazılım

Yazılımların çoğu on yıl için değil, demo için inşa edilir. Teslim günü çalışır, sonra her yıl değiştirilmesi daha pahalı hâle gelir; ta ki kimse neden böyle olduğunu bilmeyene kadar. Bu metin öbür türü anlatıyor: on yıl sonra da hâlâ çalışan — ve on yıl sonra da hâlâ güvenle değiştirilebilen sistemleri.

“On yıl”, “değişmeden” demek değildir. On yıl boyunca dokunulmadan ayakta kalan yazılım ya önemsizdir ya da ölüdür. Kastedilen başka bir şey: Sistem hâlâ çalışıyor, hâlâ makul maliyetlerle değiştirilebiliyor, hâlâ anlaşılabiliyor ve hâlâ işletilebiliyor. Uzun ömürlülük, kodun ilk gündeki bir özelliği değildir. Yıllar boyunca her değişikliğin maliyetinin bir özelliğidir.

Bu yüzden soru teknik değildir. Hiçbir framework ya da dil yazılımı uzun ömürlü kılmaz — bunu, ondan önce verilen kararlar yapar: sınırların nerede olduğu, neyin neye bağlı olduğu, neyin geri alınabilir kaldığı ve “neden”in korunup korunmadığı.

Yazılımların çoğu neden pahalılaşır

Yazılım bir kez yazılır, on yıl boyunca okunur ve değiştirilir. Maliyet neredeyse hiçbir zaman yazmakta değildir. Değiştirmektedir — ve en pahalı değişiklik, her yere aynı anda dokunmak zorunda olandır.

Sistemler nadiren tek bir yanlış karar yüzünden pahalılaşır. Birikim yüzünden pahalılaşırlar: controller'lara, model'lere ve view'lara dağılmış iş mantığı; artık kimsenin kavrayamadığı bağımlılıklar; gerekçesi kaybolmuş kararlar; production onları gösterene kadar kimsenin bilmediği hata durumları. Bu ayrıntıların her biri tek başına zararsızdır. Birlikte, küçük bir iş değişikliğinin büyük bir teknik değişikliğe dönüştüğü — ve artık kimsenin bunun başka neyi bozacağını kesin olarak söyleyemediği noktaya götürürler.

Ortak kök neredeyse her zaman aynıdır: Sistem on yıl için değil, lansman için optimize edilmiştir. Fatura daha sonra gelir — her yıl artan değişiklik maliyetleri olarak.

Bu yüzden tavsiye rahatsız edicidir: İlk teslimatın hızına değil, değişikliğin maliyetine göre optimize edin. Bunun bedeli gerçektir. Başta daha yavaş ve daha pahalıdır; lansmana göre optimize edilmiş bir sistem daha erken biter ve başlangıçta daha ucuzdur. Gerçek tek kullanımlık prototiplerde, bir kenara atılacak bir pazar testinde ve kaçırılması ürünü anlamsız kılacak katı bir dış son tarihte farklı karar veririz. Orada demoya göre optimize edilir — ve prototipin yanlışlıkla production'da yaşlanmasına izin vermek yerine yeniden yazım baştan planlanır.

Şema: Bağımlılık, bir değişikliğin etki alanını belirler.

Yazılımın uzun vadeli bakımını kolaylaştıran özellikler

Yazılım, anlaşılabilir ve değiştirilebilir kaldığında iyi yaşlanır. Geri kalan her şey bundan çıkar. Bunun başarılıp başarılamayacağını iki kuvvet belirler: bağımlılık (coupling) ve kaybolan bağlam. Bağımlılık arttıkça her değişiklik geniş alana yayılır. Bağlam kayboldukça her değişiklik bir bilmeceye dönüşür. Kod stili, biçimlendirme ve dil seçimi bunların yanında ikincildir.

Somut olarak, tipik bir değişikliğin yerel kaldığı, temel mimari kararların az ve gerekçeli olduğu, sınırların korunduğu, hata durumlarının bilindiği ve yeni bir kişinin “neden”i hâlâ okuyabildiği sistemler iyi yaşlanır. Bunlar stil meseleleri değil, yapının özellikleridir.

Teknoloji seçimi de buna dâhildir. Yenilik yerine olgun teknolojiyi tercih ediyoruz — temkinden değil, sınırları bilindiği ve beş yıl sonra da onu anlayan birileri olacağı için. Bedeli: Daha yeni araçların avantajlarından vazgeçilir ve daha yeni bir aracın kolaylık sunacağı yerlerde zaman zaman daha fazlası elle yazılır. Olgun bir seçenek katı bir gereksinimi kanıtlanabilir biçimde karşılamıyorsa — ya da yeni olan bu somut problem için çoktan olgun, anlaşılmış seçim hâline gelmişse — farklı karar veririz. “Olgun”, eski ve sahipsiz değil, anlaşılmış ve bakımı yapılan demektir; meselenin tamamı bu ayrımdır.

Uzun ömürlü sistemlerden gözlemler

Sistemlere yıllarca eşlik eden, aynı örüntülerin dilden, sektörden ve ekipten bağımsız olarak tekrar ettiğini görür. Hikâyeler değil, gözlemler:

• En sık değişen parçalar nadiren esneklik eklenmiş olanlardır. Hareketlilik hiç ihtiyaç duyulmayan yerde, katılık ise değişiklik yapılması gereken yerde oluşur.
• Bir sistemin gerçek sınırları mimari diyagramında değil, olaylarında (incident) görünür.
• İlk kaybolan “neden”dir; ikinci kaybolan, bunu kime sorabileceğinizdir.
• Veritabanı, üzerindeki her uygulama katmanından daha uzun yaşar. Şema kararları, tüm sistemin geri alınması en zor kararlarıdır.

Ayakta kalan mimari kararlar

Bütün kararlar aynı değildir. Bazıları taşıyıcıdır — sistemin sınırlarının nereden geçtiğini, domain'in ne olduğunu, neyin neye bağlı olduğunu ve neyin daha sonra değiştirilebileceğini belirler. Bu kararlar az sayıda, bilinçli olarak verilmiş, yazıya dökülmüş ve modadan bağımsız olduklarında ayakta kalır. Geri kalanı ucuza değiştirilebilen ayrıntılardır.

İlk taşıyıcı karar iş mantığıyla ilgilidir. İş mantığı, framework'ten bağımsız olarak domain'e aittir. Framework altyapıdır — HTTP'nin, kalıcılığın ve teslimatın gerçekleştiği yer —, iş kurallarının yeri değil. Bu ayrımın bedeli dolaylılıktır: daha fazla kod, bakımı yapılması gereken bir soyutlama ve doğrudan framework içinde çalışılmadığı için başta daha düşük özellik geliştirme hızı. Küçük, kısa ömürlü araçlarda ve özünde framework'ten başka bir şey olmayan uygulamalarda — örneğin saf bir CRUD arayüzü — farklı karar veririz. Orada framework'e bağımlılık bir hata değil, yerinde bir sadeliktir.

Şema: Bağımlılıklar içe doğru yönelir; domain hiçbir şeye bağlı değildir.

İkincisi sistemin bölünmesiyle ilgilidir. Varsayılan tercihimiz modüler monolittir: tek bir deployable, içeride net modül sınırları. Dağıtık servislere kıyasla bedeli: Ekipler ve parçalar bağımsız olarak ölçeklenemez ve kötü sınırlandırılmış bir modül diğerlerini etkileyebilir; modül sınırları yalnızca disiplinle korunur, çünkü onları teknik olarak zorlayan hiçbir şey yoktur. Bölünme için gerçek, kalıcı nedenler olduğunda — tek tek parçaların bağımsız ölçeklenmesi, ekipler arasındaki örgütsel sınırlar, düzenleyici yalıtım — farklı karar veririz. O zaman böleriz, ama ilke gereği değil, bu gerçek sınırlar boyunca.

Bu kararların ayakta kalmasını sağlayan, doğruluklarından çok görünürlükleridir: Açıkça verilmiş ve gerekçelendirilmişlerdir, kendiliğinden ortaya çıkmamışlardır. Kimsenin taşıyıcı olarak tanımadığı taşıyıcı bir karar en tehlikelisidir — çünkü kimse onu gözetmez.

Geri alınabilirlik neden önemlidir

Geleceği tahmin etmiyoruz; değişikliği ucuz tutuyoruz. Bu alçakgönüllülük değil, on yıl boyunca dayanan tek tutumdur, çünkü yarının gereksinimlerini bugün kimse bilmez. Doğru tahmine bahse girmek yerine, yanlış bir varsayımın ucuza düzeltilebileceği şekilde tasarlıyoruz.

Anahtar, kolayca geri alınabilen kararları alınamayanlardan ayırmaktır. Kolayca geri alınabilen bir karar hızla verilir ve gerektiğinde düzeltilir. Geri alınması pahalı olan bir karar — herkese açık bir veri formatı, dışarıya karşı bir sözleşme, kalıcılık modelinin seçimi — yavaş verilir ve “neden”i yazıya dökülür.

Tavsiye: Şüphe durumunda geri alınabilir seçeneği seçin ve geri dönüşsüz olanları, etki alanları sınırlı kalsın diye sınırların arkasında kapsülleyin. Bedeli, geri alınabilir bir tasarımın bugünkü durum için nadiren en uygun olmasıdır — belki hiç ihtiyaç duyulmayacak bir arayüz ya da ek bir çağrıya mal olan bir sınır. Denenmiş, istikrarlı ve değişmeyecek bir gereksinimde — zorunlu bir format, sabit bir yasal kural — farklı karar veririz. Orada soyutlama israftır; doğrudan sabitlenir.

Şema: Geri alınabilir olan hızlı; geri dönüşsüz olan kapsüllenmiş ve gerekçeli.

Geri alınabilirliğin çoğu zaman unutulan ikinci bir yarısı vardır: kayda geçirilmiş “neden”. Gerekçesi kaybolmuş bir karar güvenle geri alınamaz, çünkü artık kimse onun başlangıçta neyi tarttığını bilmez. Bu yüzden “neden”i yazıya dökmek evrak işi değil, geri alınabilirliğin kendisinin bir parçasıdır.

Testin rolü

Testlerin amacı bir kapsama (coverage) oranına ulaşmak değildir. Amaçları değişikliği güvenli kılmaktır. Bir testin değeri, var olmasıyla değil, izin verdiği değişiklikle ölçülür. Önemsiz kod üzerinde yüksek kapsama hiçbir şey kazandırmaz; en pahalı kural üzerindeki tek bir test, sonraki her değişiklikte huzur kazandırır.

Bu yüzden hataların pahalı olduğu yerde test ediyoruz: iş çekirdeğinde ve kırılmasının gerçek zarar verdiği yollarda. En zor yolu, genişlik oluşmadan önce, erkenden ve uçtan uca kanıtlıyoruz — risk sonda keşfedilmez, başta ortadan kaldırılır.

Bedeli, her testin kendisinin de bakımı yapılan kod olmasıdır. Fazlası değişikliği yavaşlatır ve belki henüz atılmak istenen bir tasarımı betonlaştırır; azı her değişikliği bir cesaret sınavına çevirir. Tek kullanımlık kodda ve sonucu henüz belli olmayan keşif amaçlı spike'larda farklı karar veririz — orada henüz test yapılmaz, çünkü neyin kalacağı henüz belli değildir. Bir şey kalıcı olduğu ve kırılması pahalı olduğu anda test gelir.

Dokümantasyonun rolü

Kod, sistemin ne yaptığını söyler. Neredeyse hiçbir zaman neden başka türlü değil de böyle inşa edildiğini söylemez. Tam da bu “neden” ilk kaybolan şeydir ve kaybı sonraki her değişikliği tahmin oyununa çevirir. Bu yüzden kalıcı dokümantasyon eksiksiz olan değil, kararları ve bunların avantajlarını ve sınırlamalarını kayda geçirendir.

Tavsiye: Her fonksiyonu değil, kararları ve avantajlarını ve sınırlamalarını belgeleyin — kısa decision record'lar. Bedeli zamandır ve dokümantasyon eskiyebilir; yanlış bir doküman hiç olmamasından kötüdür, çünkü yanıltır. Kolayca geri alınabilen kararlarda farklı karar veririz: Değiştirmesi hiçbir şeye mal olmayan şey bir kayda değmez.

Sonuç vazgeçmek değil, odaklanmaktır: Yavaş olanı — kararları, sınırları, işletimi — belgeliyoruz; zaten sürekli değişen uygulama ayrıntılarını değil. Hızlı olan üzerine yazılmış dokümantasyon yazıldığı günün ertesinde yanlıştır; yavaş olan üzerine yazılmışsa yıllarca dayanır.

İşletimin rolü

Yazılım lansmanla bitmez. On yıl çalışması gereken bir sistem on yıl işletilir — ve bu süreye ulaşıp ulaşmayacağını işletim de belirler. Hata durumları bilinmeyen bir sistem bitmiş değildir, yalnızca henüz göze çarpmamıştır.

Bu yüzden iki şey ilk olaya değil, başlangıca aittir. Birincisi gözlemlenebilirlik (observability): Bir şeyler ters gitmeden önce içeride ne olduğunu dışarıdan görebilmek gerekir. İkincisi hata durumu için tasarım: Production cevabı zorla öğretmeden önce, bir bağımlılık devre dışı kaldığında sistemin nasıl davrandığı prova edilir.

Şema: Gözlemlenebilirlik, eşik bir kesintiye dönüşmeden önce sinyali gösterir.

Asıl sınav sakin gün değil, sistemi inşa etmemiş birinin gece saat üçte ele aldığı olaydır. Baskı altında kimse tasarımının düzeyine yükselmez; hazırlanmış olanın düzeyine düşer. O zaman dört şey belirleyicidir: ne olduğunun görülebilmesi (gözlemlenebilirlik); hasarın yayılmak yerine sınırlı kalması (yalıtım, küçük etki yarıçapı); son değişikliğin hızla geri alınabilmesi (geri alınabilir teslimat); ve doğaçlama yerine prova edilmiş bir yol olması. Kesintilerin çoğu yükü değil bir değişikliği izlediği için, en hızlı toparlanma neredeyse her zaman değişikliği geri almaktır — bu da değişikliklerin küçük ve geri alınabilir olmasını gerektirir.

Tavsiye: Gözlemlenebilirliği ilk günden inşa edin ve sistemi baskı altında yöneten insan için tasarlayın — net sinyaller, küçük etki yarıçapı, hızlı rollback, prova edilmiş hata durumu. Bedeli, iyi bir günde hiçbir şey üretmeyen emektir: enstrümantasyon, rollback mekanizması, prova edilmiş kesintiler, biraz gecikme. Kesintileri tolere edebilen sistemlerde — örneğin bir iç araç — farklı karar veririz. Orada derinlik daha az olabilir, ama sinyaller kalır; iç araç da gece üçte takıldığında anlaşılabilir olmalıdır.

Buna teslimatın kendisi de dâhildir: küçük, geri alınabilir adımlar, erişilebilirliğin önemli olduğu yerde kesinti süresi olmadan. Bedeli daha fazla teslimat mekanizmasıdır; kısa bir bakım penceresinin kabul edildiği ve sadeliğin belirleyici olduğu yerde farklı karar veririz.

Standartların rolü

Standartlar ortak geleneklerdir — yaygın formatlar, bilinen arayüzler, tek tek insanlardan daha uzun yaşayan sınırlar. Uzun ömürlülük için değerleri iki yönlüdür: Yeni bir kişinin sistemi anlama maliyetini ve bir parçanın değiştirilme maliyetini düşürürler. Bilinen yapı taşlarından oluşan bir sistem için beş yıl sonra da eleman bulunabilir; baştan sona kendi yapımı çözümlerden oluşan bir sistemin ise önce yeniden öğrenilmesi gerekir.

Tavsiye: Kendi çözümleriniz yerine sıkıcı, yaygın arayüzleri ve gelenekleri — HTTP, SQL, yerleşik formatlar — tercih edin. Bedeli, bir standardın nadiren kusursuz oturması ve tam o duruma özel bir çözümün daha verimli olabilmesidir; biraz verimsizlik ve belli bir kısıtlama göze alınır. Standardın ölçülebilir biçimde sorunun kendisi olduğu kanıtlanmış bir darboğazda farklı karar veririz — orada tüm sistemde değil, yerel olarak ve bir sınırın arkasında optimize edilir.

Bir kod tabanı içindeki tutarlılık da bir standarttır. Her yerde aynı biçimde uygulanan bir kural, her nokta için en iyi tekil çözümden daha değerlidir, çünkü sistemi bir bütün olarak okunabilir tutar.

İnsanlar değişir. Yazılım kalır.

On yıl içinde bir ekip tamamen değişir. Bir sistemi inşa eden insanlar, sistemden çok önce ayrılır — ve onlarla birlikte yalnızca kafalarda duran bilgi de gider. Bu yüzden anlaşılabilirlik haleflere karşı bir nezaket değil, yazılımın yazarlarından daha uzun yaşamasının koşuludur.

Sınav zorludur: Yetkin bir yabancı, özgün yazarlardan hiçbiri olmadan, yalnızca koddan, kararlardan, sınırlardan ve işletimden yola çıkarak bir değişikliği güvenle yapabilir mi? Cevap “ancak X'e sorarsanız” ise sistem kendi üzerinde değil, bir kişinin üzerinde durur. O zaman her ayrılış bir risk, her işe alım aylarca süren bir arkeoloji olur.

Tavsiye: Henüz aranızda olmayan okur için yazın — şeyleri ne yaptıklarına göre adlandırın, “neden”i kayda geçirin, sınırları açık tutun, zekâ gösterisine yalnızca kendini açıkladığı yerde izin verin. Bedeli, bunun kendiniz için yazmaktan daha yavaş olması ve özgün ekip hâlâ yerindeyken gereksiz görünmesidir. Yalnızca yazarının tek okuru olarak kalacağı kısa ömürlü kodda farklı karar veririz. On yıla ulaşması gereken her şey yabancılar için yazılır.

Sık yapılan hatalar

Yazılımı vaktinden önce pahalı kılan, hep aynı örüntülerdir:

Değişiklik maliyetleri yerine lansmana göre optimize etmek. İş mantığını domain yerine controller'lara ve model'lere koymak — her iş değişikliği teknik bir değişikliğe dönüşür. Erken dağıtma: mikroservisleri ve soyutlamaları somut bir soruna cevap olarak değil, başlangıç noktası olarak kullanmak. Gereksiz yere framework'e bağımlı olmak. Teknolojiyi bağlama ve ömre göre değil, modaya göre seçmek. Kararlar hiç kayda geçirilmediği için kaybolan “neden”. Ve test konusunda iki yanlışı birden yapmak — her şeyi test edip tasarımı betonlaştırmak ya da hiçbir şeyi test etmeyip her değişikliği bir cesaret sınavına çevirmek.

Bu hataların hiçbiri ilk gün görünmez. Hepsi sonradan görünür hâle gelir — kimsenin planlamadığı değişiklik maliyetleri olarak.

Karmaşıklık ne zaman tehlikeli hâle gelir

Karmaşıklık kendiliğinden oluşur. Sadelik ise tasarlanmalıdır. Bu yüzden temkinin yönü açıktır: İhtiyaç duyulmadan önce yapı eklemeyiz ve taşıyan yapıyı kaldırmayız.

Karmaşıklık, gerçek bir problemin bedelini ödemediğinde tehlikeli hâle gelir — belki hiç gelmeyecek bir gelecek için eklendiğinde: henüz var olmayan ikinci kullanım senaryosu için bir soyutlama, ölçülmemiş bir yük için dağıtık bir sistem, kimsenin planlamadığı bir sağlayıcı değişikliği için bir arayüz. Bu öngörülerin her biri anlaşılabilirlikten kalıcı olarak bir şey götürür ve ancak tahmin edilen gelecek gerçekleşirse karşılığını verir.

Tavsiye: Karmaşıklığı yalnızca bugün var olan, adı konmuş bir probleme karşı ekleyin. Bu ölçülülüğün bedeli, zaman zaman sonradan baskı altında eklemeler yapmak zorunda kalmaktır — bir sınırı sonradan çekmek, onu baştan sahip olmaktan daha pahalıdır. Gelecekteki ihtiyaç neredeyse kesinse ve şimdi eklenmesi ucuzsa farklı karar veririz: bilinen ikinci bir pazar, sözleşmeyle taahhüt edilmiş bir entegrasyon. O zaman ek yeri erkenden konur — ama bir hisse karşı değil, somut bir şeye karşı.

Kontrol listesi

Bir CTO'nun kendi sistemine sorabileceği sorular. Bunlar hüküm değil, teşhis sorularıdır — cevaplar sistemin “geçip geçmediğini” değil, nerede durduğunu söyler.

• Tipik bir değişiklik yerel mi kalıyor, yoksa yayılıyor mu? Yayılma, fazla yüksek bağımlılığın ilk işaretidir.
• Temel mimari kararların neden böyle verildiğini hâlâ söyleyebiliyor muyuz? “Neden” kaybolduysa her değişiklik bir bilmecedir.
• İş mantığı framework'ten bağımsız mı? Değilse her iş değişikliği bir altyapı değişikliğine dönüşür.
• Hangi kararlar geri dönüşsüz — ve kapsüllenmişler mi? Sınırı olmayan geri dönüşsüzlük en büyük risktir.
• Kırılması pahalı yollar test ediliyor mu — ve yalnızca onlar mı? Hem fazlası hem azı değişikliği zorlaştırır.
• Hata durumları biliniyor ve prova ediliyor mu? Bilinmeyen bir hata durumu, henüz yaşanmamış bir kesintidir.
• Yeni ve deneyimli bir kişi sistemi yazılı olanlardan anlayabilir mi? Anlayamıyorsa sistem kafalara bağlıdır.
• Bedelini ödeyen güncel bir problem olmadan var olan karmaşıklık var mı? Böyle bir karmaşıklık saf kayıptır.
• İnşa ettiğimiz şeyi işletiyor muyuz — ilk günden gözlemlenebilirlikle? İşletim, on yılı birlikte belirler.
• Bir parça, bütünü yeniden yazmadan değiştirilebilir mi? Değiştirilebilirlik, sınırların pratik sınavıdır.

Sıkça Sorulan Sorular

Uzun ömürlü, artık hiçbir şeyin değiştirilmemesi demek mi? Tam tersi. Uzun ömürlü, değişikliğin ucuz kalması demektir. Artık dokunulamayan bir sistem uzun ömürlü değil, katılaşmıştır — ve katılaşmış sistemler dünya ilerlediği anda yerlerini başkalarına bırakır.

Olgun teknoloji bir risk değil mi? Yalnızca olgunluk eski ve sahipsiz olmakla karıştırılırsa. Olgun demek: anlaşılmış, bakımı yapılan, sınırları bilinen. Risk daha çok tersindedir — sınırlarını henüz kimsenin bilmediği ve beş yıl sonra belki kimsenin bakımını yapmayacağı yeni teknolojide.

Bu düpedüz daha pahalı değil mi? Başta evet. On yıl boyunca hayır, çünkü değişiklik maliyetleri kontrolden çıkmaz. Ama dürüst cevabın bir koşulu var: Yazılımın on yılı görmesi hiç amaçlanmıyorsa bunun için ödeme yapmayın. Tek kullanımlık bir prototip için uzun ömürlülük yanlış yatırımdır.

Mikroservisler uzun ömürlülüğe giden yol mu? Kendiliğinden değil ve orta büyüklükteki sistemler için çoğu zaman tam tersi. Dağıtım, yalnızca somut bir problemin — bağımsız ölçekleme, örgütsel ya da düzenleyici sınırlar — haklı çıkardığı işletim ve bağımlılık maliyetleri ekler. Bu problem olmadan dağıtım ömrü uzatmaktan çok kısaltır.

Ne kadar dokümantasyon gerekir? Yavaş şeylerin — kararların, sınırların, işletimin — “neden”ini korumaya yetecek kadar. Daha fazlası değil. Hızlı uygulama ayrıntıları üzerine yazılmış dokümantasyon ertesi gün yanlıştır ve o zaman zarar verir.

Yazılımın on yıl çalışacağını garanti edebilir misiniz? Hayır ve bunu garanti eden soruyu anlamamıştır — garanti edilemez, çünkü dünya değişir. Tasarlanabilir ve onu neyin bozacağı adlandırılabilir: kaybolan “neden”, kontrolsüz büyüyen bağımlılık, bilinmeyen hata durumları, problemi olmayan karmaşıklık. Biz bu dördüne karşı inşa ediyoruz. Bu bir garanti değil, ama umut ile mühendislik arasındaki farktır.

İleri okuma

Bu metin temeli oluşturuyor; aşağıdakiler buradaki tek tek kararları derinleştiriyor:

• Öngörüden önce geri alınabilirlik — geleceği bilmediğinizde belirsizlik altında nasıl karar verilir.
• Modüler monolit — ne zaman doğru seçimdir, ne zaman değildir.
• Framework'ten bağımsız domain mantığı — iş kurallarının neden controller'a ait olmadığı.
• Hataların pahalı olduğu yerde test etmek — dogmasız bir test stratejisi.
• İlk günden gözlemlenebilirlik ve Hata durumu için tasarım — tasarımın bir parçası olarak işletim.
• Yenilikten önce olgun teknoloji — neden modayı izlemediğimiz.
• Laravel mi Symfony mi — dürüst bir mimari karşılaştırma, uzun vadeli bir teknoloji seçiminin somut örneği olarak.

Hepsinin temelinde Batunet Manifestosu ve Batunet Engineering Method yer alır.

Uzun ömürlü yazılımın sınavını koymak kolay, geçmek zordur: Bugün orada olmayan biri, beş yıl sonra sistemi güvenle değiştirebilir mi? Evetse iş iyi yapılmıştır. Bu ona bakınca anlaşılmaz — sadece çalışır.