من مهندس جودة (QA) إلى مهندس مكونات (Component Architect)
أصبحت محررات الأكواد المدعومة بالذكاء الاصطناعي تتعامل الآن مع معظم الأكواد النمطية (boilerplate code). وهذا يخلق أسطورة خطيرة؛ حيث تعتقد الفرق أنه إذا كتب الذكاء الاصطناعي الكود وتم تجميعه (compiles) بنجاح، فإنه يعمل بشكل صحيح.
هذه العقلية قد تنجح مع الميزات الصغيرة، لكنها تفشل تماماً مع أنظمة التصميم (design systems).
مكون نظام التصميم ليس مجرد ميزة عابرة، بل هو بنية تحتية. فزر واحد أو حقل إدخال واحد سيخدم ملايين المستخدمين عبر مئات المنتجات.
الميزة الحقيقية ليست في سرعة كتابة الكود، بل في مدى قدرتك على توقع الفشل.
يجب أن تنتقل من عقلية "البنّاء" إلى عقلية "المُحطم". عليك تبني الاختبار من خلال TDD وBDD والتطوير القائم على المواصفات (Spec-Driven Development).
تبني معظم الفرق برمجياتها بناءً على "المسار المثالي" (Happy Path)؛ حيث يكتفون بمطابقة ملف Figma ثم يتوقفون. لكن المكونات يجب أن تصمد أمام فوضى العالم الحقيقي.
الفريق القوي يطرح أسئلة صعبة قبل كتابة الكود:
- المصممون: ماذا يحدث إذا كان النص مكوناً من 400 حرف؟ هل ستنهار واجهة المستخدم (UI)؟
- المهندسون: ماذا يحدث إذا نقر المستخدم على زر التبديل (toggle) عشر مرات في الثانية؟ هل ستفسد الحالة (state)؟
- إمكانية الوصول (Accessibility): كيف سيتعامل قارئ الشاشة مع هذه القائمة المنسدلة باستخدام لوحة المفاتيح فقط؟
أدوات الذكاء الاصطناعي جيدة في كتابة الكود، لكنها سيئة في وضع الافتراضات، مما ينتج مكونات هشة.
استخدم سير العمل هذا لحماية عملك:
- حدد المواصفات (Tokens، إمكانية الوصول، API).
- اكتب الاختبارات والقصص (stories) أولاً لتحديد الحدود.
- استخدم الذكاء الاصطناعي لتوليد الكود ضمن تلك الحدود.
تقوم منهجية TDD بقلب العملية رأساً على عقب؛ فبدلاً من إصلاح الأخطاء لاحقاً، تقوم بتحديد الحدود مسبقاً، ثم يقوم الذكاء الاصطناعي بتلبية تلك الاختبارات.
تساعد منهجية التطوير القائم على السلوك (BDD) أيضاً، حيث تستخدم لغة بشرية لسد الفجوة بين التصميم والهندسة.
مثال:
- بفرض أن المستخدم لديه اتصال بطيء،
- عندما ينقر على إرسال (submit)،
- حينها يجب أن يظهر الزر حالة تحميل (loading state) ويتم تعطيل النقرات.
يخشى بعض القادة من أن الاختبار يبطئ السرعة، وهذا خطأ.
البرمجة الأولية تمثل 5% فقط من تكلفة المكون، بينما تذهب الـ 95% المتبقية للصيانة وإصلاح الأخطاء.
عقلية الاختبار تمنحك:
- تراجعات (regressions) أقل عند إعادة هيكلة الكود (refactor).
- نظاماً ذاتي الخدمة للمطورين الآخرين.
- ثقة مؤسسية.
في عالم الذكاء الاصطناعي، أصبحت سرعة البرمجة أمراً شائعاً، لكن التفكير المنظومي (Systems thinking) أمر نادر.
توقف عن محاولة البناء بشكل أسرع. ابدأ البناء لغرض الصمود أمام الكسر.
كيف يوازن فريقك بين السرعة والقدرة على الصمود؟ أخبرني في التعليقات.
من مهندس جودة (QA) إلى مهندس مكونات (Component Architect): لماذا يعد كسر الكود الخاص بك هو السر وراء أنظمة التصميم ذات المستوى العالمي
لقد قضيت سنوات كمهندس جودة (QA)، حيث كان عملي الأساسي هو محاولة "كسر" البرمجيات. كنت أبحث عن الثغرات، والحالات الاستثنائية (edge cases)، وكل ما يمكن أن يؤدي إلى انهيار النظام. عندما انتقلت إلى دور مهندس مكونات (Component Architect)، اكتشفت أن هذه المهارة ليست مجرد وسيلة لاكتشاف الأخطاء، بل هي السر وراء بناء أنظمة تصميم (Design Systems) عالمية المستوى.
عقلية مهندس الجودة مقابل عقلية المهندس المعماري
يعتقد الكثيرون أن دور المهندس المعماري يتمحور حول "البناء" فقط. ولكن الحقيقة هي أن البناء هو نصف المعركة فقط. النصف الآخر هو التنبؤ بكيفية فشل ما تبنيه.
بصفتي مهندس جودة سابقًا، لم أكن أنظر إلى المكون (Component) وأتساءل: "هل يعمل هذا؟". بدلاً من ذلك، كنت أسأل: "كيف يمكنني جعل هذا يتوقف عن العمل؟".
- هل سيتعرض المكون للانهيار إذا تم إدخال نص طويل جدًا؟
- ماذا سيحدث إذا تم تعطيل الاتصال بالشبكة أثناء تحميل المكون؟
- هل سيبقى المكون قابلًا للاستخدام من قبل الأشخاص الذين يستخدمون قارئات الشاشة (Screen Readers)؟
كسر الكود لبناء أنظمة مرنة
السر في بناء أنظمة تصميم قوية ليس في كتابة كود مثالي من المرة الأولى، بل في اختبار حدود الكود الخاص بك بشكل منهجي.
1. اختبار الحالات الاستثنائية (Edge Cases)
بدلاً من التركيز فقط على "المسار السعيد" (Happy Path)، يجب عليك تصميم مكونات تتع