Pahalı mimari karar genellikle kimsenin ihtiyaç duymadığı bir yeniden yazımdır. WordPress’te sipariş alan bir dükkân, ana sayfa daha yeni bir çerçeveye geçti diye daha güvenli olmaz. Çoğunlukla bir API ve bir pano olan ürün, onu dükkânla aynı temaya zorladığım için daha açık olmaz. Davranışı zaten tutan yığını seçerim ve sınırı, bir kişinin hâlâ ötesini görebileceği kadar keskin tutarım.
İşin zaten yaşadığı yerde kalın
Gelir bir WooCommerce ödemesiyse iş o ödemenin yanındadır: tema, gerçekten güvendiğim eklentiler, sunucu, posta, yedekler. Katalogu yığının güncel görünmesi için ayrı bir önyüze taşımak bir projedir. Kendi başına bir promosyon kodunun ya da kaçırılmış bir webhook’un düzeltmesi değildir. Kazancı estetik olan bir taşımaya göre bu hafta çıkan sade bir PHP değişikliğine daha çok sabrım vardır.
Laravel yerini, şeyin kendi kuralları, kendi kuyrukları ve kendi yönetimi olan bir uygulama olduğu ve sayfalara bükülmemesi gerektiği zaman kazanır. Harcama tavanı ve insan onayı adımı olan bir içerik hattı o tür uygulamadır. Bir pazarlama sitesi değildir.
| Sistem zaten şudur | Uzanırım | Uzanmam |
|---|---|---|
| Sipariş alan bir mağaza | WordPress, WooCommerce ve etrafındaki sunucu | Ana sayfa başka bir çatı olsun diye yeniden yazım |
| Kuyrukları ve yönetimi olan bir uygulama | Laravel, ya da ürünün geri kalanı zaten TypeScript ise Nest | Ürün gibi görünen bir eklenti yığını |
| Bir pano ile bir API’nin paylaştığı tipli arayüz | TypeScript, uçtan uca | Yalnızca düğmeler için ikinci bir dil |
| Bulma, puanlama, belgeler üzerinde küçük bir servis | Python | Mağazanın PHP çalışma zamanı, sadakatten |
Bir ürün boyunca tek dil, kariyer boyunca değil
Bir ürünün içinde ana dilin bir olmasını isterim; API’deki değişiklik ile ekrandaki değişiklik aynı inceleme olsun. İşim boyunca her şeyin tek dil olduğunu iddia etmem. PHP, TypeScript ve Python burada üretimde, bilerek. Hata, her katman birinin tercihi diye onları tek bir istek yolunda karıştırmaktır.
Verinin ilişkileri varsa ve veritabanının onları zorlamasını istiyorsam PostgreSQL. Dükkân zaten onu çalıştırıyorsa ve taşımak görev değilse MySQL. Redis bir kuyruk ya da önbellek içindir, ikinci doğru kaynak olarak değil. Yayını anlatmak gerektiğinde Docker ve sıkıcı bir nginx, bir orkestratör öğrenmek istediğimde değil.
Yeniden yazım, kaldırdığı olayı adlandırmalıdır
Yeni bir çerçevenin plana girmesine izin vermeden önce bir cümle isterim. Taşıma yüzünden, mevcut yığının kapatamadığı hangi olay gider? Cümle zevk, işe alım ya da bir konferans konuşması hakkındaysa taşıma bekler. Cümle “ödeme eklentisi bu fiyat kuralını ifade edemiyor ve etrafından iki kez yama yaptım” ise bu gerçek bir cümledir ve yeni bir vitrinden önce yine de daha küçük bir yama ararım. Daha küçük yama genellikle oradadır.
Aynı sınama, dükkânın yanına eklemek istediğim bir hizmet için de geçerlidir. Kuyruk, bir isteğin yeniden denemeyi atlatması gerektiğinde haklıdır. Ayrı bir önyüz, aynı API’ye bir geliştiricinin değil iki istemcinin ihtiyacı olduğunda haklıdır. Yeni bir veritabanı, bir güvenilirlik sorunuyla aynı çeyrekte neredeyse hiç haklı değildir. Elinizde olan veri sistemdir. Onu taşımak kendi envanteri olan ayrı bir projedir ve promosyon kodunu düzeltmez.
Bir dükkânı ve yanındaki hizmeti tutabilirim, çünkü belgelenmiş bir kenarda buluşurlar: bir webhook, bir kuyruk, bir tablo. Kenarları “o parçayı kuran kişiye sor” olan bir sistemi tutamam. O kişi ben olmalıyım, yayından sonra da. Yeni bir araç kira ödemelidir. Bir el değişimini ya da bir olay sınıfını kaldırmıyorsa zevktir, zevk bekleyebilir.
Sonraki olayı tek kafada tutan yığını seçin. Yenilik onu yenmeli, tersi değil.
