بعد ثلاث سنوات من بناء متاجر على Shopify، بأحجام مبيعات متفاوتة، صارت لدينا صورة واضحة عن القرارات المعمارية التي صمدت مع الوقت، وتلك التي اضطررنا إلى شرحها للوكالة التالية التي استُعين بها لتنظيف عملنا. هذه هي النسخة الصريحة من تلك القائمة.
أكبر ندم: التحول إلى البنية المنفصلة (Headless) قبل أن يبرّرها حجم العمل. فعلنا ذلك مرتين في السنوات الأولى، وفي المرتين بطلب من العميل، وبمجموعة تقنيات ممتعة حقًّا في البناء: Hydrogen على Vercel، وSanity، وAlgolia، وغيرها. والمتجران عادا اليوم إلى قالب Liquid. فرق التحرير لم تستطع مجاراة نظامين، ومكاسب الأداء كانت حقيقية لكن التكلفة التشغيلية فاقتها عند ذلك المستوى من الإيرادات. البنية المنفصلة قرار صحيح للعمل المناسب، لكننا طبّقناها مبكرًا جدًا في حالتين كان فيهما بناء Liquid محسَّن جيدًا سيتفوق عليها في المقاييس التي تحرّك النتائج فعلًا.
الندم الثاني: ترك التطبيقات تتكاثر بلا ضابط. منظومة تطبيقات Shopify فخ إنتاجية: كل تطبيق يحل مشكلة حقيقية، لكن عشرين تطبيقًا معًا تصنع مشكلة أداء، ومشكلة ملكية بيانات، ومشكلة صيانة تتضاعف مع كل إصدار رئيسي من Shopify. قاعدتنا الآن: كل تطبيق جديد يستلزم إزالة تطبيق قائم، أو تبرير لماذا يكلّف البديل المبني خصيصًا أكثر على مدى ثلاث سنوات. هذا القيد وفّر من ميزانيات العملاء أكثر من أي ممارسة أخرى منفردة.
الثالث: مخططات الحقول الوصفية (metafields) التي صُممت في أول دورة عمل ولم تُراجع بعدها. ورثنا متاجر بهياكل حقول وصفية كانت منطقية حين كان الكتالوج 50 منتجًا، ولا منطق فيها عند 5,000. ترحيل الحقول الوصفية في متجر يعمل دون كسر واجهاته والأدوات الخارجية والأتمتة عمل مرهق. صرنا نعامل مخطط الحقول الوصفية كنموذج بيانات حقيقي، بمراجعة إلزامية قبل كل إضافة، ونوثّق مسارات الإيقاف من اليوم الأول.
الرابع: تأجيل قرارات توسيع صفحة الدفع. قبل Checkout Extensibility كان الجواب غالبًا «سنتعامل مع صفحة الدفع لاحقًا». ولاحقًا قد حان. المتاجر التي ما زالت تعمل بـ checkout.liquid أمام جدول ترحيل إلزامي، وأكثرها تخصيصًا في منطق الدفع أشدها ألمًا في الترحيل. كل مشروع نبدؤه الآن يتضمن مراجعة لتوسيع صفحة الدفع في الأسبوع الأول، حتى لو لم يكن أي تخصيص مخططًا، لأن شيئًا ما يظهر دائمًا.
الخامس: ملفات القوالب المتضخمة. أقسام تفعل أكثر مما ينبغي، وJavaScript مضمَّن داخل الصفحة بدل تحميله كوحدات، وCSS في ملف واحد من 4,000 سطر لأن المطور الأول لم يرد التعامل مع Webpack. ورثنا كل هذا. الوقت الذي يُوفَّر بعدم إعداد خط بناء سليم في أول دورة عمل يتراكم ليصبح أسابيع من إعادة الهيكلة لاحقًا. القوالب المبنية على Dawn ببنية وحدات سليمة جعلت هذا أسهل، لكن الانضباط يجب أن يُفرض من البداية.
معظم هذه القرارات يجمعها سبب واحد: قرارات معمارية اتُّخذت في أول دورة عمل وبدت سريعة وعملية حينها. المتاجر التي صمدت هي التي قضينا فيها أسبوعين في مرحلة الاستكشاف نتجادل حول نماذج البيانات وخطوط النشر قبل كتابة سطر Liquid واحد. والتي نندم عليها هي التي بدأنا بناءها من اليوم الأول لأن لدى العميل موعد إطلاق وأردنا أن نكون متعاونين. أن تكون متعاونًا في الأسبوع الأول ومؤلمًا في السنة الثانية ليس تعاونًا في الحقيقة.
كتبه فريق brainiac/studio. ننشر عملًا أصليًا من المهندسين والمصممين والمسوّقين الذين يقومون بالعمل نفسه، ولا نُسند الكتابة إلى جهة خارجية.