البرمجيات والمنصّات
المجالُ كاملًا، وبقيّةُ القدرات ضمنه.
تطبيقات الويب
تطبيقاتُ ويب تُبنى وفق ميزانيةٍ محدّدة للأداء ولإمكانية الوصول (Accessibility) منذ أوّل سطرٍ من الكود، لا تُصحَّح بتدقيقٍ في النهاية.
ما هذه الخدمة
تطبيقُ الويب برمجيةٌ يصل إليها المستخدمون عبر المتصفّح، وتشكّل فيها الواجهةُ وواجهةُ برمجة التطبيقات (API) خلفها ومخزنُ البيانات مشكلةَ تسليمٍ واحدة. نصمّم هذه التطبيقات ونبنيها من طرفٍ إلى طرف: التجربةُ المعروضة، وبيئةُ التشغيل التي تخدمها، وطبقةُ الـ API التي تخاطبها، وخطُّ التسليم الذي ينقل التغييرات إلى الإنتاج.
النمطُ الأكثر تكرارًا في الإخفاق هو مشروعٌ جُدولت فيه إمكانيةُ الوصول والأداءُ كمرحلة تقويةٍ بعد اكتمال الميزات. وعندها تكون مكتبةُ المكوّنات ونموذجُ التوجيه (Routing) وأسلوبُ جلب البيانات قد اختيرت جميعها على خلاف هذين الهدفين، فيصبح العلاجُ إعادةَ كتابةٍ للطبقات التي تمسّ كلَّ شاشة.
متى تحتاجها
إن صدق أكثرُ من واحدةٍ ممّا يلي، فهذه عادةً نقطةُ البداية الصحيحة.
- يبدو التطبيقُ بطيئًا على الهواتف متوسطة الفئة وعلى الاتصالات خارج المكتب، ولا أحد يستطيع تحديد التغيير الذي أوصله إلى هذه الحال.
- ظهر شرطُ إمكانية الوصول في عطاءٍ أو في قائمة تدقيقٍ للمشتريات، ولا تعرفون هل يجتازه المنتجُ أم لا.
- يحتاج كلُّ إصدارٍ إلى نافذة صيانةٍ وخطةِ تراجعٍ يدوية، فتتراكم التغييرات بدل أن تصدر.
- قاعدةُ العمل نفسها موجودة في ثلاثة مواضع، لأنّ المتصفّح وطبقةَ الـ API والمهمّةَ الخلفية أنشأ كلٌّ منها نسخته الخاصة منها.
ما الذي يشمله النطاق
- بنيةُ الواجهة الأمامية: استراتيجيةُ العرض، والتوجيه، وحدودُ الحالة (State)، وعقدُ المكوّنات الذي سيبني عليه الفريق.
- إمكانيةُ وصولٍ بمستوى WCAG 2.2 AA مبنيّةٌ داخل المكوّنات ومُتحقَّقٌ منها في خطّ التسليم، لا متروكةٌ لتدقيقٍ نهائي.
- ميزانيةُ أداءٍ معبَّرٌ عنها بأرقامٍ داخل التكامل المستمر (CI)، بحيث يُسقِط التراجعُ عمليةَ البناء بدل أن يبلغ الإنتاج.
- تصميمُ طبقة الـ API ونموذجِ البيانات، بما في ذلك التخزينُ المؤقّت والترقيمُ وعقدُ الأخطاء الذي يعتمد عليه العميل.
- التكاملُ والتسليم المستمرّان (CI/CD)، وفصلُ البيئات، والمراقبةُ (Observability)، ليصبح النشرُ حدثًا روتينيًّا بمسارِ تراجعٍ معروف.
ما الذي تستلمه
| المُخرَج | ما يحتويه |
|---|---|
| البنيةُ وسجلّاتُ القرار | سجلٌّ مكتوبٌ لقرارات العرض والحالة والوصول إلى البيانات، مع المفاضلة التي يقبلها كلُّ قرار، فيرث المهندسُ التالي التعليلَ لا التخمين. |
| مكتبةُ المكوّنات | مكوّناتُ واجهةٍ متاحةٌ ومختبَرة، بخصائصَ موثَّقة وسلوكِ تركيزٍ ومعالجةٍ للوحة المفاتيح، فترث كلُّ شاشةٍ قواعدَ التفاعل نفسها. |
| كودُ التطبيق والـ API | التطبيقُ العامل وطبقةُ الـ API والوصولُ إلى البيانات، مسلَّمةً داخل مستودعكم مع حزمة الاختبارات التي تحرسها. |
| خطُّ التسليم ودليلُ التشغيل | إعداداتُ CI/CD، وتعريفاتُ البيئات، وبوّاباتُ الميزانية وإمكانية الوصول، ودليلُ تشغيلٍ مكتوبٌ للنشر والتراجع وفرزِ الحوادث. |
مخطّطٌ معماريٌّ مرجعيّ
مرجعٌ لا قالب. بيئتُك هي التي تقرّر أيَّ أجزائه ينطبق، وبأيّ ترتيبٍ يصل.
كيف يُقاس النجاح
تُتَّفق المستهدفاتُ معك قبل بدء العمل، ويُرفَع التقريرُ عليها طوال مدّته.
- مؤشّراتُ الويب الأساسية (Core Web Vitals) — LCP وINP وCLS — مقيسةً من بيانات الميدان على حركتكم الحقيقية، لا من تشغيلات المختبر وحدها.
- مخالفاتُ إمكانية الوصول مصنَّفةً بحسب الخطورة، محسوبةً في كلّ عملية بناءٍ من الفحوص الآلية، إضافةً إلى تمريرةٍ يدوية موثَّقة بلوحة المفاتيح وقارئ الشاشة.
- وتيرةُ النشر، ونسبةُ فشل التغيير، وزمنُ الاستعادة، مقروءةً من خطّ التسليم وسجلّات الحوادث لديكم.
أسئلةٌ تُطرح علينا
هل تعملون على الكود القائم لدينا أم تصرّون على إعادة الكتابة؟
نبدأ بقراءة ما لديكم وتحديدِ الأجزاء الحاملة للنظام. معظمُ الارتباطات تدريجية: أسلوبُ عرضٍ أو توجيهٍ جديد يُطبَّق مسارًا بعد مسار، مع تشغيل المسار القديم والجديد جنبًا إلى جنب. إعادةُ الكتابة توصيةُ ملاذٍ أخير، وإن قدّمناها فسنعرض عليكم القيودَ المحدَّدة التي فرضتها.
أيّ إطار عملٍ ستستخدمون؟
نعمل أساسًا بـ React وNext.js، وبـ TypeScript وواجهات منصّة الويب المجرّدة حين يضيف الإطارُ أكثر ممّا يزيل. وإذا كان فريقكم يشغّل Angular أو Vue ويصونها جيّدًا، فنبني ضمن تلك التقنية بدل إدخال ثانية. الإطارُ أقلّ أهميةً من الحدود الفاصلة بين العرض والحالة والوصول إلى البيانات.
كم تضيف إمكانيةُ الوصول إلى الكلفة؟
إن بُنيت من البداية فإنّ عملًا كنتم ستؤدّونه على أيّ حال يستوعبها إلى حدٍّ بعيد، إذ تختارون عناصرَ أساسيةً متاحةً ودلالاتٍ صحيحة بدل غير المتاحة، بجهدٍ متقارب. الكلفةُ تظهر في التعديل اللاحق، لأنّه يمتدّ إلى الترميز وإدارةِ التركيز وأحيانًا إلى التصميم ذاته. وهذه هي حجّةُ حسمها في البداية.
هل يمكن بلوغُ ميزانية أداءٍ على صفحةٍ غنيّة بالمحتوى؟
غالبًا نعم، لكنّها تقيّد الخيارات: ما الذي يُعرض على الخادم، وكم نصًّا برمجيًّا من طرفٍ ثالث يُسمح به، وكيف تُحمَّل الصورُ والخطوط. الميزانيةُ مدخلٌ تصميمي لا نتيجةٌ نهائية. نتّفق على الأرقام قبل البناء ونفرضها في CI، وحين لا تتّسع ميزةٌ داخلها نقول ذلك بدل رفع الحدّ بصمت.
لمن يعود الكودُ وخطُّ التسليم عند انتهاء الارتباط؟
لكم. يحطّ العملُ في مستودعكم وتحت حساباتكم وبيئتكم السحابية منذ الأسبوع الأول لا عند التسليم. والتسليمُ نفسه نشاطٌ مجدول: توثيق، وجولةٌ شارحة في خطّ التسليم، ومدةٌ يقود فيها مهندسوكم ونراجع نحن.
هل تدعمون التطبيق بعد الإطلاق؟
نعم، عبر نماذج الخدمات المُدارة والدعم لدينا، بنطاقٍ متّفقٍ عليه للمراقبة وتحديث الاعتماديات والاستجابة للحوادث. وهي اتفاقيةٌ منفصلة عن البناء، فيمكنكم أيضًا تشغيلُه بأنفسكم. وفي الحالتين نصمّم المراقبةَ وأدلّةَ التشغيل على افتراض أنّ من سيتناوب على الطوارئ ليس كاتبَ الكود الأصلي.
اقرأ أيضًا
تطبيقات الهاتف المحمول
تطبيقاتُ iOS وAndroid يُصمَّم فيها العملُ دون اتصال وقواعدُ المزامنة والتعارض، وطبقةُ الخدمة الخلفية، وخطُّ الإصدار إلى المتاجر، قبل أوّل شاشة.
برمجيات المؤسسات
أنظمةٌ مؤسسية مخصّصة مصمَّمة حول نموذج البيانات وسطحِ التكامل، مع صلاحياتٍ قائمة على الأدوار، ومسارِ تدقيقٍ، وترحيلِ بياناتٍ مطابَق ومُوثَّق.
ابدأ بتقييم
أسرعُ طريقٍ إلى جوابٍ مفيد نظرةٌ قصيرةٌ محدَّدةُ النطاق على ما لديكم أصلًا.