تطوير برمجيات مخصّصة بـ Next.js

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

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

ما يعنيه هذا عمليًا

العمل يأخذ دائمًا تقريبًا واحدًا من ثلاثة أشكال.

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

سطح يراه العملاء فوق أنظمة لم تُصمَّم يومًا ليكون لها سطح. بوابة، صفحة تتبّع، حساب خدمة ذاتية، حجز. والجزء الصعب نادرًا ما يكون الشاشة؛ بل أن البيانات وراءها تسكن شيئًا قديمًا وتجيب ببطء.

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

لماذا الرسم على الخادم وليس تطبيق صفحة واحدة

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

تطبيق App Router يُلغي تلك الطبقة في أكثر الشاشات. يقرأ الخادم البيانات ويرسم الصفحة. ويستلم المتصفح وسمًا جاهزًا بدل حزمة تطلب بعد ذلك البيانات التي تحتاجها. ولا تُرسَل جافاسكربت إلا حيث يحتاجها تفاعل فعلًا، وفي نظام تشغيلي هذه أقلية الشاشات.

والآثار عادية وتتراكم. لغة واحدة في التطبيق كله بدل لغتين. مستودع واحد ونشر واحد بدل اثنين يترقّمان مستقلين. صفحة صحيحة حين تصل بدل صحيحة بعد لحظة. وكود أقل بكثير، وهو الطريقة الموثوقة الوحيدة لتقليل كلفة السنة الثانية.

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

مكان سكن البيانات يُحسَم في الوقت نفسه

التطبيق المخصّص في معظمه نموذج بيانات بشاشات عليه، فالمخطّط ليس تفصيلة تُترك لاحقًا.

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

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

كيف يسير العمل

على مراحل، تنتهي كل واحدة بشيء منشور.

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

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

ما تحصلون عليه

في نهاية كل مرحلة تطبيق منشور تستطيعون استخدامه - لا بيئة عرض ولا فرع.

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

متى يكون هذا المشروع الخطأ

يستحق القول صريحًا، لأن الجواب أحيانًا لا.

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

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

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

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