סיבוכיות בפיתוח תוכנה: מקבלים את זה בחינם

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

מקור: flickr, cc-by gigile

בפוסט הבא נדבר על פשטות של ארכיטקטורה ומוצר. בעוד שאין ספק שקל לדבר על פשטות ולזרוק משפטי מפתח כגון “בואו נעשה את זה פשוט”, “Keep It Simple Stupid”, “Less is More”, צריך לחשוב ברצינות, מה היא פשטות ואיך בדיוק משיגים אותה?

מה שמעון פרס היה אומר?

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

כפי שבוודאי יצא לכם להבין, לכל נהג מונית יש בערך 4 דרכים להשיג שלום עולמי “תיק-תק” – אבל הבודדים שכן מנסים להשיג שלום עולמי, מגלים שאין תורה ברורה איך עושים את זה.

ג’ונגל הסיבוכיות

למי שכתב אפליקציית “Hello World” בחייו ברור שזו אפליקציה פשוטה. מוסיפים לה עוד פונקציה, ועוד פונקציה – והיא עדיין פשוטה. לאחר שאנו יודעים שיש לנו בסיס פשוט, ורצון כן ואמיתי לפשטות (אולי אפילו יש איזה שלט ענק במסדרון שאומר “!Simplicity” – לוודא שלא נאבד את הדרך) – אנו מתקדמים בקצב. פעם הבאה שנרים את הראש, נשים לב שאנחנו בתוך ג’ונגל סבוך – ג’ונגל הסיבוכיות.

עיקרון #1: התבונה היא לא בייצור פשטות, התבונה היא ביציאה מסיבוכיות ברגע שהגענו אליה.

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

פה יש נקודה שקצת קשה למפתחים, אך יותר קלה למי שנמצא בדרגות גבוהות יותר: הדבר שאתם רוצים לשנות יכול להיות דרישות, עיצוב גרפי, צורת התקנה וכו’. אל תגבילו את הבדיקה רק לקוד שלכם ומה שאתם יכולים לעשות מבלי לערב אף-אחד מחוץ לפיתוח.

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

יצא לי באופן אישי להיות מעורב במחיקה של סט יכולות שלם מ-Component Model באחת המערכות, לאחר שנוצרה קואליציה דיי גדולה של מפתחים, מתעדים טכניים ואנשי UX שהיא סיבכה להם את החיים. יצא לנו גם להעביר שירות (service) מרכזי ועתיק יומין משרת אחד לשרת אחר – ולצמצם הרבה תקשורת וסנכרון מיותרים. הדברים הללו פישטו את המערכת והסירו נתח משמעותי מהסיבוך [א].

עיקרון #2: החכמה היא להאריך את הדרך אל הג’ונגל, עד כדי כך שאולי אפילו לא להגיע אליו…

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

“אנחנו מקבלים את זה בחינם”, או חוסר ההבחנה בין ממשק public ל-published.

מקור: flickr, cc-by Accretion Disc

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

אפילו יותר גרוע: תחשפו UI, WebService או Public API שלקוחות יוכלו להשתמש בו: הרי הקוד שם – וכך אתם יכולים בעלות נמוכה להשיג תועלת גבוהה – כלכלה פשוטה, “מקבלים את זה בחינם”.

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

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

אם אתם רוצים לצבור נקודות או שקשה לכם להתאפק – עדיף אולי לחשוף את החיפוש לכל עבר. אם אתם רוצים מערכת פשוטה שיהיה קל לתחזק לאורך שנים – נסו לצמצם את השימוש בתכונה החדשה למינימום ההכרחי. תמיד תוכלו להרחיב אותה, אך ההיפך הוא קשה יותר: Public APIs, ממש כמו יהלומים – הם Forever.

“ריבית דריבית”

אם תכפילו 1.2 חמש פעמים תקבלו יותר מ-2. משהו כמו 2 וחצי. החצי הוא ה”ריבית דריבית”. אם תוסיפו פיצ’ר של חיפוש, ועליו יכולת Customization ועליה יכולת X ויכולת Y – הפיצ’ר הבא, Z, יהיה יקר יותר מאשר אם הייתם מוותרים על X ו-Y. לעיתים – משמעותית יקר ומורכב יותר.

זכרו את הכלל הבא: העלות של יכולת חדשה n, היא זמן הפיתוח של n + זמן התחזוקה של n + זמן גבוה יותר לפיתוח יכולת n+1 וזמן תחזוקה גבוה יותר ליכולת n+1. רקורסיבית (lim: n–>m).

עקרון שהתייחסתי אליו גם בפוסט על היעילות האמיתית שב SCRUM: הדרך הטובה ביותר לפריון גבוה יותר בפיתוח הוא לייצר פחות פ’יצרים – וכמעט תמיד יש מה להוריד. YFAGNI[א]!

לכו על זה!

—–

[א] הערה טכנית: כמובן ש Unit Tests ואוטומציית רגרסיה היא גיבוי רב-עצמה לביצוע שינויים כאלו בפועל.

[ב] ! You Ain’t Gonna Need It

הפוסט פורסם לראשונה בבלוג ארכיטקטורת תוכנה.

ליאור בר-און

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

הגב

5 תגובות על "סיבוכיות בפיתוח תוכנה: מקבלים את זה בחינם"

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

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

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

YAGNI אני מכיר.
מה זה YFAGNI??

Adi Hadas
Guest

"יחידות איש-שנה"? כנראה גוגל טרנסלייט לא מכיר את המונח שנות אדם בפיתוח תוכנה.

Lior Bar-On
Guest

הטעות במקור

פבל
Guest

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

ליאור בר-און
Guest

היי פבל,

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

ליאור

wpDiscuz

תגיות לכתבה:

נותרו עוד
00
ימים
:
00
שעות
:
00
דקות
:
00
שניות
לכנס המפתחים הגדול בישראל