Keputusan arsitektur yang mahal biasanya penulisan ulang yang tidak dibutuhkan siapa pun. Toko yang sudah menerima pesanan di WordPress tidak menjadi lebih aman karena beranda pindah ke kerangka yang lebih baru. Produk yang sebagian besar API dan papan tidak menjadi lebih jelas karena saya memaksanya ke tema yang sama dengan toko. Saya memilih stack yang sudah memegang perilaku itu, dan menjaga batas cukup tajam agar satu orang masih bisa melihat ke seberang.
Tetap di tempat bisnis sudah tinggal
Jika pendapatan adalah checkout WooCommerce, kerja itu di samping checkout itu: tema, plugin yang benar-benar saya percaya, server, surel, cadangan. Memindahkan katalog ke frontend terpisah agar stack tampak mutakhir adalah proyek. Itu sendiri bukan perbaikan kode promo atau webhook yang terlewat. Saya lebih sabar pada perubahan PHP biasa yang keluar minggu ini daripada migrasi yang hasilnya estetis.
Laravel mendapat tempatnya ketika hal itu adalah aplikasi dengan aturan sendiri, antrean sendiri, admin sendiri, dan tidak boleh dibengkokkan menjadi halaman. Pipeline konten dengan batas belanja dan langkah persetujuan manusia adalah aplikasi semacam itu. Situs pemasaran bukan.
| Sistemnya sudah | Saya meraih | Saya tidak meraih |
|---|---|---|
| Toko yang menerima pesanan | WordPress, WooCommerce, dan server di sekelilingnya | Penulisan ulang agar beranda jadi framework lain |
| Aplikasi dengan antrean dan admin | Laravel, atau Nest jika sisa produk itu sudah TypeScript | Tumpukan plugin yang berpura-pura jadi produk |
| Antarmuka bertipe yang dipakai bersama papan dan API | TypeScript, ujung ke ujung | Bahasa kedua hanya untuk tombol |
| Pengambilan, penilaian, layanan kecil di atas dokumen | Python | Runtime PHP toko, karena kesetiaan |
Satu bahasa di satu produk, bukan di seluruh karier
Di dalam satu produk saya ingin satu bahasa utama, supaya perubahan di API dan perubahan di layar adalah tinjauan yang sama. Di seluruh kerja saya tidak berpura-pura semuanya satu bahasa. PHP, TypeScript, dan Python semuanya ada di produksi di sini, dengan sengaja. Kesalahannya mencampurnya di dalam satu jalur permintaan karena tiap lapisan adalah selera seseorang.
PostgreSQL saat data punya hubungan dan saya ingin basis data yang menegakkannya. MySQL saat itulah yang sudah dijalankan toko dan memindahkannya bukan tugasnya. Redis untuk antrean atau cache, bukan sebagai sumber kebenaran kedua. Docker dan nginx yang membosankan saat deploy harus bisa dijelaskan, bukan saat saya ingin belajar orkestrator.
Penulisan ulang harus menyebut insiden yang dihilangkannya
Saya minta satu kalimat sebelum kerangka baru boleh masuk rencana. Insiden mana, yang stack sekarang tidak bisa menutup, hilang karena perpindahan itu? Jika kalimatnya tentang selera, perekrutan, atau ceramah konferensi, perpindahan menunggu. Jika kalimatnya “plugin checkout tidak bisa menyatakan aturan harga ini, dan saya sudah menambal di sekelilingnya dua kali”, itu kalimat sungguhan, dan saya tetap mencari tambalan yang lebih kecil sebelum etalase baru. Tambalan yang lebih kecil biasanya ada.
Ujian yang sama berlaku untuk layanan yang saya tergoda menambah di samping toko. Antrean masuk akal saat permintaan harus selamat dari percobaan ulang. Frontend terpisah masuk akal saat dua klien, bukan satu pengembang, butuh API yang sama. Basis data baru hampir tidak pernah masuk akal di kuartal yang sama dengan masalah keandalan. Data yang sudah Anda punya adalah sistemnya. Memindahkannya adalah proyek sendiri, dengan inventaris sendiri, dan tidak memperbaiki kode promo.
Saya bisa memegang toko dan layanan di sampingnya karena bertemu di tepi yang terdokumentasi: webhook, antrean, tabel. Saya tidak bisa memegang sistem yang tepinya “tanyakan orang yang membangun bagian itu”. Orang itu harus saya, termasuk setelah peluncuran. Jadi alat baru harus membayar sewa. Jika tidak menghapus serah terima atau satu kelas insiden, itu selera, dan selera bisa menunggu.
Pilih tumpukan yang menahan insiden berikutnya di dalam satu kepala. Kebaruan harus mengalahkan itu, bukan sebaliknya.
