בניית קוד נקי ומסודר – ממתחיל למקצוען #2

המאמר הזה הוא המשך למאמר: דע איך האינטרנט בנוי – ממתחיל למקצוען #1

מבט קצר בקוד

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

אז כמה נקודות חשובות בותר לקוד מסודר:
(הסבר על כל אחת מהנקודות נמצא למטה)

• DRY – אל תחזור על עצמך
• MVC והפרדת עיצוב מתוכן
• חלוקה למשימות פשוטות
• שמות משתנים ופונקציות
• קומנטינג
• טאבינג

אבל לפני שנכנס נקודה נקודה ונסביר נבין למה כל זה חשוב.

למה לי לכתוב מסודר מה שאני כותב עובד מצוין

קוד קריא

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

תחזוקה, שינויים ותוספות

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

• הלקוח שלנו מבקש אנחנו רוצים לשנות משהו
• הלקוח שלנו מבקש אנחנו רוצים להוסיף או להעיף משהו
• לאחת הframeworks או הספריות שאנחנו משתמשים בהם יצא עדכון לאבטחה או ביצועים או עדכון עם תכונות חדשות שאנחנו רוצים

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

debugging

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

אני רוצה לכתוב בצורה מסודרת, איך עושים את זה?

DRY – אל תחזור על עצמך

אולי הדבר הבודד הקריטי ביותר, מתוך עקרון זה נובעים חלק מהדברים הבאים.
תדמיינו שאתם בונים אתר, באתר שלכם כמובן מופיע הסלוגן שלכם, אז כל פעם שאתם כותבים דף חדש אתם כותבים איפשהו בחלק העליון "האתר שלי – האתר הכי מגניב ברשת".
אתם כותבים עוד ועוד דפים ואתם פשוט לא מבינים למה אף אחד לא אוהב את האתר שלכם, חבר שלכם אומר לכם שהמילה מגניב מזמן יצאה מהאופנה וזה גורם לכם להראות גיקים, אז אתם לשנות את המילה מגניב הגרועה למילה "טוב" עכשיו תאלצו לעבור דף דף למחוק מה שכתבתם ולכתוב "האתר שלי – האתר הכי טוב ברשת".
המקרה הזה הוא הרע במיעוטו כי אם הבעיה מתעוררת באפליקציה ואתם לא יודעים מאיפה היא מגיעה והתקלה מתעוררת רק בדפים מסוימים, אתם תאלצו לערוך את כל הדפים רק בשביל לגלות שאומנם פתרתם את הבעיה עבור חלק מהדפים אבל עבור חלק לא ויצרתם בעיה אחרת בדפים אחרים.
הסיוט הזה הוא חלק בלתי נפרד מחייהם של המתכנתים שעוברים על עיקרון זה.
והפתרון הוא דיי פשוט למרות שלפעמים בהתחלה הוא נראה כבזבוז זמן, במקום לעשות copy paste לחתיכת קוד, שימו אותה בפונקציה או עם זה רק סטרינג או מסתפר שימו אותו בקבוע (constant) זה לא רק יחסוך לכם זמן בטווח הרחוק ויעזור לכם בדיבאגינג זה גם יגרום לקוד שלכם להיות יותר קריא.

MVC והפרדת עיצוב מתוכן

עיקרון זה היא הלחם והחמאה של עבודת צוות בתכנות (bread and butter הבנתם?) אבל גם אם אתם עובדים לבד כדאי מאוד לאמץ את סגנון העבודה הזה. היום נדבר רק על היתרונות מנקודת מבטו של המתכנת הבודד.
פעמים רבות נרצה לשנות רק תוכן של משהו או רק את איך שהוא נראה בלי להשפיע על האחר.
דוגמה רעה של עיצוב מעורבב עם תוכן:
נגיד שמעצבן אותי שהרווח בין פסקאות קטן מידי אז אני אוסיף בתוכן שלי אחרי כל פסקה את התו <br /> בעיקרון פתרתי את הבעיה בלי להתעסק עם בקובץ הדפוק הזה style.css אני מלך העולם. הבעיה תתעורר כשאני פתאום ירגיש שהרווח עדיין קטן מידי או שהוא פתאום מרגיש לי גדול מידי דיברנו כבר על DRY נכון?
בשביל ללמוד קצת על MVC אפשר לקרוא את הכתבה: model – viewer – controller או מה זה MVC?

חלוקה למשימות פשוטות

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

שמות משתנים ופונקציות

מה לעשות

לפונקציות – שמות שמתארים מה מחזירה הפונקציה

פונקיצה שמקבלת מספרים ומחזירה את הגבוהה מבינהם תקרא max או maxValue ולא insertNumber או twoNumbers או כל דבר אחר שאיך שהוא גם מייצג אותה

למשתנים – שמות שמתארים מה מחזיק המשתנה

משתנים לא יקראו x, y או yossiInt אלא אם התוכנית שלנו דורשת שננחש את המספר של יוסי וגם אז יש לשקול לקרוא למשתנה משהו בסגנון trueNum או rightNum

למשתנים – שימוש בסטנדרטים

ישנם יוצאי דופן לחוק הקודם i וj הם שמות טובים לאינדקסים של לולאות וn וm יתאימו לשימוש במטריצות, אם נרצה לחשב שטח של מעגל נוכל להשתמש בr כערך הרדיוס למרות שאולי עדיף לקרוא לו radius

אחידות בשמות

נבחר לנו קווים מנחים לשמות וצורת כיתוב ונשאר איתה לעורך כל התוכנית צורות כתיבה המקובלות ביותר הן דבשות גמל (נחשו למה קוראים לזה ככה) דוגמה: thisStringIsVeryLong או שימוש בקווים תחתונים this_string_is_very_long

שמות קצרים במידת האפשר

בדרך כלל נעדיף את max על highestNumerFromUserInput או משהו בסגנון, אלא אם יש לנו המון המון משתנים עם שימושים דומים וצריך להבדיל ביניהם לא נרצה שיהיה לנו max1 max2 וmax3 כשלא ברור בדיוק מה ההבדל בניהם

מה לא לעשות

שמות בעברית

misparGadol זה לא שם למשתנה ובטח שלו teodatZeotShelSavta

לא מתחילים שם במספר

למרות שיש ספר שמרשות את זה, לא נעשה את זה בשביל להשאיר את הקוד מובן

קומנטינג

כתבתם משהו שאתם לא ב100% בטוחים שמישהו מפגר יבין תכתבו הערה, כדי שעוד חודשיים המפגר הזה לא יהיה אתם :)
לא סתם כל השפות שאני מכיר מאפשרות קומנטינג, אפילו שפות בלי לוגיקה כמו HTML וCSS מאפשרות את זה ולא סתם, אין דבר כזה יותר מידי קומנטינג ועדיף להשקיע עוד 10 שניות ולכתוב הערה מאשר אחר כך שעתיים ולנסות להבין מה למה כתבתי משהו.

טאבינג

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

אני לולאה:

• ואני שורה שמתבצעת בלולאה
• אני תנאי בלולאה
• • אני מתבצע בתנאי
  • וגם אני
• אני עוד שורה בלולאה

אני תנאי ואני קורה אחרי הלולאה:

• ואני מתבצע בתנאי

המשך יום נעים וקוד נקי!