חוקים לדיזיין פשוט

בסוף שנות התשעים הגיחו לעולם מתודלוגיית הפיתוח והספר Extreme Programming שנוצרו (ברובם) על ידי Kent Beck (האיש המגניב בתמונה למעלה). 

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

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

למה דיזיין פשוט?

מפתח בשם Gergely Orosz שאני מאוד אוהב לקרוא תכנים שלו, כתב בבלוג משפט שמאוד התחברתי אליו - ״Software Architecture is Overrated, Clear and Simple Design is Underrated״.

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

הטענה כאן היא שלרוב, אם נדבוק בעקרונות הדיזיין הפשוטים שלנו נשים לב בדיעבד שמימשנו patterns מבלי שידענו. ובסוף צריך לזכור שהמטרה במילים כמו microservices, event-driven design, pub/sub, event-bus, broker pattern ועוד כל מיני buzzwords, היא ליצור שפה משותפת לפתרונות לבעיות נפוצות, כלומר, ישבו מאחורי המילים האלו אנשים שהיתה להם בעיה, הם פתרו אותה תוך שמירה על עקרונות מסויימים, וכדי ליצור שפה משותפת עבור הפתרון שלהם, הם נתנו לו שם.

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

החוקים לדיזיין פשוט

הטסטים תמיד עוברים

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

הכוונה תמיד חשופה

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

ללא שכפול

DRY (don't repeat yourself) ו SPOT (single point of truth) הם העקרונות אולי הכי מדוברים וחשובים ליצירת דיזיין טוב. אין הרבה מה להרחיב על העיקרון אבל הוא פשוט להבנה הרבה יותר משפשוט למימוש והוא אומר - תכתבו כל דבר פעם אחת ורק פעם אחת.

כמה שפחות אלמנטים

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

החוקים נכתוב בסדר העדיפויות הבא:
סדר העדיפויות של Kent Beck


סיכום

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

מטרת הפוסט היא בעיקר קריאה לבדק בית ותזכורת לביצוע first things first ולא לשים את העגלה לפני הסוסים. היכרות עם design ו architecture patterns זה דבר חשוב ושתרם לי לא מעט בהתקדמות שלי כמפתח אבל כשניגשים לכתוב קוד או לעשות דיזיין חשוב להגדיר לנו ולעקוב אחרי עקרונות פשוטים ולהסכים עליהם עם הקולגות שלנו. כשמסתכלים על עקרון פארטו (80-20) שם כנראה יושבים ה20 אחוז שיהיו אחראים על 80 אחוז מהתוצאה.

נתראה בפוסט הבא :)

תגובות

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

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

    השבמחק
    תשובות
    1. ואיפה בעיניך עובר הגבול בין לכתוב את הקוד גנרי ולהלביש אבסטקרציות לבין premature optimization?

      מחק

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

מהם קבצי DLL ואיך להשתמש בהם?

מדריך C# | שימוש ב LINQ

תכנות מונחה עצמים | Dependency Inversion Principle