כותרת לא אמינה לפוסט הזה אבל זה מה שמצאתי לנכון אז סליחה מראש, בכל מקרה, לכתוב קוד כמו שצריך זה פילוסופיה שלמה ומי שממש רוצה להעמיק בזה שיצפה ב clean code של הדוד בוב.
יש הרבה שיטות לכתוב קוד וכל אחד שהוא מספיק טוב יהיה לו מה להגיד על זה. אז גם מה שאני אומר פה , ככל הנראה חלק יקבלו אותו חלק יהיה להם מה להגיד. כמו כן רוב הדברים שאני אציין פה, יתארו קונבציות בסיסיות ופופולאריות (נכון לימינו בתאריך זה).
לפני שנתחיל, חשוב לציין, כי בחרתי את הדוגמאות קוד בפוסט הזה ב ANGULAR ולכן אולי לא יתאימו בדיוק לפרויקטים אחרים, אבל אנסה להיות כמה שיותר גנרי, ביחס לנושאים שאותם אציין כמובן. אז נתחיל:
HTML – סמנטי . מבנה HTML חשוב מאד
מבנה HTML מדויק יקל עליכם רבות בעובדה, ישפר את החוויה של הגולשים וגם ישפר את הביצועים עבור מנועי החיפוש, אז שימו דגש על מבנה נכון וסמנטיות. אפשר לראות בתמונה כאן דוגמה של HTML סמנטי ולא סמנטי:
ישנן תגיות ייעודיות בHTML ורבים לא מודעים לחשיבות ופשוט עושים הכל ב DIV. אפשרי כמובן, אבל לא אידאלי. השתדלו להקפיד על כך. כמו כן תגיות זה לא הכל, ממליץ גם להגדיר ROLE שצריך , למשל אם תרצו לבנות TABS יהיה נכון להשתמש בהגדרות הנכונות למשל:
<div class="tabs">
<div role="tablist" aria-label="Sample Tabs">
<button
role="tab"
aria-selected="true"
aria-controls="panel-1"
id="tab-1"
tabindex="0">
First Tab
</button>
</div>
<div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
<p>Content for the first panel</p>
</div>
</div>
CSS\SCSS – לכתוב DESIGN SYSTEM
נושא CSS גם נושא שקל הזניח, מתכנתים אוהבים לשבת שעות ולפצח קוד של לוגיקה ופתאום לעצב איזה כפתור עם גרדיאנט וטרנזישן יכול לגרום להם להזיע, וכן גם אפשר לעשות בלגן שלם בעיצוב בקלי קלות. פותחים ת inspect משנים קצת פרופס עושים קופי פייסט לסלקטור והופה הכל נראה טוב. גם שמעתי על כאלה שדפקו להם בדלת בגלל חוסר סדר בסטיילינג אז אם לא בשבילכם אז לפחות תעשו חיים קלים למפתחים אחריכם שלא יהיה מצב לא נעים 🫣.
בשביל לעשות חיים קלים כל מה שצריך לעשות זה DESIGN SYSTEM . שם מפוצץ עם הרבה משמעות אבל נתחיל בקטן. כל מה שצריך לעשות זה לפרק את העיצוב בצורה יעילה, לבנות קובץ כללי שיכיל את כל מה שאתם צריכים ברמת הDESIGN , צבעים במשתנים, קלאסים שחוזרים על עצמם בהרבה מקומות, תאימות למכשירים בהתאם למידות שאתם מעדיפים (break points), סט אנימציות ועוד אפשרויות עם SCSS כמו פונקציות, MIXIN ועוד…
סדרו תיקיות לקבצי העיצוב ושמות הגיוניים, למשל בangular אני עושה משהו כזה:
יש לי תיקיה של הסטיילינג הככלי ושמה אני מפצל לקבצים ומשתמש ב import למשל כך:
ובשביל שאוכל לעשות import בקלות אני מגדיר בangular.json כך:
ברגע שיש לכם תיקיה ראשית להגדיר את כל מאפייני העיצוב אז כל מה שנשאר לכם זה להשתמש בהגדרות אלו ברכיבים השונים בקבצי הסטיילינג הפרטיים של אותם רכיבים וכך יהיה לכולנו חיים מסודרים יותר.
מבחינת כתיבת CSS , יש חשיבות לכתיבה אבל לרוב מאד זניח, יכול כמובן לפגוע בפרפורמנס אבל בדפדפנים של היום זה לא כזה מורגש, השתדלו לתת את המינימום הנדרש סלקטור, לדוגמה אם תרצו ליישר אלמנט למרכז אל תעשו flex, פלקס מביא איתו עוד המון הגדרות עיצוב לסלקטור, שכן כל מה שתצטרכו זה text-align: center
קוד מודולרי – לחלק למודולים בגבול הטעם הטוב
אחד הדברים שקורים להרבה מפתחים מתחילים זה שהקוד שלהם קשה לתחזוקה, ועם הזמן שהופכים מתכנתים מנוסים יותר אז שמים יותר דגש על קוד שנוח לתחזק. אחד מהשיטות לקוד נוח לתחזוקה הוא חלוקה מסודרת של קבצים ופונקציות שעושות משימה אחת בלבד, כלומר פונקציות קטנות ככל האפשר. מצב זה יבטיח נוחות מרבית בתחזוקת הפרויקט. בין אם החלטתם לכתוב פרויקט בJS או להשתמש באיזה framework\library תמיד ביכולתכם לחלק את הפרויקט לחתיכות בתוך תיקיות שונות ושמות בעלי משמעות לכל קובץ. כמו כן בעבודה עם ריאקט או אנגולר וכדומה, יהיה נוח יותר לבצע זאת, כי ישנה תשתית מוכנה מראש, ובכל זאת יהיה לכם קל לעשות בלגן. אז כמו שכבר הסברתי בפוסט קורס front end – קיבלתם פיצ’ר, מזל טוב! מה עכשיו? ומאיפה להתחיל? קודם כל, מתכננים. ועכשיו שאתם נגשים לקוד, התחילו בלייצר את התיקיות והקבצים המרכזיים ואז יהיה לכם מבנה ראשוני שיעשה לכם סדר בדברים. למשל:
הדטה הוא המלך – הגדירו את תצורת המידע וזרימת המידע בין הרכיבים
צרו את המודל של המידע שאותו כבר הגדרתם, והגדירו תרשים מתי ואיפה מגיע המידע וכיצד המידע מחלחל בין הרכיבים השונים שעליהם אתם אחראיים. ולאחר שיש לכם את התרשים ב figma תוכלו לגשת לקבצים וליצור את הCLASS, TYPES, INTERFACE, ENUMS שאתם צריכים.
כתיבת קוד עם משמעות והסברים מסודרים
לרשום שם לפונקציה או למשתנה אני מאמין שכולם יודעים לעשות ומי שקצת מתקשה בשליפת שמות טובים יכול להיעזר ב copilot שלרוב עושה זאת נהדר. אל תחששו משמות ארוכים, לפעמים שם פונקציה יעזור למפתחים אחרים להבין במהירות מה אתם התכוונתם ואם תחסכו, אתם תאלצו את אותו מפתח לעבור על הפונקציה ולהבין מה היא עושה, אם הפונקציה מקבלת פרמטרים, אנא רשמו בקצרה מה תפקידו של כל פרמטר, אם זה לא מספיק ברור כמובן, וכן אם הפונקציה שלכם עושה איזה חישוב מסובך ודורש הסברים אז תוסיפו קומנט מעל הפונקציה שמסביר קצת יותר כך שאותם מפתחים שירצו להשתמש בפונקציה שלכם יוכלו לקרוא 2 -3 משפטים ולדעת כיצד משתמשים בפונקציה ומה אי עושה בדיוק. אני יודע שלרשום קומנטים זה נורא ואיום אבל אתם לא מבינים כמה אתם יכולים לחסוך למערכת וכן להיות מוערכים מאד על ידי חברי הצוות האחרים. אם בכל זאת אתם מתקשים לרשום קומנטים, היעזרו ב copilot labs שיעשה את זה עבורכם, רק עברו אחריו וודאו שהוא אכן רשם דברים הגיוניים.
אפשר לראות בצד שמאל ש copilot labs נתן הסבר לא רע , אומנם הפונקציה לא באמת מעניינת אבל לצורך הדוגמה זה מפסיק אני מקווה, כמו כן ישנו כפתור נוסף למטה שנקרא document ולחיצה עליו תוסיף ישירות קומנט שמסביר את אותו קטע קוד.
עבודה עם טייפים
מאד ממליץ לעבוד עם טייפים בTS. התעקשו על כל משתנה והפונקציה שיהיה מוגדר היטב עם טייפ המתאים, השתדלו להימנע מטייפ ANY. כמו כן אם אתם מריצים לינטר אז לא תוכלו להתחמק מ ANY (תמיד אפשר להתחמק תלוי כמה אתם פדנטים עם הערות warning).
טסטים – test driven development
מודה כי אינני רגיל לחשוב בצורה זו (עדיין) יש מספר פרויקטים בודדים שמימשתי בהם unit tests והחשיבות של כך היא תלוי מיזם שבו תעבדו, מה שכן, לעבוד בשיטת TDD עושה חיים קלים לכתיבת טסטים, וגם מיישר את הקוד להפליא כשאתם חושבים על הבדיקה של הפונקציה בעודכם כותבים אותה.
סיכום קורס front end – שלבים הראשונים בלכתוב קוד כמו שצריך
פוסט ארוך יחסית. עם הרבה נקודות חשובות שיעזרו לכם לכתוב קוד תקין ומסודר. חלק מהשיטות לא יעבדו עבור כולם, אפילו עבורי, למשל TDD ברוב הפרויקטים שלי אני לא מייחס לזה חשיבות (לפחות נכון להיום) עבדתי על 3 פרויקטים בחיים שלי ששמנו דגש על unit test וזה היה דיי מדהים. אז תלוי אופי פרויקט. יאללה ממשיכים לפוסט הבא בוא נתקדם לתוך הכתיבה ונראה דוגמאות ספציפיות של קבצי פרויקט שהכנתי עבורכם.
בהצלחה 🐊😎
