اختيار حزمة التقنيات هو القرار الذي يحدد من يمكنك توظيفه، وكيف تبدو فاتورة الاستضافة، وكم سيكون تعديل المنتج مؤلماً بعد ثلاث سنوات. هذا الدليل موجّه للمؤسسين ومديري المنتجات الذين عليهم اعتماد هذا القرار دون أن يكونوا مهندسين، وللمطورين الذين يريدون طريقة للدفاع عن حزمة تقنيات بحجة أقوى من «هذا ما أعرفه». والخلاصة: اختر أكثر التقنيات مللاً مما يؤدي المهمة، واجعل الاستثناءات مقصودة.
ماذا تعني «التقنية المملّة» ولماذا تفوز؟
التقنية المملّة هي أي لغة أو إطار عمل أو قاعدة بيانات تعمل في بيئات الإنتاج منذ سنوات، ولها مجتمع كبير، وأنماط فشلها معروفة، وليست في طريقها إلى الزوال. فكل مشكلة ستصادفها صادفتها آلاف الفرق قبلك، والجواب على بُعد بحث واحد.
والبديل هو التقنية المثيرة: جديدة، سريعة التغيّر، وأحياناً أفضل فعلاً على الورق. والثمن أنك تصبح من يكتشف المشكلات. فالتوثيق ضعيف، والمكتبة التي تعتمد عليها قد تُهجر، ومن اختارها قد يكون الوحيد في الفريق الذي يفهمها.
المنتج الجديد يحمل من المخاطر في السوق ما يكفيه. ولا يحتاج إلى مخاطر في الأنابيب. أنفق رصيدك من الجدّة على الشيء الوحيد الذي يميّز منتجك، وأبقِ كل ما عداه تقليدياً.
ما وزن إلمام الفريق والتوظيف في القرار؟
أكبر مما تعترف به معظم المقارنات التقنية. فإطار العمل الذي يتفوق قليلاً في قياسات الأداء لا يساوي شيئاً إن كان فريقك يسلّم فيه ببطء، والفريق الذي يعرف حزمة تقنيات جيداً سينتج أخطاء أقل وبنية أفضل وإصلاحات أسرع من فريق أقوى يتعلم أثناء العمل.
وسؤال التوظيف هو النسخة بعيدة المدى من النقطة نفسها. اطرح ثلاثة أسئلة قبل الالتزام:
- هل يمكننا التوظيف لهذه التقنية في منطقتنا بسعر نتحمله؟
- إن غادر مطورنا الرئيسي، هل يمكننا استبداله خلال فترة إشعار عادية؟
- هل تستطيع شركة خارجية تولّي قاعدة الكود هذه دون شهر من التهيئة؟
إن كان الجواب عن أي منها «لا»، فحزمة التقنيات عبء مهما بلغت أناقتها. وهذه هي الحجة لصالح الخيارات السائدة: PHP، وJavaScript وTypeScript، وPython، وقاعدة بيانات علائقية.
كم ستكلّف الاستضافة والصيانة فعلاً؟
كلفتان تُهملان عند اختيار الحزمة: كلفة التشغيل، وكلفة إبقائها آمنة.
كلفة التشغيل تعتمد على المعمارية أكثر من اللغة. فتطبيق موحّد على خادم أو اثنين مع قاعدة بيانات مُدارة رخيص ومتوقع وسهل المراقبة. أما توزيع المنتج نفسه على دوال بلا خادم وطوابير وخدمات مُدارة فقد يكلّف أكثر، ويصعب توقّع فاتورته لأنها تتغير مع زيارات لا تتحكم بها بعد. ولمنتج بلا عملاء بعد، يفوز الرخيص والمتوقع.
وكلفة الصيانة تتعلق بطول العمر. فكل اعتمادية تضيفها شيء سيحتاج إلى ترقية. وأطر العمل ذات جدول إصدارات واضح وفترات دعم طويلة أرخص في إبقائها محدّثة من أطر تعيد اختراع نفسها كل عام.
متى يكون Laravel مع Next.js الخيار الصحيح، ومتى لا يكون؟
نبني معظم المنتجات على Laravel للواجهة الخلفية وNext.js لواجهة الويب، ونوصي بهما كثيراً. وهذا متى يناسب الخيار، ومتى لا يناسب.
يناسب الخيار حين:
- يكون المنتج تطبيق ويب بقاعدة بيانات وحسابات مستخدمين ولوحة إدارة وواجهة برمجية. فـLaravel يمنحك المصادقة والطوابير والصلاحيات والبريد ومنظومة أدوات إدارة دون تجميعها من أجزاء.
- تحتاج إلى موقع تسويقي وتطبيق يتشاركان التصميم والواجهة الخلفية. فـNext.js يتولى العرض وتحسين محركات البحث والأداء للصفحات العامة، والواجهة البرمجية نفسها تخدم التطبيق.
- يجب أن يعمل المنتج بالإنجليزية والعربية من الشاشة الأولى. فكلا الإطارين يدعمان التوطين والتخطيط من اليمين إلى اليسار بنضج.
- تريد حزمة تستطيع شركات ومستقلون كثر صيانتها بعدنا.
ولا يناسب حين:
- يكون جوهر المنتج معالجة فورية ثقيلة أو خطوط بيانات أو تعلّماً آلياً. فحينها تنتمي الواجهة الخلفية إلى لغة بُنيت لذلك، ويصبح Laravel في أحسن الأحوال طبقة رقيقة حولها.
- يكون المنتج تجربة جوال أصلية أولاً، والويب فكرة لاحقة.
- يكون لديك أصلاً فريق كفء في منظومة أخرى. فنقلهم إلى منظومتنا إرضاءً لمورّد اتجاه خاطئ.
- يكون الأمر كله موقع محتوى بسيط. فمنصة محتوى تؤدي المهمة أرخص من أي حزمة مخصصة.
كيف تتخذ القرار دون أن تندم عليه؟
اكتب القرار. مذكرة من صفحة واحدة تذكر ما اختير وما رُفض ولماذا، بحيث يبقى المنطق بعد رحيل من اتخذه.
واتخذه قبل تثبيت سعر البناء، لا بعده. في منهجيتنا يحدث هذا في ورشة الاستكشاف المدفوعة، حيث تُختار الحزمة وفق قيودك الفعلية، ثم يُبنى النطاق المرحلي ثابت السعر على ذلك الاختيار. وتغيير الحزمة بعد تسعير النطاق هو أغلى تغيير ممكن.
وتعامل مع الحزمة كقرار توظيف وقرار كلفة وقرار مخاطر قبل أن تعامله كقرار تقني. فسيكون للمطورين دائماً تفضيلاتهم. أما العواقب فتعيش معها الشركة.