כיצד מגדירים ארכיטקטורה? צעד אחר צעד

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

תהליך ה\”ארכיטקטורה\” נראה לפעמים כמעט כמיסטיקה – ואני מקווה שפוסט זה יתיר חלק מהערפל (ואולי גם מההילה).

לצורך התרגיל בחרתי בבעיה קלאסית במדעי המחשב (שאני פחות או יותר פותר בעצמי כרגע כחלק מלמידת שפת רובי): \”בעיית שבע המלכות והפרש\”. כיצד ניתן להציב על לוח שחמט 7 מלכות [א] ופרש מבלי שיאיימו זה-על-זה.

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

בואו נצא לדרך.

כיצד מתחילים להגדיר ארכיטקטורה?

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

כאשר יש כיוון – הקוד רץ מעצמו, \”7 המלכות והפרש\” זה לא באמת \”אתגר\” תכנותי עבורנו. הקושי לרוב יהיה לבחור כיוון ראשוני לארכיטקטורה.

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

שיטה קטנה אחרת היא כלל שמגיע מתכנון-מונחה עצמים, ו DDD: \”המלים בהן אנו משתמשים לתאר את הבעיה \’חייבות\’ לקבל ייצוג מתאים (מחלקות) במערכת\”.

אז הנה, קיצרנו לעצמנו מעט – ויש לנו נקודת התחלה כלשהי.
מהם המלים שחוזרות על עצמן בתיאור הבעיה? \”מלכה\” ו\”לוח\” (לפחות אצלי):

להבהיר: במיוחד במערכת כ\”כ קטנה, במיוחד כשכותב אותה אדם בודד, ובמיוחד בעולם האג\’ייל – אין הגיון לייצר תרשימי UML! יצרתי את התרשים רק עבורכם – קוראי הבלוג.

האופן הטבעי לעשות זאת הוא לכתוב קוד מסגרת ראשוני (כלומר: skeleton):

לגבי שפת רובי (הנה פוסט \”נחיתה\” – למי שלא מכיר), attr_accessor היא דרך מהירה לייצר getter/setters לרשימת ה symbols שהוצמדה לפונקציה. למשל, במקרה של המחלקה Board ייווצר משתנה בשם queens@ שערכו nil, מתודה בשם queens שמחזירה את ערך המשתנה, ומתודה בשם =queens שמאפשרת לבצע השמה לערך בעזרת סימן \”=\” (להלן הסבר יותר מפורט)

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

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

אלו החלטות כבר \”לקחתי\”?

• אופציה א\’: לוח כמטריצה 8×8 של מערך המחזיק אובייקטים.
• יתרונות: מודל פשוט וקל להבנה
• אופציה ב\’: ניהול רשימות של הכלים השונים – כאשר כל כלי מחזיק את המיקום שלו על הלוח.
• יתרון: יותר יעיל (טיול על x כלים – שזה מספר קטן מ 64 תאים – בכדי למצוא כלי) – לא משמעותי כאן.
• יתרון: מישהו יצטרך לחשב \”איום\” של כלי על כלי אחר. זה גורר דילמה אחרת (מייד) – שאת התוצאה שלה, אופציה זו \”תקבל\” בצורה טבעית יותר.

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

• אופציה א\’: הלוח הוא זה שמחשב איומים בין הכלים
• יתרונות: אני מעריך שאופציה זו תדרוש פחות שורות קוד.
• אופציה ב\’: כל כלי הוא זה שמחשב את האיומים שלו
• יתרונות: יותר OO, משום ש\”הצלחנו למצוא\” מומחיות למחלקות. מלכה מומחית בלהכיר את האיומים שהיא מפיקה, ופרש מומחה בלהכיר את האיומים שהוא מפיק.

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

אם היינו מתמודדים עם בעיה דמיונות בשם \”8 המלכות\” [ב] בה יש רק מלכות – אולי היה היתרון של אופציה ב\’ היה פחות ברור. אני חושב שאני אישית עדיין הייתי מעדיף לבחור באופציה ב\’ – כי אני לא מרגיש עקרונית נוח עם \”לוח יודע כל\”.

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

הנה עדכנתי את התוכנית בהשלכות של הבחירה באופציה ב\’:

למי שלא מכיר UML – חץ משמעו קשר, שמתבטא בפועל ב member של המחלקה. כלומר: חץ דו-כיווני אומר שבמחלקה Queen יש member בשם board@, ובמחלקה Board יש מערך של members בשם queens@.

יש לנו כאן קשר דו-כיווני, מה שאמור להדליק לנו נורה אדומה. ככל האפשר (עקרונות ה OO) – מומלץ להפחית קשרים דו-כיווניים (וקשרים בכלל) מהמערכת.

בואו נזכר מדוע אנו רוצים את הקשרים האלו:

• מלכה מכירה את הלוח – כי היא צריכה לבדוק מה יש בתאים מסביבה – (\”()board.content_at\”).
• לוח מכיר את המלכות – כי הוא מציב את המלכות.

בואו נכסה עוד יכולת נדרשת לתכנון: היכולת להדפיס את הפתרון (כלומר: מצב הלוח בו 7 מלכות ופרש לא מאיימים זה על זה) על המסך. לצורך המערכת הזו – מדובר בהדפסת ASCII ב console.

דילמה: כיצד לבצע את ההדפסה:

• אופציה א\’: ה Board אחראי להדפסה
• ייתרון: יש למחלקה את כל המידע הדרוש להדפסה
• חיסרון: עכשיו יהיו למחלקה 2 אחריויות: א. לנהל את ה state של פתרון, ב. לנהל את ההדפסה של ה state הזה. 2 אחריויות היא חריגה מה SRP (קיצור של: Single Responsibility Principle).
• אופציה ב\’: ה Board מדפיס את הלוח, ועושה to_s (כלומר: toString ברובי) למלכה – כדי לתת לה את האחריות כיצד להציג את עצמה (למשל: האות \”Q\” או סמיילי)
• ייתרון: פיזור אחריות בין אובייקטים שאחראים למשימה (scalability פיתוחי)
• חיסרון: פיזור אחריויות – אין SRP
• אופציה ג\’: ליצור מחלקה נוספת שאחראית על ההדפסה
• ייתרון: הפרדת אחריויות ברורה בקוד
• חיסרון: מה השתגענו – עוד מחלקה? כלומר: יותר קוד לכתוב

בואו נבנה מבנה הגיוני אחר (או שניים) – ונבחן אותם. נראה אם אנו יכולים להגיע לפתרון שהוא סה\”כ טוב יותר.
הנה אלטרנטיבה אחרת (להלן ארכיטקטורה ב\’):

ארכיטקטורה ב\’

היתרונות של ארכיטקטורה א\’ הם:

• הפרדת אחריויות מקיפה (כל מחלקה אחראית על משהו אחד)
• מוכנות לגדילה* (development scalability). 

סיכום התהליך

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

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

1. הידע על הארכיטקטורה איננו קיים – הוא מתגלה. אנו מגלים תוך כדי תכנון ומעט קידוד (\”spike solutions\” ו/או POCs) תובנות חדשות, ומשלבים אותן בארכיטקטורה.
   נכון, שאם בנינו מערכות דומות בעבר – אנו יכולים להשתמש בידע שנצבר שם בכדי לקצר תהליכים.
2. אפשרויות בחירה הן קריטיות לתכנון איכותי. ההרגל נוטה למשוך אותנו ל\”פתרון הראשון שיכול לעבוד\” ולהישאר שם, אבל חשוב לעצור לרגע וליצור עוד אלטרנטיבות ישימות – ואז לבחור מביניהן את הטובה יותר.

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

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

   למשל: בארכיטקטורה א\’ הצבנו את כל אחריות ההדפסה על הלוח. בגלל ריבוי הכלים (מלכה, פרש) הוא יאלץ לבצע if (או case) ולהגדיר התנהגויות לכל כלי (המקביל לקריאה ל ()to_s בארכיטקטורה ב\’). מצב כזה נחשב כ bad smell בו מומלץ לעשות refactoring לכיוון State Pattern. מצד שני – המצב שייווצר יפגע ב SRP. פה יש עניין של הבחנה עיקר וטפל – שמבוסס במידה רבה על ניסיון מכיוון שאין דרך מתמטית \”להוכיח\” איזה מצב הוא עדיף. ניסיון הוא בסהכ ה\”מושכל\” ב\”הימור מושכל\”, כמובן.

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

—-

[א] מלכה ברבים, מלכות, יש לקרוא כמְלָכוֹת (כ\’ רפה) – כמו \”MELAHOT\”

[ב] \”8 המלכות\” זו כמובן הבעיה המקרית. אני רציתי לגוון ולנסות משהו טיפה אחר.