قائمة مراجعة الشيفرة الأمامية قبل الإطلاق

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

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

١. أكِّد السلوك المقصود

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

حالات الفراغ، والتحميل، والاكتمال الجزئي، والخطأ، والنجاح
الأسماء الطويلة، والنصوص المُترجَمة، والأرقام الكبيرة، والحقول الاختيارية الغائبة
النقرات والإرسالات المتكرّرة
التنقّل بالعودة والتقدّم
تحديث رابط عميق
طلبات شبكة بطيئة أو فاشلة
انتهاء صلاحية المصادَقة أو قصور الصلاحيات

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

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

٢. راجع بنية المستند

يمنح HTML الدلالي المتصفّح والتقنيات المساعِدة سلوكًا مفيدًا قبل تشغيل JavaScript. تحقّق من أن التنفيذ يستخدم:

h1 واحدًا وصفيًا لموضوع الصفحة
عناوين تصف الأقسام في هرمية منطقية
عناصر button حقيقية للأفعال
روابط للتنقّل إلى رابط آخر
nav وmain وarticle وsection وaside وfooter حيث تعبِّر عن البنية
عناصر تحكّم أصيلة للنماذج بتسميات مرئية
قوائم للمجموعات المرتبطة من العناصر

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

يجب أن يُكمل ARIA الدلالة الأصيلة لا أن ينافسها. تحقّق من أن المعرِّفات المُشار إليها في aria-labelledby وaria-describedby وaria-controls موجودة وفريدة. احذف السمات القديمة المتروكة بعد إعادة الهيكلة.

تصف صفحة إمكانية الوصول في الموقع خط الأساس المتوقَّع عبر هذا المعرض.

٣. اختبر سلوك لوحة المفاتيح والتركيز

استخدم الصفحة بدون فأرة. يجب أن يستطيع المراجع:

الوصول إلى كل عنصر تحكّم تفاعلي بلوحة المفاتيح.
رؤية موقع التركيز في كل لحظة.
تشغيل عناصر التحكّم بالمفاتيح المتوقَّعة لها.
فتح النوافذ والقوائم وإغلاقها دون فقدان التركيز.
الخروج من الواجهات المؤقّتة حيث يتوقّع المستخدم أن يعمل زر Escape.
المتابعة بترتيب منطقي بعد تغيّر المحتوى.

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

لا توافق على تغيير يزيل حلقة التركيز دون بديل مرئي بنفس الوضوح.

٤. افحص السلوك الاستجابي بمحتوى قاسٍ

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

افحص العناصر ذات التنسيق الثابت مثل الجداول وأشرطة الأدوات والمخطّطات والشبكات والنوافذ. تحقّق من أن:

النص يلتفّ دون تغطية عناصر التحكّم المجاورة
الكلمات الطويلة والروابط لا تفرض تمريرًا أفقيًا للصفحة
أهداف اللمس بينها مسافة كافية
الأفعال المهمّة لا تتحرّك بشكل غير متوقَّع
الصور تحجز أبعادها قبل التحميل
التكبير إلى 200% لا يخفي محتوى أو أفعالًا
ترتيب المحتوى يبقى ذا معنى عند تكديس الأعمدة

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

٥. احمِ Core Web Vitals

يجب أن تربط مراجعة الأداء قرارات التنفيذ بالعمل الظاهر للمستخدم. مؤشّرات Core Web Vitals الحالية هي Largest Contentful Paint (LCP)، وInteraction to Next Paint (INP)، وCumulative Layout Shift (CLS).

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

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

بالنسبة إلى CLS، احجز مساحة للصور، والعناصر المضمَّنة، والشرائط الإعلانية، والمحتوى غير المتزامن. تجنّب إدخال إشعارات فوق موضع المستخدم الحالي بعد التحميل.

راجع أيضًا:

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

مزيد من التفاصيل حول نهج التنفيذ في خدمات هندسة الواجهة الأمامية.

٦. راجع قرارات React وTypeScript

في React، تحقّق من أن التأثيرات (effects) تُزامن مع نظام خارجي بدل حساب قيَم يمكن اشتقاقها أثناء العرض. افحص تنظيف الاشتراكات، والمؤقّتات، ومستمعي الأحداث.

لا تطلب useMemo أو useCallback تلقائيًا. يضيفان شيفرة وقد يُخفيان الملكيّة. استخدمهما عندما يوفّر التحليل، أو تطابق المرجعية، أو استراتيجية مُترجِم قائمة، سببًا محدّدًا.

في TypeScript:

فضِّل الأنواع الضيّقة الخاصة بالمجال على الكائنات العامّة
تجنّب any حيث يمكن التحقّق من الحد
مثِّل حالات التحميل والخطأ بصورة صريحة
تحقّق من بيانات API غير الموثوقة عند الحد
أبقِ الخصائص العامّة للمكوّنات مقصودة
تجنّب التأكيدات التي تُسكت فقط شكًّا حقيقيًا

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

٧. قيِّم القابلية للصيانة والاختبارات

اسأل نفسك ما إذا كان مطوِّرٌ غير مطّلع على التغيير يستطيع تحديد تدفّق البيانات، ومالك الحالة، وسلوك الإخفاق، ونقاط التوسيع. يجب أن تشرح التسميةُ النيةَ. يجب أن تحفظ التعليقاتُ المنطقَ غير الواضح لا أن تسرد بناء اللغة.

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

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

قائمة مراجعة نهائية

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