إعادة بيع ديون CSS: مقدمة (الجزء 1)

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

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

إعادة بناء أجزاء كبيرة من كود CSS ليست مهمة سهلة بأي مقياس. في بعض الأحيان ، قد يبدو أنها مجرد حالة "حذف الشفرة ذات الجودة الرديئة ، وكتابة CSS أفضل ، ونشر الكود المحسن اللامع". ومع ذلك ، هناك العديد من العوامل الأخرى التي يجب مراعاتها ، مثل صعوبة إعادة بناء قاعدة بيانات حية ، والمدة المتوقعة واستخدام الفريق ، ووضع أهداف إعادة البناء ، وتتبع فعالية إعادة البناء والتقدم ، وما إلى ذلك. هناك أيضًا مسألة إقناع الإدارة أو أصحاب المصلحة في المشروع بـ استثمار الوقت والموارد في عملية إعادة البناء.

في هذه السلسلة المكونة من ثلاثة أجزاء ، سنخوض عملية إعادة بناء CSS من البداية إلى النهاية ، بدءًا من المعرفة حول كيفية التعامل معها وبعض الإيجابيات والسلبيات العامة لإعادة البناء ، ثم الانتقال إلى استراتيجيات إعادة البناء نفسها والانتهاء مع بعض أفضل الممارسات العامة حول حجم ملف CSS وأدائه.

الآثار الجانبية لسوء الجودة CSS

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

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

نتيجة لذلك ، يمكن أن تتسبب CSS ذات الجودة الرديئة في حدوث مشكلات تتجاوز الأخطاء المرئية البسيطة ويمكن أن تنتج العديد من الآثار الجانبية الشديدة التي يمكن أن تؤثر على المشروع ككل. تتضمن بعض الأمثلة ما يلي:

• انخفاض جودة الكود مع إضافة المزيد من الميزات نظرًا لتباين مستويات مهارات CSS داخل فريق التطوير والافتقار إلى القواعد الداخلية والاتفاقيات وأفضل الممارسات.
• تؤدي إضافة ميزات جديدة أو توسيع المحددات الحالية إلى حدوث أخطاء وآثار جانبية غير متوقعة في أجزاء أخرى من الكود (المعروف أيضًا باسم الانحدار ).
• يمكن فصل محددات CSS المختلفة مع كتل أكواد مكررة أو أجزاء من كود CSS إلى محدد جديد وتمديدها من خلال التباين.
• الأجزاء المتبقية وغير المستخدمة من التعليمات البرمجية من الميزات المحذوفة . فقد فريق التطوير مسار رمز CSS المستخدم والذي يمكن إزالته بأمان.
• عدم الاتساق في بنية الملف وتسمية فئة CSS والجودة الشاملة لـ CSS وما إلى ذلك.
• "جحيم الخصوصية" حيث تتم إضافة ميزات جديدة عن طريق تجاوز قاعدة رموز CSS الحالية بدلاً من قاعدة بيانات CSS الحالية.
• التراجع عن CSS حيث تقوم المحددات عالية الدقة "بإعادة تعيين" نمط محدد الخصوصية الأقل. يكتب المطورون المزيد من التعليمات البرمجية لتقليل التصميم. ينتج عن هذا التكرار والكثير من الضياع في الكود.

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

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

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

"(...) ما بدأ مع PostCSS المنظم نما تدريجيًا ليصبح بنية CSS عالمية معقدة ومتشابكة مع الكثير من الخصائص والتجاوزات. كما قد تتوقع ، هناك نقطة تجعل الدين التكنولوجي الإضافي الذي تقدمه من الصعب الاستمرار في الشحن بسرعة دون إضافة أي تراجع. بالإضافة إلى ذلك ، نظرًا لتزايد عدد مطوري الواجهة الأمامية الذين يساهمون في قاعدة الشفرة أيضًا ، فإن هذا النوع من بنية CSS يصبح أكثر صعوبة في العمل معه ".

إعادة بناء أو إعادة كتابة؟

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

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

يجب إضافة اختلاف آخر للبطاقة ، والذي يشترك في بعض الأنماط من الأشكال المختلفة للبطاقة الأخرى. لذلك من أجل تجنب الأخطاء ، والشفرات المكررة وفئات CSS المعقدة ، وترميز HTML ، قرر الفريق إعادة تشكيل CSS لمكون البطاقة قبل تنفيذ شكل جديد.

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

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

دعونا نلخص إيجابيات وسلبيات كل نهج.

متى يتم إعادة بناء CSS؟

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

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

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

يجب على مطور الواجهة الأمامية أو المطور الذي يتمتع بأكبر قدر من الخبرة مع CSS إثارة المشكلات وإنشاء مهام إعادة البناء لفرض معايير جودة كود CSS في قاعدة الكود.

متى تعيد كتابة CSS؟

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

سبب آخر لإعادة كتابة CSS بالكامل هو عندما يتم التخطيط لإجراء تغيير جوهري على موقع الويب - إعادة تسمية العلامة التجارية أو إعادة تصميمها أو أي تغيير مهم آخر يؤثر على معظم موقع الويب. من الآمن أن نفترض أن أصحاب المصلحة في المشروع يدركون أن هذا استثمار كبير وسيستغرق الأمر بعض الوقت حتى تكتمل إعادة الكتابة.

تدقيق CSS Codebase Health

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

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

عند إجراء تدقيق لـ CSS أو التحضير لمعامل CSS ، أعتمد على العديد من الأدوات المفيدة للحصول على نظرة عامة وإحصائيات مفيدة حول قاعدة كود CSS.

أداة go-to الشخصية الخاصة بي هي CSS Stats ، وهي أداة مجانية توفر نظرة عامة مفيدة على جودة قاعدة بيانات CSS مع الكثير من المقاييس المفيدة التي يمكن أن تساعد المطورين في التعرف على بعض المشكلات التي يصعب تحديدها.

بالعودة إلى عام 2016 ، قامت trivago بعمل إعادة بناء على نطاق واسع لقاعدة كود CSS الخاصة بها واستخدمت المقاييس من CSS Stats لتعيين بعض الأهداف الملموسة والقابلة للقياس مثل تقليل الخصوصية وتقليل عدد تباينات الألوان. في غضون ثلاثة أسابيع فقط ، تمكنوا من تحسين الصحة العامة لقاعدة كود CSS وتقليل حجم ملف CSS وتحسين أداء العرض على الهاتف المحمول وما إلى ذلك.

"يمكن لأداة مثل CSS Stats مساعدتك بسهولة في اكتشاف مشكلات التناسق داخل قاعدة التعليمات البرمجية الخاصة بك. بالإشارة إلى ما يمكن أن يحدث عندما يكون لكل شخص آراء مختلفة حول الشكل الذي يجب أن تبدو عليه النغمة الرمادية ، سينتهي بك الأمر بخمسين درجة من الرمادي. علاوة على ذلك ، يمنحك Specificity Graph مؤشرًا عامًا جيدًا لصحة قاعدة CSS الخاصة بك ".

بالنسبة لأدوات CLI ، فإن Wallace هي أداة مفيدة توفر إحصائيات ونظرة عامة حول CSS أساسية إلى حد ما ولكنها مفيدة والتي يمكن استخدامها لتحديد المشكلات المتعلقة بحجم الملف وعدد القواعد والمحددات وأنواع المحددات والتعقيد ، إلخ.

يقدم Wallace أيضًا أداة محلل مجانية على موقع Project Wallace الإلكتروني الذي يستخدم إصدارًا أكثر تقدمًا على ما يبدو من Wallace في الواجهة الخلفية لتوفير بعض تصورات البيانات المفيدة وعدد قليل من المقاييس غير المتوفرة في Wallace CLI.

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

كتابة CSS عالية الجودة

لقد رأينا كيف يمكن أن تتسبب بساطة ومرونة قاعدة بيانات CSS في حدوث الكثير من المشكلات المتعلقة بجودة الكود والأداء والأخطاء المرئية. لا توجد أداة آلية ذات رصاصة فضية تتأكد من أننا نكتب CSS بأفضل طريقة ممكنة ونتجنب جميع الأخطاء المعمارية المحتملة على طول الطريق.

أفضل الأدوات التي ستضمن أننا نكتب كود CSS عالي الجودة هي الانضباط والاهتمام بالتفاصيل ومعرفة ومهارات CSS العامة . يحتاج المطور أن يكون على دراية مستمرة بالصورة الأكبر وأن يفهم الدور الذي يلعبه CSS في تلك الصورة الأكبر.

على سبيل المثال ، من خلال التحديد الزائد للمحددات ، يمكن لمطور واحد أن يحد بشدة من قابلية الاستخدام ، مما يؤدي إلى اضطرار المطورين الآخرين إلى تكرار الكود لاستخدامه مع مكونات أخرى مماثلة ذات ترميز مختلف. تحدث هذه المشكلات غالبًا عندما يفتقر المطورون إلى الفهم ولا يستفيدون من الآليات الأساسية وراء CSS (التسلسل والوراثة وأداء المستعرض وخصوصية المحدد). يمكن أن تؤدي هذه القرارات المبكرة إلى تداعيات كبيرة في المستقبل ، لذا فإن صحة قاعدة كود CSS وقابليتها للصيانة تعتمد على معرفة المطور ومهاراته وفهمه لأساسيات CSS.

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

بالحديث من تجربة شخصية ، وجدت أن ما يلي ساعدني على تحسين طريقة عملي مع CSS بشكل ملحوظ:

• تعلم الأنماط المعمارية.
  توفر إرشادات CSS قاعدة معرفية رائعة وأفضل الممارسات لكتابة CSS عالية الجودة بناءً على أنماط البرمجة العامة والمبادئ المعمارية.
• الممارسة والتحسين.
  اعمل على مشاريع شخصية أو واجه تحديًا من Frontend Mentor لتحسين مهاراتك. ابدأ بمشاريع بسيطة (مكون واحد أو قسم) وركز على كتابة أفضل CSS يمكنك تجربة الأساليب المختلفة وتطبيق أنماط معمارية مختلفة وتحسين الكود تدريجيًا وتعلم كيفية كتابة CSS عالية الجودة بكفاءة.
• التعلم من الأخطاء.
  صدقني ، ستكتب بعض CSS ذات الجودة الرديئة حقًا عندما تبدأ. سوف يستغرق الأمر بضع محاولات لفهمه بشكل صحيح. توقف لحظة وفكر في الخطأ الذي حدث ، وحلل نقاط الضعف ، وفكر فيما كان يمكن أن تفعله بطريقة مختلفة وكيف ، وحاول تجنب نفس الأخطاء في المستقبل.

من المهم أيضًا وضع قواعد ومعايير CSS داخلية داخل فريق أو حتى للشركة بأكملها. يمكن أن تؤدي المعايير المحددة بوضوح على مستوى الشركة وأسلوب الكود والمبادئ إلى العديد من الفوائد مثل:

• أسلوب وجودة رمز موحد ومتسق
• أسهل في الفهم ، قاعدة بيانات قوية
• تبسيط المشروع على متن الطائرة
• مراجعات الكود المعيارية التي يمكن إجراؤها بواسطة أي عضو في الفريق ، وليس فقط مطور الواجهة الأمامية الرئيسي أو المطورين الأكثر خبرة

عمل كيربي ياردلي على إعادة هيكلة نظام تصميم معهد Sundance و CSS وأشار إلى أهمية وضع القواعد الداخلية وأفضل الممارسات.

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

بالعودة إلى المثال السابق من الفريق في trivago ، أثبت وضع القواعد والمبادئ التوجيهية الداخلية أنه خطوة مهمة في عملية إعادة البناء.

"لقد قدمنا ​​مكتبة أنماط ، وبدأنا في استخدام التصميم الذري في سير العمل لدينا ، وأنشأنا إرشادات ترميز جديدة ، وقمنا بتعديل العديد من المنهجيات مثل BEM و ITCSS من أجل دعمنا في صيانة وتطوير CSS / UI لدينا على نطاق واسع."

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

خاتمة

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

يمكن للأدوات المفيدة مثل CSS Stats و Wallace أن توفر نظرة عامة عالية المستوى على قاعدة كود CSS وتعطي نظرة تفصيلية عن حالة قاعدة الكود وصحتها. توفر هذه الأدوات أيضًا إحصائيات قابلة للقياس يمكن استخدامها لتحديد أهداف عملية إعادة البناء وتتبع تقدم إعادة البناء.

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

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

مراجع

• "إدارة مشاريع CSS مع ITCSS ،" هاري روبرتس
• "إعادة بيع ديون CSS على نطاق واسع في Trivago ،" كريستوف رينارتز
• "Sundance.org Design System و CSS Refactor" كيربي ياردلي
• "من CSS الدلالية إلى Tailwind: إعادة هيكلة قاعدة بيانات Netlify UI Codebase ،" تشارلي جيرارد وليزلي كوهن وين
• "أدوات تدقيق CSS" ، Iris Lješnjanin