יום שבת, 27 ביולי 2013

האם אנו זקוקים ל Software Design?

ביצוע תכנון (Software Design) מתחבר לאנשים רבים ל"עשיית הדבר הנכון".
אם את/אתה אחד מאותם אנשים, עצרו לרגע והסבירו: מדוע זה הדבר הנכון? מה יקרה אם לא נעשה Design?

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

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





מעט ספקות

אנחנו לא באמת יודעים מה היה קורה "אילו היינו עושים..." - אנחנו יכולים רק לדמיין: "אם היינו משקיעים במניית אפל בתחילת 2007 ומוכרים אותה ברבעון הראשון של 2012 היינו עושים 600% רווח!". במקבילה שלנו בעולם התכונה: "אם היינו שומרים את כל ה properties על אובייקט ה xyz זה היה פתרון אחד לשלושת הלקוחות ולא היינו מסתבכים ככה!".

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

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

כל זה השתנה לא מעט בעשור האחרון בעזרת תנועת האג'ייל שעזרה לחדד 2 נקודות:
  • לא כל השקעה ב Design מחזירה את עצמה. המלצה: השקיעו בזהירות רבה יותר (על זה בהמשך).
  • אנו יכולים להפחית את עלות השינויים במערכת production (ע"י אוטומציה, למשל) ולכן שווה אולי לדחות רבות מהחלטות ה Design לשלב מאוחר יותר - שלב בו הידע שלנו לגבי צרכי המערכת יהיה טוב יותר. 


עברו 30-40 שנה. מה השתנה?

מאז שהחלו להתעסק בצורה מקיפה ברעיונות של Software Design עברו קצת מים בנהר, ונוספו כמה כלים חדשים ומשמעותיים המקלים על פיתוח תוכנה גדולה ומורכבת:
  • Unit Tests & Automation
  • Agile (ספרינטים קצרים, MVCs)
  • Static Analysis Tools, Modern IDEs
  • מערכת ניהול קוד מבוזרת, כלי build מתקדמים (כמו Gradle [א]) ו Continuous Integration
  • ווב, מחשוב ענן, Continuous Delivery or Deployment 

האם כלים אלו:
  1. מעלים את רף מורכבות התוכנה בה תכנון (Design) הוא משתלם?
  2. מייתרים את הצורך ב Design?
  3. הופכים את ה Design למשהו אחר לגמרי?
  4. או בכלל לא משנים?

מה דעתכם?



הכלכלה של ה Design


את הטיעון "הכלכלי" המצדיק השקעה ב Software Design היה מקובל להציג לאורך השנים בדרכים שונות:

שנות ה 60 עד שנות ה 90: "נדל''ן יכול רק לעלות"



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


שנות ה 2000: "הבורסה היא השקעה בטוחה לאורך זמן, עם תשואה צפויה של 6% בשנה"

עם הזמן הוכרה ההבנה שלעתים אי-ביצוע Design אינו מתכון בטוח לכישלון. המודל ה"כלכלי" התאים את עצמו והתמקד בתובנה ש Design משתלם - בטווח הארוך:

מקור: הבלוג של מרטין פאולר

כמה הבחנות חשובות שנוספו הן:
  • הטענה שהשקעה ב Design משתלמת היא תחושה (של רבים ומקצועיים) - אך לא עובדה מוכחת.
  • יש אי-הסכמה בקרב המקצוענים מתי Design משתלם: אחרי שבועות של פיתוח או חודשים רבים.
  • יש אבחנה ברורה בין "good design" ל "mediocre design" - פעולת ה Design לא מבטיחה תוצאות, התוצאות תלויות מאוד באיכות העבודה.

לינק רלוונטי: Design Stamina Hypothesis 



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


גם אם Design נעשה בצורה טובה (קרי: מימוש נכון של העקרונות החשובים), עדיין כדאי למצוא את התמהיל הנכון של כמה חוקים לאכוף, והיכן "לשחרר".

תובנות חדשות שנוספו הן:
  • Design כולל סדרה של החלטות שניתן לבחור ליישם רק חלק מהן. נכון, יש קשר ותלות בין ההחלטות - אך תלות זו עדיין מותירה החלטות שניתן לוותר עליהן באופן בלתי-תלוי.
  • Design הוא תהליך מתמשך. המתכנת מבצע Design (בקטנה) תוך כדי שהוא כותב קוד, וכדאי פעם בכמה זמן (חודש-חודשיים?) לבצע עצירה מתודית ולבדוק את ה Design וכיצד הוא מתפתח בצורה יותר שיטתית.
  • חשוב לבחון כל החלטה של Design כהשקעה עם סיכון: "בניית שכבת ההפשטה תדרוש עוד x התעסקות, אבל תקל מאוד במידה ובעתיד יוסיפו אלמנט חדש". מה הסבירות שיוסיפו אלמנט חדש בעתיד? עד כמה יותר יקר יהיה לבצע את השינוי בעתיד? אולי סבירות נמוכה שהאירוע יתרחש מצדיקה תשלום כפול בעתיד על אותו האלמנט.

לינק רלוונטי: ?Is Design Dead



סיכום

שלא תבינו אותי לא נכון: אני מאוד בעד Design, אולם במשך השנים אני נוטה לעשות פחות ממנו ובמנות קטנות יותר - ואני מרגיש שאני משתפר.

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

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

כדי שנוכל להחליט טוב יותר כמה מה Design ליישם ומתי, שווה לבחון בצורה יסודית את השאלות "מה בעצם Design פותר - בפועל?" ו "מה הן בעצם המשמעויות של החלטות ה Design שאנו עושים?" - שאלות לא פשוטות.

קוראים קבועים ישימו לב שאני תוקף לאחרונה את כל הנושא, אולם לאט ובזהירות. היעד הבא הוא להתמודד עם 2 השאלות הנ"ל.

שיהיה לנו בהצלחה!

שאלות, תגובות, מחשבות וכו' - יתקבלו בשמחה!



----

[א] ב Technology Radar האחרון (מאי 2013) סימנו את Mavan ב "Hold" (תרגם לעברית: "צמצמו השקעות קיימות והימנעו משימוש בו בעתיד"), בעוד Gradle זכה ב "Adopt".



12 תגובות:

  1. מאוד מעניין. תודה רבה!

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

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

    אסיים במשפט ששמעתי מ Juval Lowy . לארכיטקט צעיר יש הרבה אפשרויות לארכיטקט מנוסה יש מעט.

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

    נשתמע,
    ליאור

    השבמחק
    תשובות
    1. היי ליאור,

      תודה על התגובה!

      ובכן... אני באמת מתכוון למה שאמרתי: אני עושה פחות Design.

      להבהיר: לפני כל feature או פרוייקט אני יושב ומתכנן.
      אבל על פרוייקט חדש, אם פעם ישבתי שבוע-שבוע וחצי, היום אני יושב יומיים-שלושה. אני משאיר הרבה יותר פרטים פתוחים להחלטה בהמשך ואני באופן אקטיבי מנסה לצמצם את מס' "הכללים" שייצאו מה Design.

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

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

      גם את ה Design של המתכנתים - אני מנסה לצמצם: במקום מסמך בן 10-15 עמודים עברנו לפורמט של מצגות בנות 3-6 שקפים. המפתחים מתכננים הרבה פחות אבל מתמקדים בנקודות המשמעותיות - ומשיגים יותר.

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

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

      מצד שני: כש Design הוא דבר קצר - אנחנו עושים אותו בתחיפות רבה יותר.

      סה"כ זו מבחינתי שיטה "הנדסית" מבוססת - לא תהליך אקראי חסר שליטה.

      ליאור

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

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

      ניתן לראות הרבה דוגמאות לכיצד מבינים את unclebob בצורה לא נכונה!!!

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

      מאוד מקווה שהבנתי אותך נכון.

      מחק
    3. היי ליאור,

      נראה לי שאנו דיי מסכימים - אבל זה עניין של ניסוחים.

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

      אז כן, Design הוא טוב ואנו עושים אותו במנות קטנות יותר - אבל בצורה יותר תכופה.

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

      ליאור

      מחק
  3. מסכים התגובה מעליי, בידיוק מה שרציתי להגיד,
    unclebob אמר שארכיטקטורה טובה זה בעצם לדחות כמה שיותר החלטות כמה שיותר רחוק (אפילו באיזה db להשתמש)

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

    השבמחק
    תשובות
    1. היי רומן,

      הייתי שמח אם היית יכול לבחון האם ה "design הגרוע" היה כזה מלכתחילה או הוא נראה כך רק בדיעבד?
      אולי עשו design סביר+, אבל אם השנים נוספו והשתנו דרישות שגרמו לקוד במערכת "להרקב"?

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

      לגבי unclebob: אני מסכים. הוא בהחלט האנשים שהניעו את שינויי התפיסה לגבי Design וארכיטקטורה.

      ליאור

      מחק
  4. שלום ליאור.

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

    איילת.

    השבמחק
    תשובות
    1. היי איילת,

      תודה על התגובה.

      שאיפה מרכזית ב Design היא לדחות כמה שיותר החלטות לעתיד, לא ע"י התעלמות אלא ע"י השארת "כל האופציות פתוחות".

      פעמים רבות ניגשים ל Design כמשימת הכנת רשימת ה"יסודות" של המערכת: באלו טכנולוגיות, ספריות להשתמש או תבניות עיצוב להשתמש.

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

      ואז:
      א. לייצר לכל החלטה 2-3 אופציות ריאליות, להשוות - ולבחור את הטובה ביותר.
      ב. לנסות לדחות את ההחלטה, אם אפשר, ע"י הצבת פיתרון פשוט וקל שיהיה קל להחליף בעתיד (אם קיים כזה). לא פיתרון "עקום", אלא פיתרון פשוט וטוב שסביר שיספיק לזמן מסויים.

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

      מקווה שעניתי,
      ליאור

      מחק
  5. תגובה זו הוסרה על ידי המחבר.

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

    הרבה מהדברים שאתה אומר כאן מתיישרים אם מה שאומר Juval Lowy שהוזכר בחטף ע"י המגיב ליאור.
    Juval הוא אבי שיטה ארכיטקטונית ששמה The Method אשר מדברת בדיוק על הדברים האלה. קצרה היריעה מלתאר אותה אבל אחד מעמודי התווך שלה הוא עקרון ש- design הוא תהליך לצריך להיות *מאוד קצר*. זה מבטיח התמקדות בדברים העיקריים (core uses cases), מונע gold plating ב design, ירידה לפרטים שהם לא חלק מה design ו- analysis paralysis.

    לינק מאוד ממולץ להרצאה שלו בטקאד: https://www.youtube.com/watch?v=Jxm2rgeuC6s.
    עברו כבר שנים מספר מאז אבל הרלוונטיות של התוכן רק גדלה.

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

    השבמחק
    תשובות
    1. תודה רבה!

      לא הכרתי את The Method - ובהחלט ארשום לי להתעמק בה.

      מחק