تطوير تطبيقات Laravel

يجعل Laravel الأشهر الثلاثة الأولى سهلة، وتلك هي المشكلة. سيسمح لك الإطار بكل رحابة صدر أن تطلق تطبيقًا اختُرع مخططه هجرةً هجرة، ومهامه تفترض أنها لن تُنفَّذ إلا مرة واحدة، وأبطأ استعلام فيه سريع لأن الجدول فيه أربعمئة صف.

لا شيء من ذلك مرئي عند الإطلاق. وكله مرئي عند التوسع، وحينها تكون البيانات في الإنتاج وتكون الإصلاحات انقطاعات.

ماذا نبني

تطبيقات يكون السلوك فيها هو الجزء الصعب: منصات SaaS متعددة المستأجرين، وأسواق يتحرك المال خلالها، وأنظمة داخلية تحلّ محل عقد من جداول البيانات، ومكاتب خلفية يُدار عليها عمل حقيقي.

وحيث تكون للمشكلة هيئة خاصة بها فلها صفحتها - قاعدة البيانات حين يكون نموذج البيانات هو الصعوبة، والطوابير حين يقع العمل خارج الطلب، والواجهات البرمجية حين يتعين على غيرك استهلاكه. هذه الصفحة هي ما تشترك فيه تلك الأعمال.

المخطط يُقرَّر قبل الشيفرة

أغلب تطبيقات Laravel تحصل على قاعدة بياناتها بالصدفة. يُنشأ نموذج، فتتبعه هجرة، فتُضاف علاقة حين تحتاجها شاشة، وبعد ثمانية عشر شهرًا تجد أربعة أعمدة تحمل حالة ولا يتفق اثنان منها.

نحن نصممه أولًا، على الورق، وهو الجزء الذي لنا فيه أشد الآراء:

• قيود في قاعدة البيانات، لا في التطبيق وحده. مفتاح أجنبي يفرضه المخطط عطلٌ لا يستطيع الوصول إلى الإنتاج. والقاعدة التي تعيش في طلب نموذج فقط قاعدة ستلتف حولها مهمة في طابور أو أمر artisan أو مطوّر مستقبلي دون أن يعلم بوجودها.
• فهارس تُختار من الاستعلامات لا تُخمَّن. تُكتب حين يُكتب الاستعلام، بينما السبب لا يزال في رأس أحدهم.
• هجرات آمنة على جدول حي. إضافة عمود مجانية؛ وإضافة عمود بقيمة افتراضية، أو فهرس، قفلٌ - وعلى جدول فيه ملايين الصفوف يكون القفل انقطاعًا مربوطًا بعملية نشر.
• المال والوقت يُخزَّنان كما ينبغي. وحدات صغرى صحيحة، وعملة صريحة، وتوقيت عالمي منسق، وقرار مكتوب مرة واحدة بشأن عرض المنطقة الزمنية بدل مجادلته في كل شاشة.

Eloquent، مستخدَمًا عن قصد

Eloquent منتج ويخفي كلفة ما يفعله، وهي مقايضة جيدة حتى اليوم الذي تتوقف فيه عن كونها كذلك.

نتعامل مع عدد الاستعلامات كرقم يملكه أحد. تُحمَّل العلاقات مسبقًا لأن الشيفرة تقول ذلك، لا لأن صفحة بدت بطيئة ذات مرة. والتحميل الكسول معطَّل تمامًا في البيئات غير الإنتاجية، فيصبح N+1 العارض اختبارًا فاشلًا لا تذكرة دعم. والتجميعات التي تنتمي إلى SQL تبقى في SQL بدل جمعها في الذاكرة وعدّها في PHP.

لا شيء من ذلك غريب. إنه الفرق بين تطبيق يتدهور بلطف وآخر ينهار يوم نجح التسويق.

العمل الذي يقع خارج الطلب

كل ما هو بطيء، وكل ما هو طرف ثالث، وكل ما يمكن أن يفشل ينتمي إلى مهمة لا إلى متحكم. قول ذلك سهل وله نتائج تستحق التصميم لها بدل اكتشافها:

تُكتب المهام لتكون آمنة إذا نُفِّذت مرتين، لأن كل واحدة منها ستُنفَّذ كذلك في مرحلة ما. إعادة المحاولة ليست حالة فشل بل الحالة العادية، والمهمة التي تسحب من بطاقة أو ترسل بريدًا يجب أن تعرف ذلك. والإخفاقات تهبط حيث يراها إنسان. والعمل الطويل مقسَّم إلى دفعات كي لا يقتله نشرٌ في منتصفه.

الاختبار، بالقدر الذي يسدد ثمنه

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

المقياس الذي نستخدمه هو: هل ستلتقط المجموعة التغيير الذي يكسر العمل؟ اختبار يؤكد أن متحكمًا يعيد 200 لا يلتقط شيئًا تقريبًا؛ واختبار يؤكد أن طلبًا لا يمكن دفعه مرتين يلتقط ما كان سيكلفك استردادًا وسمعة.

شكل العمل

أربع مراحل. تنتهي كل واحدة بشيء يعمل على رابط لا بشيء موصوف في تقرير حالة.

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

كل ذلك يحدث حيث يعمل فريقك بالفعل - مستودعك، ونظام تتبعك، ومراجعاتك. الشيفرة التي تبقى داخل أدواتنا حتى يوم الإطلاق شيفرة يراها فريقك أول مرة يوم يكون قد فات وقت الجدال فيها.

ما الذي يحرّك الرقم فعلًا

ليس الإطار. الأشياء التي تقرر كم يستغرق بناء Laravel هي نفسها التي تقرر كم يستغرق أي بناء، ومعرفة أيّها ينطبق عليك أنفع من سعر اليوم:

• كم نظامًا يجب أن يتحدث إليه. مزوّد دفع واحد أسبوع. أما مزوّد دفع ونظام تخطيط موارد وواجهة شحن وصيغة ملف بنكي موثَّقة في ملف PDF من 2011 فمشروع آخر.
• هل القواعد مكتوبة في مكان ما. البناء مقابل عملية لا توجد إلا في رأس شخص واحد هو أضمن طريقة لبناء الشاشة نفسها ثلاث مرات.
• هل هناك شيء في الإنتاج بالفعل. البيانات الموجودة يجب ترحيلها، وترحيل بيانات لم يتحقق منها أحد هو حيث تذهب الجداول الزمنية.
• كم منه تقارير. التقارير تبدو رخيصة وليست كذلك: فيها يعيش عمل الاستعلامات وحساب التواريخ ومحادثات "لكن المالية تحسبها بطريقة أخرى".

متى يكون هذا التعاقد الخطأ

إن كان التطبيق موجودًا بالفعل والمشكلة أنه صار صعب التغيير أو متأخرًا بعدة إصدارات، فذلك ترقيات وإنقاذ، ويبدأ بالقراءة لا بالكتابة.

وإن كان يعمل لكنه ينهار تحت الحمل، فذلك الأداء والتوسع.

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

ماذا تتسلّم

التطبيق، والوثائق الأربع التي تجعل تشغيله ممكنًا لغيرنا: المخطط مع تبرير كل قرار لم يكن بديهيًا، وبنية الطوابير وما يُسمح لكل عامل بفعله، ودليل تشغيل النشر، ومجموعة الاختبارات مع ملاحظة عمّا لا تغطيه عمدًا.

طلبات الدمج قابلة للمراجعة وتصل تباعًا، فتقرأ العمل وهو يجري لا أن تتسلّمه في النهاية. وإن كان فريقكم سيتولّاه، فالأولى أن يراجعه قبل ذلك اليوم لا بعده.