ארכיטקטורה: מהם מאפייני איכות ולמה צריך אותם?

האם ללא מאפייני איכות המוצר שלנו יהיה שבור ומקולקל? ליאור בר-און מסביר מהם מאפייני איכות של מוצר, למה אנחנו צריכים אותם ומתי משתמשים בהם.

cc-by Juhan Sonin

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

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

“באמת ארכיטקטורה זה כ”כ משעמם?” – היה קול אחד שניקר בראשי. אולי אני לא מבין שום דבר (“you know nothing Jon Snow”) – היה קול ספקני שני.

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

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

אחד הכלים הללו נקרא מאפייני איכות (Quality Attributes) – ועליו נדבר בפוסט זה.

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

מה הם לא מאפייני-איכות?

הנה screenshot ממצגת שראיתי, אשר ניסתה להסביר “מהם מאפייני איכות”:

בית הרוס מול בניין מטה חברת SAP. מקור: יח”צ

המטפורה הזו היא שטותית!

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

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

אז מה הם מאפייני איכות?

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

אנסה להסביר מהם מאפייני איכות בעזרת דוגמה: חי-הסוללה של מחשב נייד (Laptop).

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

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

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

אנו רואים ש”חיי סוללה ארוכים”, עבור מחשב נייד, זו איכות רוחבית של המוצר. “מאפיין איכות” (Quality Attribute), בשפה שלנו.

הנה דוגמה לבחירה בין מאפייני איכות שונים:

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

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

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

מאפייני איכות בעולם התוכנה

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

כמה אחסון נדרש? איזו אמינות? זמינות? ביצועים? אבטחה?

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

“אתה רוצה להשקיע 5 ימי פיתוח בהגנה בפני Directory Traversal (סוג של פגיעות מערכת, בהיבט האבטחה)?” זו כמובן שאלה לא הוגנת – שרוב אנשי המוצר פשוט לא מסוגלים לענות עליה. “כמה יהיה ‘ציון האבטחה’ של המערכת שלנו עם ובלי Directory Traversal?” היא שאלת הנגד המעשית של איש המוצר – שהמפתחים מצידם לא יהיו מסוגלים לספק לה תשובה.

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

כדאי מאוד שמישהו ייקח באופן מודע את ההחלטה לגבי מאפייני האיכות, מישהו:

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

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

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

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

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

כיצד בוחרים מאפייני איכות?

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

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

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

Security (נקרא במקור Integrity) – עד כמה מוגבלת / מאובטחת צריכה להיות הגישה לנתונים / שירותים של המערכת.

Efficiency – עד כמה יעילה המערכת בניצול משאבי החומרה העומדים לרשותה, או בניצול שירותים אחרים (כגון SOA) – והחומרה העומדת לרשותם.

Portability – היכולת של המערכת לרוץ בסביבות ריצה שונות, קרי מערכות הפעלה, סביבות ענן, תצורות רשת וכו’.

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

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

Maintainability – עלות תפעול (Administration / Operations) נמוכה של המערכת. מה שנקרא TCO (Total Cost of Ownership). מאפיין זה יכול להצביע על הוספת “פ’יצרים של ניהול המערכת”. עוד נושא שנכנס לקטגוריה זו היא קלות ההתקנה של המערכת, לעתים מתייחסים אליה כמאפיין איכות עצמאי: Installability. לדוגמה: כלי monitoring שיסייעו לנטר בעיות במערכת. השקעה ב Upgrade קל וכו’.

Developability (נקרא במקור Flexibility) – היכולת לפתח את המערכת בקלות, לבצע בה שינויים או לתקן באגים. מה שנקרא TCD ((Total Cost of Development מאפיין איכות זה עוזר לאפיין את הדילמה שבין איכות שמוסיפה סיבוכיות למערכת (Portability או Efficiency, למשל) למול היכולת לפתח מהר וביתר קלות.

Extensibility – היכולת להרחיב ולהוסיף יכולות חדשות למערכת, בעזרת Plug-in, API וכו’. כמובן שיכולת ההרחבה היא ליכולות / אזורים ספציפיים במערכת.

Supportability – היכולת לתמוך במוצר בקלות, אם מדובר בגוף המייצר את התוכנה או גוף שלישי. כלי Monitoring, לוגים קריאים, יכולת לבצע Dumps של זיכרון או נתונים, דו”ח על תצורת המערכת וכו’.

Scalability – היכולת של המערכת של המערכת לטפל במספר הולך-וגדל של בקשות ו/או היכולת של המערכת לגדול על מנת להמשיך ולהתמודד עם גדילה זו. לרוב עושים הבחנה בין Vertical Scalability – יכולת לצרוך ביעילות חומרה יותר חזקה ו Horizontal Scalability – היכולת של המערכת להתפרס על מספר שרתים פיסיים (cluster).

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

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

Availability – מאפיין זה תקף בעיקר לשרתים (או שירותים) והוא מורכב מזמינות (אחוז הזמן שהשרת / שירות זמין ללקוחותיו) או תדירות הכישלונות (מה שנקרא MTBF). שרת יכול להיות זמין 99% מהזמן אך לכשול לשנייה אחת – כל יום, מה שיגרום לתקלות כואבות. (MTBF (Mean Time Between Failures עוזר להשלים את התמונה שנתון הזמינות לבדו לא מספק היטב.

רשימת “מאפייני איכות” ממקורות שונים. מקור: clarrus.com

כמה הערות על הרשימה:

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

Extensibility, Maintainability ו Supportability הם סוג של “פיצ’רים” שאולי מנהל המוצר לא ייזום ולכן על הארכיטקט להציע ולקדם. לכאורה נראה שהם שונים משאר מאפייני האיכות מכיוון שהם “פיצ’רים נוספים למערכת”. בפועל – השקעה בכל מאפייני איכות (למשל Availability או Safety) דורשת עבודה וההבדל בין שלושת מאפייני איכות אלו לשאר היא קטנה משנדמה במבט ראשון.

בחירת מאפייני איכות

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

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

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

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

דוגמה לבחירה לא מוצלחת של מאפייני איכות

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

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

במשך שנים, נושא חם בשוק ה IT היה בעיית ה Lock-In: בחרת ספק מסוים, לו יש API מסוימים. השתמשת בהם והיית מרוצה, אך ביום בו הספק מעלה מחירים / מחפף בשירות / קמים מתחרים עדיפים – “אין לכם שום דרך לבצע שינוי”.
האמירה של “אין שום דרך” היא אמירה לא מדויקת – אך מכיוון שהסיפור (אלמנטים טרגיים של בגידה?) הוא סיפור מוצלח – הוא הושרש והשאיר חותמו על אנשים רבים.

אחד ה “Best Practices” שנבעו מכך הוא לכתוב קוד “בלתי תלוי בספק (vendor)” בכלל, ו”בלתי תלוי בספק בסיס-הנתונים” בפרט. עבדתם עם מערכת אורקל ומחר אתם רוצים לעבור ל MS-SQL? אין בעיה – מחליפים רק את ה “connection string” – והכל עובד.

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

  • באף אחת מהמערכות הללו לא החליפו בסיס נתונים, עד היום (עד כמה שידוע לי).
  • הצוות הקפיד להשתמש ב ANSI SQL – וכך התעלם מרוב היכולות של בסיס הנתונים. אי-השימוש ביכולות הקשה בצורה משמעותית על הפיתוח ועל שיפורי ביצועים.
  • בכמה פעמים, המוצר נזנח / נכתב מחדש – אך בסיס הנתונים נותר. כלומר: בסיס הנתונים היה חלק יציב יותר מהקוד שהשתמש בו.

בפועל, ההחלטה המעשית הייתה לבחור במאפיין האיכות “no DB vendor lock-in”, על פני “Developability” ועל פני “Scalability”.

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

הבחירה של פלטפורמות ג’אווה וNET. לבצע הפשטה שכזו (בעזרת ODBC ו JDBC) באה לתמוך במי שרוצה להשיג Maintainability. אם כל מה שאני שומר בבסיס הנתונים היא טבלה או 2 של נתונים פשוטים – אין לי רווח רב משימוש בבסיס נתונים ספציפי.

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

כניסה לפרטים

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

דרך מומלצת 

על מנת להשתמש במאפייני איכות בצורה יעילה כדאי לבחור כמה תסריטים עיקריים במוצר ולהדגיש אותם:
“בתחום ה X אנו מעדיפים d על c ומעדיפים b על a”.

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

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

Reusability

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

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

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

לעומת זאת, אם אחת מתמקדת ב customizability והשנייה ב performance/scalability (שליחת אלפי הודעות בדקה) – קרוב לוודאי שטוב תעשו אם תשמרו אותן כ2 ספריות נפרדות. לעתים דיי קרובות, ספריות שאיחודן נראה כ no brainer במבט ראשון, מתגלות במהרה כלא סבירות לאיחוד לאחר שבוחנים את מאפייני האיכות שלהן.

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

מאפייני איכות מסייעים להגדיר ארכיטקטורה עבור “משהו” – ולא ארכיטקטורה “סתם”.

חלק מהספרות הפורמלית בנושא מתאר את “מאפייני האיכות” קצת אחרת – אני התייחסתי אליהן בצורה שהייתה שימושית עבורי והוכיחה את עצמה. חפשו בגוגל “Quality Attributes” ותוכלו למצוא חומר רב.

זכרו שבארכיטקטורה, כמו בארכיטקטורה, “קוד שעובד” היא נקודת האפס. “קוד שעובד יעיל” (Effective, לא efficient) הוא הדבר בעל המשמעות.

 הפוסט פורסם במקור בשני חלקים, בבלוג Software Archiblog

Avatar

ליאור בר-און

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

הגב

3 תגובות על "ארכיטקטורה: מהם מאפייני איכות ולמה צריך אותם?"

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

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

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

אחלה פוסט

Gitay Shafran
Guest

פוסט מומלץ

פבל
Guest

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

wpDiscuz

תגיות לכתבה: