כיצד Refactor CSS - מדריך

CSS refactoring צריך להיות חלק חיוני של העבודה הקדמי פיתוח עבודה, אם אנחנו רוצים יש בסיס לניהול וממוטב קוד. כאשר אנו refactor CSS, אנחנו לנקות ולארגן מחדש את הקוד הקיים שלנו מבלי להוסיף תכונות חדשות או לתקן באגים.

Refactoring עוזר למנוע פיצוץ CSS, משפר את הקריאות קוד reusability, ו עושה CSS שרוול ומהיר יותר לבצע.

Refactoring נדרש בדרך כלל לאחר זמן מה, כמו גם פרויקטים שהתחילו עם בסיס קוד תמציתי מאורגן במוקדם או במאוחר להתחיל לאבד את בהירותם; עקביות, כללים מיושנים וחלקי קוד כפולים מופיעים; ואנחנו גם מתחילים לעקוף סגנונות ולהשתמש יותר ויותר פריצות דרכים לעקיפת הבעיה.

הדרך הטובה ביותר לשמור על בסיס קוד CSS שלנו היא לתחזוקה היא לדבוק “refactor מוקדם, refactor לעתים קרובות” כלל אצבע. במאמר זה נסקור כמה טיפים לגבי האופן שבו אנו יכולים לנהל תהליך יעיל של refactoring ב- CSS.

1. לערוך ביקורת ראשונית

כדי לקבל תמונה טובה יותר על מה שאנחנו צריכים כדי refactor, זה הכי טוב להתחיל עם ביקורת מקיפה כדי לראות מה יש לנו כרגע.

יש הרבה כלים מקוונים גדולים שיכולים לעזור לנו במאמץ זה. CSSDig הוא תוסף Chrome רב-עוצמה המנתח את ה- CSS של אתר אינטרנט, וחוקר את חולשותיו, כגון בוררים ספציפיים מדי או מאפיינים חוזרים.

CSS שאינו בשימוש חוקר כללי CSS שאינם בשימוש, ואילו כלי צביעה, כגון CSS Lint, מאפשרים למצוא במהירות יכולת תחזוקה, תחזוקה ונושאים אחרים.

חשוב גם לבדוק באופן ידני את הקוד במהלך הביקורת הראשונית, כמו בעיות רבות ברמה האדריכלית יכול רק להיתפס בדרך זו.

.2 הגדר תוכנית ניתנת לניהול

Refactoring קוד עובד תמיד משימה מרתיעה, אבל אנחנו יכולים להקל על הכאב אם אנחנו יוצרים תוכנית על מה שאנחנו צריכים לעשות, לחתוך את תהליך refactoring לגושים לניהול, ולעשות לוח זמנים ריאלי.

ב CSS refactoring יש דבר חיוני אנחנו תמיד צריכים לקחת בחשבון: כמה דברים שאנחנו refactor, למשל שינוי שמות הבורר, יעשה את זה הכרחי כדי להתאים את הקוד של קבצי HTML ו- JavaScript הרלוונטיים גם כן.

לכן זה רעיון טוב עקוב אחר השינויים הנוספים שנצטרך לבצע, ו לבנות אותם לתוך לוח הזמנים שלנו refactoring יחד עם המשימות העיקריות הקשורות ל- CSS.

3. עקוב אחר התקדמות

לפני היציאה refactoring, זה צעד חיוני לגבות את הקבצים הראשוניים שלנו. הצגת מערכת בקרת גרסאות, כגון Git או Subversion, לזרימת העבודה שלנו יכולה גם לשפר באופן משמעותי את תהליך ה- Refactoring, שכן יהיה לנו רישום לגבי הצעדים הרצויים שנקטנו, ואנו יוכל לחזור לשלב הקודם אם אנחנו רוצים לעשות דברים מחדש.

4. היצמד מדריך סגנון קידוד

מדריך קוהרנטי סגנון הסגנון יכול לשפר באופן משמעותי את הקריאות קוד ותחזוקה, אז לפני שאנחנו מתחילים refactor זה חיוני כדי להגדיר מדריך CSS קידוד סגנון.

הדברים החשובים להחלטה הם:

• - מוסכמות למתן שמות
• כללי עיצוב
• צו הכרזה
• יחידות וערכים שאנו רוצים להשתמש בהם
• חוקי הערות

אם אנחנו לא רוצים ליצור את הסגנון שלנו מדריך קידוד, אנחנו יכולים גם להשתמש של מישהו אחר, כגון ThinkUp אשר ניתן למצוא על Github.

זה לא מספיק אם רק להציג מדריך קידוד בסגנון, אנחנו גם צריכים מקל על זה כאשר אנו לשכתב את הקוד במהלך refactoring, ו לצפות אותו מכל האחרים שעובד על הפרויקט שלנו.

5. הגדרת מבנה קובץ קוהרנטית

אחרי שאנחנו מוכנים עם ההכנות, הדבר הראשון שאנחנו צריכים לעשות הוא להקים מבנה קובץ CSS הנכון שמשלם את תשומת הלב לאופי מדורגים של CSS.

זה בעיקר תלוי בפרויקט איך הכי טוב לארגן את הקבצים שלנו, אבל יש כמה כללים אוניברסליים, כגון להשתמש נפרד normalize.css קובץ עבור סגנונות לאיפוס CSS, נפרד global.css עבור סגנונות גלובליים המשמשים את כל הפרויקט, וכן לאחסן ספריות צד שלישי בתיקיה נפרדת.

אם אנחנו רוצים לשחק בטוח עם מבנה קובץ CSS שלנו, יש גם ארכיטקטורות מוכנות, כגון SMACSS או ITCSS, המציעים טכניקות יעילות על כיצד לארגן קבצי CSS בצורה ניתנת להרחבה.

6. להיפטר של כללים שאינם בשימוש וכפל

לאחר זמן מה, קבצי CSS בדרך כלל מתחילים בשפע בכללים שאינם בשימוש, כי אנחנו צריכים לזהות ולנקות במהלך refactoring. ישנם כלים מקוונים רבים המאפשרים לנו לחקור את הכללים האלה מיושן, ולפעמים גם לאפשר לנו במהירות תעלה אותם.

הכלי הידוע ביותר למטרה זו הוא כנראה UnCSS, מודול Node.js שמאפשר להיפטר מכללי CSS שאינם בשימוש במהירות, והוא גם מספק לנו אפשרויות תצורה מתוחכמות המקלות על תהליך הניקוי.

חשוב לקחת בחשבון שאנחנו לא בהכרח רוצה להסיר את הכללים שאינם בשימוש מ את כל קבצי CSS שיש לנו, לדוגמה מגיליונות סגנונות גלובליים, איפוס או צד שלישי, לכן אנו זקוקים לכך לא לכלול אותם תוך ביצוע הניקוי.

יחד עם הכללים מיושן, כללים כפולים גם להוביל bloat קוד מיותר וביצועים הפסד. אנחנו יכולים להסיר אותם באמצעות מודול CSS Purge Node.js, אבל אנחנו יכולים גם לעבוד עם CSS linters כדי לחפש כללים כפולים בקבצי CSS שלנו.

7. הפחתת הספציפיות

הספציפיות של בורר CSS מחושבת מהמספר וסוגי הסלקטורים הפנימיים שהוא מכיל. סגוליות CSS באה לידי ביטוי כמספר בן 4 ספרות שהכי קל להבין אם אנחנו בודקים את המחשבון החזותי CSS הזה:

הספציפיות הנמוכה ביותר (0001) שייך לסלקטורים שמכוונים רק אלמנט HTML כללי אחד, כגון

או

. ככל שבוחרים פנימיים יותר בורר תרכובות מכיל, כך הסגוליות שלו גבוהה יותר.

סלקטורים מסוימים, כגון id או סלקטורים שמגיעים מסגנונות מוטבעים, יש להם קדימויות גבוהות יותר משום שהם עוקפים את הסגנונות השייכים לבחירה כללית יותר. לדוגמה את הספציפיות של # id1 28- J 0100.

ב refactoring, המטרה היא להקטין את הספציפיות של בוררים (לשמור אותם קצר) ככל שזה אפשרי, כמו סלקטורים בעלי סגוליות גבוהה יותר מפחיתים באופן משמעותי את יכולת השימוש של הבורר, ו להוביל לבסיס קוד נפוח.

שלושת הסוגים העיקריים של בוררי סגוליות גבוהים הם:

1. סלקטורים מוסמכים, כמו p.class1 (הגדרת עמ ' תג אינו מיותר כאן, שכן זה עושה את זה בלתי אפשרי להשתמש באותה הכיתה עם אלמנטים אחרים HTML)
2. בוררים מקוננים עמוקים, כמו .class1 .class2 .class3 .class4 ...
3. תעודות זהות, כמו # id1

כלים מקוונים, כמו CSSDig המוזכרים בשלב 1, ניתן להשתמש בהם כדי למצוא במהירות אלה בוררים סגוליות גבוהה. זה גם יכול להיות שימושי כדי להגדיר כלל במדריך קידוד סגנון על דברים כמו רמת מקסימלית של קינון, או מגבלה על שימוש id סלקטורים.

8. עשב החוצה !חשוב כללים

כללי CSS ואחריו !חשוב הצהרה לעקוף כללי סגנון רגיל. שימוש !חשוב הכללים במוקדם או במאוחר להוביל לקוד לא ברור. זה לא צירוף מקרים רוב הכלים linting לסמן אותם כשגיאה.

כאשר אנו צריכים לכתוב CSS במהירות, אנו עשויים להתחיל להסתמך עליהם אף כי בגלל הפשטות שלהם.

הבעיה העיקרית עם !חשוב הצהרות הן שאם אנחנו רוצים לעקוף אותן בעתיד, אנחנו צריכים לשים יותר !חשוב הצהרות בשימוש, ולכן עדיף לנכש אותם בכל מקום אפשרי במהלך תהליך refactoring.

9. לנקות את מספרי הקסם ואת ערכי coded קשה

במהלך העבודה היומיומית שלנו CSS, לפעמים אנחנו נתקלים בבעיות שאנחנו לא יכולים לפתור, ואנחנו מתחילים להשתמש שנקרא מספרי קסם, ערכים שעובדים מסיבות מסוימות, אבל אנחנו לא מבינים למה. לדוגמה לקחת את הדוגמה הבאה:

 .Class הצ/ מוחלט top: 28px; משמאל: 15.5%; 

הבעיה העיקרית עם מספרי הקסם היא שהם נסיבתי, והם מגלמים את “תכנות על ידי תמורה” אנטיפטרן. במהלך תהליך refactoring אנחנו צריכים להסיר את הכללים שרירותי מהקוד שלנו, ולהחליף אותם עם פתרונות סבירים יותר בכל מקום אפשרי.

אותו כלל אצבע חל ערכים מוצפנים גם כן. כנראה התרחשות השכיחה ביותר של ערכים מוצפנים ניתן למצוא בכללים גובה גובה:

 / * רע, נצטרך להוסיף כללי גובה קבועים נוספים עבור אלמנטים של הילד .class1 * / .class1 font-size: 20px; line-height: 24px;  / * טוב, את הגמישות קו גובה גמיש ניתן להשתמש בבטחה על ידי אלמנטים הילד גם כן * / .class1 font-size: 20px; גובה קו: 1.2; 

ערכים מוצפנים מקודדים את הקוד שלנו, ונוקשים יותר, ולכן כחלק מחידוש הנתונים אנו צריכים לחפור אותם, להחליף אותם עם ערכים גמישים.

10. יחידות וערכים מחדש

כדי להפוך את התחזוקה ואת איתור הבאגים לקלה יותר בעתיד, וכדי למנוע כשלים שיכולים לנבוע משימוש ביחידות שונות, כגון em ו px, בעת ובעונה אחת, אנחנו צריכים מקל על כללים קוהרנטיים לגבי האופן שבו אנו משתמשים בערכים יחסיים ומוחלט.

אם השתמשנו בהם באופן לא עקבי בעבר, אנחנו צריכים להמיר אותם כך שהם יכולים להוות מערכת תמציתית

אם אנו משתמשים יותר מדי צבעים דומים באתר שלנו, זה יכול להיות גם דבר חכם לתרץ את ערכת הצבעים על ידי צמצום מספר הצבעים שאנו מעסיקים. (הנה הודעה על איך לבחור ערכת צבע האתר בצורה מעשית).