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

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

software-design-shutterstock1

ביצוע תכנון (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: “נדל”ן יכול רק לעלות”

cost1

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

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

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

מקור: Martinfowler.com

מקור: Martinfowler.com

כמה הבחנות חשובות שנוספו הן:

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

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

שנות העשרה: “פיזור תיק ההשקעות”

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

מקור: Martinfowler.com

מקור: Martinfowler.com

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

תובנות חדשות שנוספו הן:

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

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

סיכום

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

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

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

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

קרדיט תמונה בראש הפוסט: Shutterstock

הפוסט פורסם במקור בבלוג Software Archiblog.

Avatar

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

4 תגובות על "האם אנו זקוקים ל-Software Design?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
איתי
Guest

מעולה. נהניתי לקרוא. תודה

גלעד - מפתח -
Guest

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

קוקו
Guest
מסכים ולא מסכים – הגרף של ה NO DESIGHN בהקשר לסיכונים לא נכון – אם כבר לעשות רדוקציה לתחום של כלכלה,אז בגרף חסר מצב של קריסה כללית,או מה שניקרא “ברבור שחור”. בעולם התוכנה זה מקביל לקטסטרופה ב PRODUCTION,משהו כמו הקריסה של הרשת של פלאפון לפני כמה חודשים בגלל באג בתוכנה,או באג בתכנון של תוכנה לבנק שתעשה חישוב מוטעה במיליונים. אומנן טעויות כאלו לא קורות בדר”כ בגלל DESIGHN לא נכון,זה בדר”כ באגים במקרי קצה,ששום תכנון לא היה עולה עליהם,אבל יש מערכות שהעלות של באג היא כל כך גדולה,שפשוט אי אפשר בלי DESIGHN. נכון,באפליקציה להזמנת פיצה אולי הייתי קצת מוותר,אבל יש מיקרים… Read more »
יוסי
Guest

כל מילה בסלע!

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

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

wpDiscuz

תגיות לכתבה: