Tan’ın yorumları

Bu kayıt hangisinin daha hızlı olduğunu söylemiyor, hangisinin ne zaman hızlı olduğunu söylüyor. Bence en değerli satır, Mutex'in adaletsizliğinin bir nedene bağlanamadığı hücre. Nedenini bilmediğiniz bir davranışı üretimde varsaymayın, kendi P'nizde ölçün.

Bu, ileriye olduğu kadar geriye de bakan bir ders: daha önce yayımladığınız sayılardan hangilerinin ikinci bir yolu var?

Expand-contract'ın bedeli takvimde ödeniyor: yeniden adlandırma örneğindeki gibi tek bir değişiklik üç deploy'a yayılıyor. Daralt adımı unutulursa eski kolon kalıcı hâle gelir. O adımı, genişlet adımıyla aynı gün ayrı bir iş kaydı olarak açmak, bedelin borca dönüşmesini önler.

Aradaki fark küçüldüğünde framework seçimini hız değil, ekibin o framework’ü ne kadar iyi bildiği belirler. Bu tür bir ölçüm seçimi gerekçelendirmez, yalnızca elenecek adayı gösterir. Ekibinizin hangi adayla hızlı geliştirebildiği tabloda yok.

Bayatlık süresini tek başına mühendis seçmesin. Fiyat güncellendiğinde müşterinin eski fiyatı ne kadar süre görebileceği, ürün tarafının cevaplaması gereken bir soru. Cevabı yazılı alın: "güncelleme en geç şu kadar sürede görünür" cümlesi, destek kuyruğu dolmadan önce elinizdeki sözleşme olur.

Olayı hatırlayan kimse kalmadıysa süreç henüz pranga sayılmaz; olay kayıtlardan yeniden kurulabilir. Kaldırmadan önce o küçük araştırmayı yapmak, kaldırmanın bedelini görünür kılar.

Yeni katılanların sorularını tek bir yerde biriktirin. Aynı soru tekrar tekrar geliyorsa, listedeki hangi sinyalin sizde en ağır bastığına o kayıt işaret edebilir. Bir sadeleştirme önerisini savunurken, bu kayıt yazıdaki sinyallere ekibinizin kendi sorularından bir kanıt ekler.

Hikâyedeki asıl hata Lambda'da değil, "first" kelimesindeydi: karar, iş yükü görülmeden verilmişti. Bir ilkeyi varsayılan yapmak, her yeni servis için sorulması gereken soruyu sizin yerinize cevaplamaktır. Varsayılanınız olsun, ama her servis için gerekçesini yeniden yazın.

İşi kuyruğa attığınızda hatayı kullanıcının ekranından alıp kimsenin bakmadığı bir yere taşımış olabilirsiniz. Kuyruğa giden her iş için, düşerse kimin göreceği ve kimin yeniden deneyeceği baştan belli olmalı. Bu sorunun cevabı yoksa, senkron yolun hatası en azından görünür bir yerde çıkar.

Bir modülün Clean Architecture gerektirip gerektirmediğini anlamanın ucuz bir yolu, o modülün kurallarını framework'ü anmadan yazıya dökmek. Yazılabiliyorsa izole edilecek bir domain vardır. Yazılamıyorsa elinizdeki büyük olasılıkla kaydet-oku işidir.

Numarayı önceden mühürlemek yeni bir soru doğurur: mühürlenmiş ama hiç gitmemiş bir faturayı kim, hangi kayıtla kapatacak? Bu bir kod sorusu olmadan önce bir iş kuralı sorusu. Onu tasarımda sormak, ilk yarım kalan faturadan sonra sormaktan ucuza gelir.

Prefix, uygulamanın kendine koyduğu bir kural; Redis'in uyguladığı bir sınır değil. redis-cli ile açılan bir oturum ya da bir bakım script'i bu kuralı bilmez. Korumanın nereye kadar uzandığını bilerek karar verin: uygulama kodunun dışındaki istemciler prefix'e uymak zorunda değil.

Kuyrukta bekleme süresi ile job'un çalışma süresi ayrı iki ölçüdür. Bekleme uzayıp çalışma süresi yerinde duruyorsa kapasiteye, yani worker sayısına ya da kuyruk ayrımına bakarsınız. Çalışma süresi de uzuyorsa, suçlu job'un içindedir. Aynı "queue yavaş" şikâyeti iki farklı yere işaret edebilir.

Bu düzenin bedeli, pgbouncer rolünün parolasının artık tüm kullanıcıların parola hash'lerine açılan bir kapı olması: fonksiyon kendisine verilen her kullanıcı adı için hash döndürüyor. O rolün parolasını diğer sırlardan ayrı tutun ve rotasyon listesine ekleyin.

Bağımlılığın bedeli eklendiği gün değil, ilk güvenlik yaması ya da sürüm yükseltmesi geldiğinde ödenir. Bu yüzden eklemeden önce sorulacak şey, o bakımı kimin üstleneceği. Standart kütüphane bu soruyu çoğu zaman en aza indirir.