دليل للتعاون في نظم التصميم
للكاتب دومينيك نجوين /المصدر انفجن
هذا مقتطف من Design Systems for Developers ، دليل نظم التصميم الذي نشره الفريق وراء مطور مكون أنظمة التصميم Storybook. قراءة الكتاب مجانا هنا.
في الفصل 4 ، سنتعلم سير العمل الاحترافي لإجراء تحسينات على نظام التصميم مع التخفيف من حالات عدم الاتساق. يغطي هذا الفصل تقنيات جمع تعليقات واجهة المستخدم والتوصل إلى توافق مع فريقك. يتم استخدام عمليات الإنتاج هذه بواسطة الأشخاص في Auth0 و Shopify و Discovery Network.
مصدر واحد للحقيقة أو نقطة واحدة من الفشل
لقد كتبت سابقًا أن أنظمة التصميم تمثل نقطة فشل واحدة للفرق الأمامية. في جوهرها ، نظم التصميم هي التبعية. إذا قمت بتغيير أحد مكونات نظام التصميم ، ينتشر هذا التغيير إلى التطبيقات التابعة. آلية توزيع التغييرات غير متحيزة – إنها تأتي بكل من التحسينات والأخطاء.
الأخطاء تشكل خطرًا وجوديًا على أنظمة التصميم ، لذلك سنبذل قصارى جهدنا لمنعها. القرص الصغيرة في نهاية المطاف كرة الثلج في تراجع لا حصر لها. دون استمرار تصميم أنظمة الصيانة ذبل.
التكامل المستمر
التكامل المستمر هو وسيلة defacto للحفاظ على تطبيقات الويب الحديثة. يسمح لك بسلوك النص البرمجي مثل الاختبارات والتحليل والنشر كلما دفعت الكود. سنستعير هذه التقنية لإنقاذ أنفسنا من العمل اليدوي المتكرر.
نحن نستخدم CircleCI هنا ، وهو مجاني للاستخدام المتواضع. تنطبق نفس المبادئ على خدمات CI الأخرى أيضًا.
أولاً ، اشترك في CircleCI إذا لم تكن بالفعل. بمجرد وصولك ، سترى علامة تبويب “إضافة مشاريع” حيث يمكنك إعداد مشروع نظام التصميم على هذا النحو.
أضف دليل .circleci في المستوى العلوي وقم بإنشاء ملف config.yml بداخله. سيتيح لنا ذلك كتابة كيفية تصرف عملية CI الخاصة بنا. يمكننا ببساطة إضافة الملف الافتراضي الذي تقترحه الدائرة لـ Node في الوقت الحالي:
في الوقت الحالي ، يتم إجراء اختبار الغزل هذا ، وهو اختبار React أساسي تم إعداده بواسطة تطبيق create-react-app بالنسبة لنا. دعونا نتحقق من أنه يعمل على الدائرة:
لاحظ أن إنشاءنا فشل ، حيث لا يوجد لدينا في الوقت الحالي أي اختبارات محددة لمشروعنا. سنضيف بعضًا قريبًا ، الآن ، دعنا نستمر في الحركة.
مراجعة مرئية مكونات واجهة المستخدم مع فريقك
المراجعة البصرية هي عملية تأكيد سلوك وواجهات واجهات المستخدم. يحدث ذلك أثناء تطوير واجهة المستخدم وأثناء ضمان الجودة مع الفريق.
معظم المطورين على دراية بمراجعة الكود ، وهي عملية جمع تعليقات الكود من مطورين آخرين لتحسين جودة الكود. نظرًا لأن مكونات واجهة المستخدم تعبر عن الرمز بيانياً ، فإن المراجعة المرئية ضرورية لجمع تعليقات واجهة المستخدم / UX.
إنشاء نقطة مرجعية عالمية
حذف node_modules. إعادة تثبيت الحزم. مسح محلي. حذف ملفات تعريف الارتباط. إذا كانت هذه الإجراءات مألوفة ، فأنت تعلم مدى صعوبة التأكد من الرجوع إلى أعضاء الفريق على أحدث رمز. عندما لا يكون لدى الأشخاص بيئات تطوير متطابقة ، يكون ذلك بمثابة كابوس للتعرف على المشكلات التي تسببها البيئة المحلية من الأخطاء الحقيقية.
لحسن الحظ ، كمطورين أماميين ، لدينا هدف ترجمة شائع: المتصفح. تقوم فرق الدهاء بنشر قصصها على الإنترنت لتكون بمثابة مرجع عالمي للمراجعة البصرية. هذا يتجنب التعقيدات الملازمة لبيئات التطوير المحلية (من المزعج أن يكون الدعم الفني على أي حال).
عندما يمكن الوصول إلى مكونات واجهة المستخدم الحية عبر عنوان URL ، يمكن لأصحاب المصلحة تأكيد شكل واجهة المستخدم وشعورها بالراحة من المتصفحات الخاصة بهم. وهذا يعني أن المطورين والمصممين والمديرين التنفيذيين لا يتعين عليهم التركيز على بيئة تطوير محلية أو تمرير لقطات شاشة أو الرجوع إلى واجهة المستخدم القديمة.
“إن نشر القصص القصيرة يجعل كل العلاقات العامة المراجعة المرئية أسهل ويساعد أصحاب المنتجات على التفكير في المكونات”.
نوربرت دي لانجن ، صانعي قصص الأطفال
نشر القصص القصيرة
أنشئ سير عمل المراجعة المرئية باستخدام Netlify ، وهي خدمة نشر سهلة الاستخدام للمطورين. Netlify مجاني لحالة الاستخدام الخاصة بنا ، ولكن من السهل إنشاء Storybook كموقع ثابت ونشره على خدمات الاستضافة الأخرى أيضًا.
الآن ، ابحث عن ريبو GitHub لنظام التصميم الذي أنشأناه في الفصل الأخير.
أدخل الأمر storybook-build لتشغيل Netlify كلما ارتكبت.
كل شيء على ما يرام ، سترى بناء ناجح في Netlify:
تصفح كتابك القصصي المنشور من خلال النقر على الرابط. ستجد أن بيئة تطوير Storybook المحلية معكوسة عبر الإنترنت. هذا يجعل من السهل على فريقك مراجعة مكونات واجهة المستخدم المقدمة الحقيقية كما تراها محليًا.
يقوم Netlify بتشغيل أمر بناء على كل التزام ينشر Storybook الخاص بك. ستجد رابطًا إليه في اختبارات GitHub’s PR (سنرى ذلك أدناه).
تهانينا! الآن بعد أن قمت بإعداد البنية التحتية لنشر Storybook ، دعنا نجمع العروض التوضيحية.
أثناء تواجدنا فيه ، دعونا نضيف الدليل الثابت للقصص إلى ملف .gitignore لدينا:
و ارتكابها.
طلب مراجعة بصرية من فريقك
في كل مرة يحتوي فيها طلب السحب على تغييرات في واجهة المستخدم ، من المفيد بدء عملية مراجعة بصرية مع أصحاب المصلحة للتوصل إلى توافق في الآراء بشأن ما يتم شحنه إلى المستخدم. بهذه الطريقة لا توجد مفاجآت غير مرغوب فيها أو إعادة صياغة باهظة الثمن.
سنقدم عرضًا مرئيًا عن طريق إجراء تغيير في واجهة المستخدم في فرع جديد.
أولاً ، يعدل مكون الزر. “اجعلها منبثقة” – سوف يحبها المصممون لدينا.
ارتكب التغيير وادفعه إلى GitHub repo.
انتقل إلى GitHub.com وافتح طلب سحب لفرع تحسين الزر.
انتقل إلى عنوان URL الخاص بـ Netlify في اختبارات العلاقات العامة للعثور على مكون الزر الخاص بك.
لكل مكون وقصة تم تغييرها ، انسخ عنوان URL من شريط عنوان المتصفح والصقه أينما كان فريقك يدير المهام (جيثب ، أسانا ، جيرا ، إلخ) لمساعدة زملائه في الفريق على مراجعة الأخبار ذات الصلة بسرعة.
عيّن المشكلة لزملائك في الفريق وشاهد ردود الفعل تدور حولها.
في تطوير البرمجيات ، تنبع معظم العيوب من سوء الفهم وليس التكنولوجيا. تساعد المراجعة البصرية الفرق على جمع الملاحظات المستمرة أثناء التطوير لشحن أنظمة التصميم بشكل أسرع.
“لقد كان نشر عنوان URL الخاص بـ Storybook عن كل طلب سحب أمرًا نقوم به لفترة من الوقت في نظام التصميمات في Shopify ، Polaris ، وقد كان مفيدًا بشكل مثير للدهشة.”
بن سكوت ، مهندس في SHOPIFY
اختبار نظام التصميم الخاص بك
المراجعة البصرية لا تقدر بثمن. ومع ذلك ، قد تستغرق مراجعة مئات القصص المكونة يدويًا ساعات. من الناحية المثالية ، نريد أن نرى التغييرات المتعمدة فقط (الإضافات / التحسينات) وأن نلاحظ تلقائيًا الانحدارات غير المقصودة.
