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