<<לחץ כאן למעבר לשיעור 1
שלום לכולם!
בשיעור הזה נתחיל לדבר, על מה הופך קוד לנקי, אמין ובר תחזוקה לטווח הארוך.
ההבדל הכי יסודי והכי בסיסי שעושה את הקוד לנקי או מלוכלך, זה ההיבט שלו, האם הוא גנרי או ספציפי. קוד גנרי תמיד יהיה בעל נטייה נקיה יותר מאשר קוד ספציפי.
כלל הזהב בכתיבת קוד, שאסור בשום פנים ואופן, לכתוב קוד פעמיים, אם יש לך קוד שחוזר על עצמו, בקונבנציות שונות, אתה צריך לבדוק את עצמך היטיב היטיב, אם אתה לא חוטא. קוד שמבצע פעולה מסויימת, ניתן יהיה לקרוא לו ממקומות שונים לביצוע הפעולה.
מכאן מושפעים 2 שלבים נוספים הכרחיים בארכיטקטורה
הראשון הוא קריאת שמות לפונקציות ואובייקטים למיניהם, כאשר השמות אף הם צריכים לייצג את הפעולה הטהורה של הקוד שבפנים, ולא את התוצאה הגסה. (הערה: נדבר בהרחבה על קריאת שמות לאובייקטים, לפי פעולה או לפי תוצאה, ויש בזה תיאוריות נוספות, אין לשלול קריאת שם לפי תוצאה, בפרט בפונקציות שאמורות להחזיר ערך וזהו כל מהותן, אולם כאן אני שם דגש, על כך שהפונקציה צריכה להיקרא בשם הנקי שלה, הגנרי, ולא בשם ספציפי שמתאים למטרה הסופית של הלקוח הנוכחי)
השלב השני, הוא אישכול נכון של הקוד. אישכול הוא בעצם נגזר של הקפדה על קריאת שמות נכונים לאובייקטים, והאישכול הוא בסך הכל הרחבת משפחות השמות, לפי הקשר של נושאים ונשואים. כל זה נותן שליטה בלתי רגילה בקוד ענק, וככה אפשר לנהל פרוייקטים גם בסדר גודל של לינוקס.
כטבעו של עולם, לכתוב קוד גנרי זה הרבה יותר קשה מנטלית, בפרט בתחילת הדרך, בעיקר בגלל העצלות הטבועה בנו כבעלי חיים, אולם בהמשך כאשר רואים תוצאות, זה הופך להיות חווייה עילאית. זהו עיסוק תמידי באידיאות, ולכן לדעתי מתכנת אמיתי לא נשחק לאורך השנים, אלו שנשחקים ומרגישים עבודה אפרורית, הם האנשים שבאמת עושים עבודה שחורה, ואינם אחראיים על קוד אלא כותבים קוד.
גם כשאתם כותבים קוד ללקוח שמתעסק בתחום מאוד מאוד ספציפי כגון ניהול משולח"ים למיון חרקים בעלי שש רגלים ומעלה באזורים הקרים של צפון אירופה. לעולם הפרוייקט שלכם לא יכיל יותר מ 10% קוד ספציפי מותאם לקוח. ככל שתצמצמו את כמות הקוד הספציפי, כך הקוד יהיה נקי יותר.
לאור הדברים הללו, נחזור לדוגמאות שהבאנו בשיעור 1.
איך אמורים לנהל ערכים של קומבו??? הבה ונחשוב, כאשר יש לנו טבלה אחת גדולה לכל הקומבו בוקס, הבה ונניח, שהלקוח החליט יום אחד להוסיף גם "הסברים צפים" tooltip לכל ערך ברשימה.... אוי, יש לנו 20 טבלאות להוסיף להם עמודות.... לא הכי נעים. אבל אם מדובר בטבלה אחת, עמודה אחת לאותה טבלה ונגמר הסיפור. אם נניח הוא רוצה צבעים??? אין בעיה, עמודה שתכיל ערך של צבע.
תחשבו על ה UI בעצם כשאנו רוצים לנהל קומבו בוקס, יש לנו אובייקט UI אחד ויחיד, שאיתו אנו מתנהלים, רוצים tooltip?? אין בעיה, מוסיפים לו. רוצים ניהול צבעים לערכים??? שום בעיה ברגע אחד שינינו את כל הפרוייקט.
בוא נגיד שהוא החליט שהערכים צריכים להיות אפשריים גם באנגלית, עוד עמודה של אנגלית ונגמר הסיפור, לקומבו הגנרי הכללי, מוסיפים פרמטר של שפה, והערכים מתקבלים בשפה הרצויה. וכן הלאה וכן הלאה וכן הלאה.
בנושא של טרנזקציות פיננסיות, אני כמובן אהיה חסיד של השיטה האחרונה הדוגלת בטבלה אחת ענקית, כאשר שאילתות מולה נעשות בצורה הכי גנרית שיש בעולם. אם נרצה לחבר את ההכנסות, הזיכויים, ההתחייבויות העתידיות, ההכנסות הקבועות (סוג של טרנזקציה הייתי אומר) הוראות הקבע, בסך הכל לשנות את משפט ה where של SQL ולקבל תשובה מיידית. אם נרצה להוסיף עמודה שתתאר גם מי אחראי על הטרנזקציה (בכל ארגון למשל יש כמה מורשי חתימה שכותבים שיקים, או כמה אנשים שאוספים תרומות או מקבלים כסף מלקוחות, וכן הלאה), לא נצטרך להוסיף אותה בחמישים טבלאות, בטבלה אחת הוספנו אותה והסיפור הסתיים!!! כשנרצה לדעת באמצעות שאילתה, כמה הוצאות דלק היו באמצעות שליח מסויים???? נוכל בתוך פחות ממיליארדית השניה לקבל סיכום מלא!!!! ולא נצטרך קוד שבנוי מחמישים שאילתות.... לא מקסים????
בשיעור הבא נדבר על הנושא החשוב קריאת שמות לאובייקטים.
פורסם במקור בפורום CODE613 ב18/07/2013 01:32 (+03:00)
