توقف عن إعادة اختراع الأكواد النمطية: تطوير الويب الحديث يدور حول التنسيق

اعتاد الكثير من المطورين على بناء كل شيء من الصفر.

يبنون لوحات تحكم مخصصة. يكتبون أنظمة مصادقة مخصصة. ينشئون سكربتات نشر مخصصة. ويبنون أنظمة تسجيل أحداث (logging) مخصصة.

يبدو الأمر وكأنه هندسة. يبدو وكأنه سيطرة.

لكن هذا النهج يخلق مشاكل.

عندما تكتب الأكواد النمطية (boilerplate) الخاصة بك، تبدو النسخة الأولى جيدة. بعد ستة أشهر، لا أحد يتذكر لماذا صممتها بهذا الشكل. بعد عام واحد، تظهر في المشروع حالات استثنائية (edge cases) لا يريد أحد المساس بها. وبعد ثلاث سنوات، يصبح النظام موروثاً (legacy)، ويصبح من الصعب تغييره.

تطوير الويب الحديث لا يتعلق بكتابة كل جزء من الصفر، بل يتعلق باختيار الأنظمة الموجودة ودمجها معاً.

• استخدم مزودين ناضجين للمصادقة. • استخدم Stripe أو Paddle للمدفوعات. • فوّض مهام إرسال البريد الإلكتروني والتحليلات. • استخدم الأدوات الموجودة للبحث، وتخزين الملفات، وتتبع الأخطاء.

وظيفتك تتغير. لم تعد مجرد كاتب للأكواد، بل أصبحت:

• اختيار المكونات الصحيحة.
• فهم المقايضات (trade-offs).
• تصميم حدود واضحة ونظيفة.
• الحفاظ على قابلية استبدال النظام.
• توثيق القرارات.

كل سطر كود تملكه هو سطر يجب عليك تصحيحه (debug)، واختباره، وتأمينه، وشرحه. الكود غير الضروري مكلف. استخدام حل خارجي ناضج يتيح لفريقك التركيز على مشاكل عملك الخاصة بدلاً من البنية التحتية العامة.

بالطبع، هناك مخاطر. فالاعتماد على أطراف خارجية (Dependencies) يجلب معه مخاطر الارتباط بمزود واحد (vendor lock-in)، وتغير الأسعار، والمشاكل الأمنية.

الهدف هو أن تكون مقصداً (intentional). لا تبنِ كل شيء بشكل افتراضي، ولا تثبت كل شيء بشكل افتراضي. اسأل نفسك: هل هذا الكود جزء من ميزتنا التنافسية الحقيقية، أم أننا نعيد فقط بناء بنية تحتية موجودة بالفعل؟

توقف عن إضاعة وقت المراجعة البشرية في التنسيق أو المسافات البادئة (indents). استخدم أدوات التدقيق (linters) وفحوصات التكامل المستمر (CI) المؤتمتة. وفر الانتباه البشري للأسئلة رفيعة المستوى:

• هل هذا التصميم قابل للصيانة؟
• هل الحدود واضحة؟
• هل سيتحمل هذا النظام التوسع (scale)؟
• هل سيتمكن مطور آخر من فهم هذا بعد ستة أشهر؟

أفضل كود هو أحياناً الكود الذي تقرر عدم كتابته.

المطور الأكثر قيمة ليس هو من يكتب أكبر قدر من الأكواد النمطية، بل هو من يعرف ما يجب أن يتواجد في قاعدة الكود وما لا يجب أن يتواجد.

البرمجيات مكلفة ليس بسبب النسخة الأولى، بل بسبب الصيانة طويلة الأمد.

توقف عن إعادة اختراع الأكواد النمطية: تطوير الويب الحديث يدور حول التنسيق (Orchestration)

في كل مرة أبدأ فيها مشروعًا جديدًا، أجد نفسي أقوم بنفس الأشياء: إعداد قاعدة بيانات، وتكوين نظام المصادقة (authentication)، وإعداد التوجيه (routing)، وتكوين متغيرات البيئة (environment variables)، وما إلى ذلك. إنه أمر ممل، ومتكرر، وبصراحة، هو مضيعة للوقت.

نقضي ساعات، وأحيانًا أيامًا، فقط في تجهيز الأساس قبل أن نكتب سطرًا واحدًا من منطق العمل (business logic).

هذا هو "فخ الأكواد النمطية" (Boilerplate Trap).

لم يعد تطوير الويب الحديث يتعلق ببناء كل شيء من الصفر. بل يتعلق بالتنسيق (Orchestration).

ما هو التنسيق (Orchestration)؟

بدلاً من بناء نظام مصادقة مخصص، نستخدم Auth0 أو Clerk. وبدلاً من إدارة خوادم قواعد البيانات الخاصة بنا، نستخدم Supabase أو PlanetScale. وبدلاً من بناء بوابة دفع، نستخدم Stripe.

نحن نقوم بتنسيق الخدمات لتعمل معًا لإنشاء تطبيق كامل.

فوائد التنسيق (The Benefits of Orchestration):

1. سرعة التطوير: يمكنك الانتقال من الفكرة إلى مرحلة الإنتاج في جزء بسيط من الوقت.
2. التركيز على القيمة الجوهرية: تقضي وقتك في حل المشكلات الفعلية التي يواجهها مستخدموك، بدلاً من إعادة اختراع العجلة.
3. الأمان والموثوقية: هذه الخدمات مبنية من قبل خبراء ومجربة في بيئات عمل حقيقية.

المقايضات (The Trade-offs):

1. الارتباط بالمورد (Vendor lock-in): قد يكون من الصعب التبديل بين المزودين بمجرد دمج خدماتهم.
2. التكلفة: مع نمو تطبيقك، يمكن أن تتراكم تكاليف هذه الخدمات.

الخاتمة (Conclusion):

لقد انتهى عصر بناء كل شيء من الصفر. تبنَّ أسلوب التنسيق (orchestration) وركز على ما يهم حقًا: بناء منتجات رائ