قرار المعمارية المكلف عادةً إعادة كتابة لم يحتجها أحد. متجر يتلقى الطلبات أصلاً على WordPress لا يصير أكثر أماناً لأن الصفحة الرئيسية تنتقل إلى إطار أحدث. منتج هو في الغالب API ولوح لا يصير أوضح لأنني أرغمته في السمة نفسها التي للمتجر. أختار المكدس الذي يمسك السلوك أصلاً، وأبقي الحد حاداً بما يكفي ليرى شخص واحد إلى الجانب الآخر.
ابقَ حيث يعيش النشاط أصلًا
إن كان الإيراد دفع WooCommerce، فالعمل ينتمي إلى جانب ذلك الدفع: السمة، والإضافات التي أثق بها فعلاً، والخادم، والبريد، والنسخ. نقل الكتالوج إلى واجهة منفصلة ليبدو المكدس حديثاً مشروع. ليس، بذاته، إصلاحاً لرمز ترويجي أو webhook فائت. عندي صبر أكثر لتغيير PHP بسيط يخرج هذا الأسبوع من ترحيل عائده جمالي.
Laravel يستحق مكانه حين يكون الشيء تطبيقاً بقواعده وطوابيره وإدارته، ولا ينبغي ثنيه إلى صفحات. خط محتوى بسقف إنفاق وخطوة موافقة بشرية هو ذلك النوع من التطبيقات. موقع تسويق ليس كذلك.
| النظام هو أصلًا | ألجأ إلى | لا ألجأ إلى |
|---|---|---|
| متجر يتلقى طلبات | WordPress وWooCommerce والخادم حولهما | إعادة كتابة كي تصبح الرئيسية إطارًا آخر |
| تطبيق بطوابير وإدارة | Laravel، أو Nest إن كان بقية ذلك المنتج أصلًا TypeScript | كومة إضافات تتظاهر بأنها منتج |
| واجهة منمّطة يشترك فيها لوح وواجهة برمجية | TypeScript، من الطرف إلى الطرف | لغة ثانية فقط من أجل الأزرار |
| استرجاع وتقييم وخدمة صغيرة فوق الوثائق | Python | بيئة PHP للمتجر، من باب الولاء |
لغة واحدة عبر منتج، لا عبر مسيرة
داخل منتج واحد أريد لغة رئيسية واحدة، ليكون تغيير API وتغيير الشاشة المراجعة نفسها. عبر عملي لا أدّعي أن كل شيء لغة واحدة. PHP وTypeScript وPython كلها في الإنتاج هنا، عن قصد. الخطأ خلطها داخل مسار طلب واحد لأن كل طبقة كانت تفضيل أحد.
PostgreSQL حين للبيانات علاقات وأريد أن تفرضها قاعدة البيانات. MySQL حين هذا ما يشغله المتجر أصلاً ونقله ليس المهمة. Redis لطابور أو ذاكرة مؤقتة، لا كمصدر حقيقة ثانٍ. Docker وnginx ممل حين يجب وصف النشر، لا حين أشتهي تعلم منسّق.
إعادة الكتابة يجب أن تسمّي الحادثة التي تزيلها
أطلب جملة واحدة قبل أن يُسمح لإطار جديد بدخول الخطة. أي حادث، لا يستطيع المكدس الحالي إغلاقه، يزول بسبب الانتقال؟ إن كانت الجملة عن ذوق أو توظيف أو حديث مؤتمر، فالانتقال ينتظر. إن كانت الجملة «إضافة الدفع لا تستطيع التعبير عن قاعدة التسعير هذه، وقد رقّعتها مرتين»، فتلك جملة حقيقية، ومع ذلك أبحث عن رقعة أصغر قبل واجهة متجر جديدة. الرقعة الأصغر عادةً موجودة.
الاختبار نفسه ينطبق على خدمة يغريني إضافتها بجانب المتجر. الطابور مبرر حين يجب أن ينجو الطلب من إعادة المحاولة. الواجهة المنفصلة مبررة حين يحتاج عميلان، لا مطور واحد، إلى API نفسها. قاعدة جديدة لا تكاد تبرَّر في الربع نفسه الذي فيه مشكلة موثوقية. البيانات التي عندكم أصلاً هي النظام. نقلها مشروع قائم بذاته، بجرده الخاص، ولا يصلح الرمز الترويجي.
أستطيع إمساك متجر وخدمة بجانبه لأنهما يلتقيان عند حافة موثّقة: webhook، وطابور، وجدول. لا أستطيع إمساك نظام حوافه «اسأل من بنى ذلك الجزء». ذلك الشخص يجب أن أكون أنا، وبعد الإطلاق أيضاً. لذا على الأداة الجديدة أن تدفع إيجاراً. إن لم تُزل تسليماً أو صنفاً من الحوادث فهي ذوق، والذوق يمكنه الانتظار.
اختر المكدس الذي يُبقي الحادثة التالية داخل رأس واحد. الجِدّة يجب أن تغلب ذلك، لا العكس.
