Linting وبوابات CI لإمكانية الوصول

تُشغّل الاختبارات بعد كتابة التعليمات البرمجية، لكن linter يعلّم على المشكلات أثناء الكتابة. وكلما اكتشفتم المشكلة مبكرًا، انخفضت تكلفة إصلاحها.

في مشاريع React، تفحص إضافة eslint-plugin-jsx-a11y الخاصة بـ ESLint تعليمات JSX البرمجية بحثًا عن أخطاء إتاحة الوصول الشائعة مباشرةً في المحرر.

يكتشف jsx-a11y أمورًا مثل صورة بلا خاصية alt، أو رابطًا بلا href، أو معالج نقر على عنصر غير تفاعلي.

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

يقرأ linter التعليمات البرمجية المصدرية، لا الصفحة المعروضة. ولا يمكنه قياس التباين أو ترتيب التركيز، لذا فهو يكمّل فحوصات axe ولا يحل محلها.

بوابة CI هي فحص يجب اجتيازه قبل دمج التعليمات البرمجية. فإذا فشل اختبار إتاحة الوصول لديكم، يُحظر طلب السحب ببساطة.

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

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

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

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

يجمع الإعداد الأقوى بين هذه العناصر: lint أثناء البرمجة، وaxe في الاختبارات، وبوابة CI عند الدمج. وتكتشف كل طبقة ما قد تفوّته الطبقات الأخرى.

فكّروا فيما يستطيع linter الخاص بالتعليمات البرمجية رؤيته وما لا يستطيع رؤيته.

شغّلوا lint أثناء البرمجة، وشغّلوا axe في اختباراتكم، واجعلوا CI بوابة لعمليات الدمج. وعند جمع هذه الضمانات، تمنع تراجعات إتاحة الوصول من الوصول إلى الإصدار. 🚦