כתיבת קוד כסיפור
-
שלום חברים.
כשיש פרוייקט גדול ומשמעותי, ניהול הקוד עובר מהמיקרו אל המאקרו. כבר לא מדברים על מחלקה שבנויה טוב, אלא על אוסף של מחלקות שנמצאות בניימספייס המתאים, ועל אשכולות שלמים של ניימספייסים. קחו לדוגמא את המחלקות של דוט נט עצמם תראו כמה הם השקיעו בניימספייסים.ברוב הספרות המקצועית, מדברים על איכות קוד ברמת הקריאות של הפקודות, הפונקציות וכדומה. אולם פחות ראיתי שמדברים על מה נקרא קוד איכותי מבחינת ניהול של מאות ואלפי מחלקות.
ברצוני להציג כאן נקודה מעניינת, כאשר עוברים בניהול קוד מהמיקרו למאקרו, אנו נכנסים לתחום חדש לגמרי: ספרות, כן כן יצירת אמנות המובעת בכתב. לא סתם קוראים לזה "ספריית קוד", כשזה קוד גדול מידי, המבחן האמיתי שלו אם הוא ניתן לניהול ושליטה או לא, הוא האם הוא כתוב בצורה של סיפור קולח, שהקורא אותו פשוט רואה כאן סוג של "עלילה" מתפתחת, בתוך תבנית. כשהוא מדלג ומדבג ונמצא בשכבה השנים עשר של איזו פונקציה שקראה לפונקציה שקראה לפונקציה וכו', הוא לא מאבד ראש, כי העלילה פשוט קולחת.
אם ייצא לכם פעם לנהל פרוייקטים עם מעל מאה מחלקות, הנושא הזה חשוב מאוד. אני בדרך כלל מקפיד לבדוק האם כשמגיעים מהקונטרולר (אני מדבר על פרוייקט API בדוט נט) שהוא בעצם "השער" של הקוד לעולם החיצון, איך זה נראה משם, האם משם הסיפור קולח? כשאתה מדבג את הקוד ויורד במורד השכבות (נניח עד למסד הנתונים, שם ה"סיפור" קצת משתנה) האם אתה רואה כאן סיפור, או סידרת פעולות יבשות מורטת עצבים. כל עוד אתה בתוך סיפור, אתה שורד. ברגע שאתה רואה כאן סדרות של פעולות "שהמחשב צריך לבצע" לא תוכל להחזיק מעמד.
לכן לדעתי, יש להסתיר ככל הניתן בקוד את הבלוקים המטפלים ב"עבודה שחורה" (נניח ניקוי סטרינג מתווים לא חוקיים לדוגמא, או המרת סטרינג לאינט) אני נוהג לעשות זאת בשיטה הבאה: ראשית, עבודה שחורה של הקוד, אני עוטף ב region שרוב הזמן הוא מוסתר ב IDE, ושנית ככל שניתן אני כותב את העבודות השחורות בתחילת הפונקציה כדי "להיפטר" מהם כמה שיותר מהר.
גם הנושא של חלוקה לפונקציות חשוב מאוד בהקשר הזה, ככל שאתה רואה בקוד כתיבה של "סיפור" השיקול העיקרי שלך את מה לחלק לפונקציה נפרדת, הוא מה עלול להפריע לסיפור כ"רעשי רקע" ומה דווקא מתחבר טוב לעלילה, וחבל לוותר עליו. כך שלפעמים דווקא כדאי לכתוב פונקציה עם הרבה שורות קוד, מאשר לחלק אותה לחמש פונקציות אחרות, דווקא בגלל שבמצב השני אנחנו עלולים להפסיד את אפקט הסיפור. לכן לא כל קוד ארוך הוא גרוע, ולא כל קוד קצר הוא טוב. קוד הוא טוב כשאתה חוזר אליו אחרי שנה או שנתיים (וזה כבר קורה לי הרבה) ומצליח להשתלב בתנועה די בקלות.
גילוי נאות, ב SQL המצב קצת שונה (כלומר קצת קשה לממש את התיאוריה הזו, היא תקפה בעיקר בתיכנות אובייקטאלי), אם כי לאחרונה עליתי על כמה רעיונות איך להפוך קוד SQL ליותר קריא, נחשו מה? שימוש טבלאות זמניות! הופך את הקוד לקריא מאוד. טבלה זמנית שמזינים אותה בנתונים בסיסיים, ולאחר מכן מעדכנים בה את השדות הריקים בפעולה אחרי פעולה, במקום סלקט עם הרבה ג'וינים.
וגם שימוש רב בתת שאילתה מקוננת במקום בג'וין (ב SQL SERVER הביצועים נהדרים! ב mysql ובאורקל זה בבחינת "אל תנסו את זה בבית") אתן לכם דוגמא, ותחליטו איזה קוד קריא יותר.
קוד SQL "לפי הספר":
SELECT a.Title ,c.FullName AS ContactFullName ,c2.FullName AS AssignedToFullName FROM Activities.Activities a JOIN Contacts.Contacts c ON a.ContactID=c.ID JOIN Contacts.Contacts c2 ON a.AssignedToID=c2.IDקוד SQL בסגנון אחר:
SELECT a.Title ,(select top 1 FullName from Contacts.Contacts where ID=ContactID) AS ContactFullName ,(select top 1 FullName from Contacts.Contacts where ID=AssignedToID) AS AssignedToFullName FROM Activities.Activities aשימו לב שבדוגמא השניה הסיפור קולח, כשמגיעים לעמודה של ContactFullName יש לנו את כל השאילתה מול העיניים, ולא צריך לרדת לjoin למטה כדי להבין על מה מדובר.
בדיוק היום יצא לי לראות דטה בייס של ארגון חשוב ומכובד וידוע מאוד בארץ, יש שם שאילתה עם (תחזיקו חזק!!!) מעל עשרים ג'וינים. ג'וין מלשון גהינם.
פורסם במקור בפורום CODE613 ב28/07/2017 02:13 (+03:00)
-
הנה PR לקרנל לינוקס.
https://github.com/torvalds/linux/pull/437אחד שחשב שהקוד שלו יותר מהיר.
משעשע.פורסם במקור בפורום CODE613 ב28/07/2017 14:57 (+03:00)
