دور بنية المشروع في التصميم المعتمد على المواصفات

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

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

ويحذر Muzli من وضع HTML وCSS وJavaScript في ملف واحد، مثل index.html، عند بدء العمل مع وكلاء توليد الكود. فقد يكون ذلك مقبولاً في مشروع صغير جداً، لكنه يفرض على النموذج قراءة الملف كاملاً حتى عند تعديل قاعدة تنسيق أو دالة واحدة. ووفق المقال، ينعكس ذلك في وقت معالجة أطول، ودقة أقل بسبب اختلاط السياق غير المرتبط بالمهمة، واستهلاك أعلى للرموز والتكلفة المرتبطة بها.

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

ويربط Muzli هذا النهج بخبرة المصممين في Figma، إذ يشترك مكوّن Figma وWeb Component في فكرة الوحدة القابلة لإعادة الاستخدام التي ينعكس تعديلها على مثيلاتها. لكن المقال يؤكد أيضاً أهمية التشاور مع فريق التطوير حول الأعراف التنظيمية القابلة لإعادة الاستخدام لاحقاً، من دون أن يتحول ذلك إلى محاولة حسم قرارات معمارية خاصة بالإنتاج خلال مرحلة التحقق من UX وUI.

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