בראיון עבודה אחד, שערך לי מנהל בכיר בחברה המייצגת בישראל מוצר ERP מוביל בשוק, שאלתי אותו: "את הרכיבים שאתם מפתחים כאן, אתם דואגים לפתח בשכבות?" התגובה שלו היתה מדהימה: "שכבות מבחינתי יש רק בעוגת קרם…"
מפגישות שערכתי עם מפתחים אצל ספקים רבים של תוכנות שונות מתברר כי בתי תוכנה רבים לא רואים את הפיתוח בשכבות כדרישה מנדטורית בסיסית שיש לבצעה בעת כתיבת הקוד לכן, ראיתי לנכון להסביר את החשיבות העסקית ואת היתרונות הכלכליים שיהיו לבית תוכנה שיחליט לפתח את הרכיב שלו בשכבות.
אנשי מקצוע רבים מציגים בפני היגיון כזה:
1. אם מוצר מסויים מפותח כמקשה אחת ולא כשכבות בודדות כל שדרוג שלו יימשך יותר זמן.
2. הלקוח משלם עבור הזמן הזה.
ולכן:
3. לבית התוכנה כדאי שלא לפתח את המוצר באופן מרובה שכבות על מנת לקבל את התשלום עבור העדכונים.
לדעתי, "היגיון" זה הוא שגוי ומוטעה ובמאמר זה אני אנסה להדגים את היתרונות והחסרונות שיש לפיתוח שכבתי עבור בית התוכנה.
אז מה זה בדיוק פיתוח רב שכבתי (Multi-tier)? אולי יהיה קל יותר לענות על זה על דרך השלילה, בפיתוח מונוליתי (ההיפך הגמור מפיתוח שכבתי) המודול התוכנתי (יכול להיות DLL, EXE וכו') אשר בו מבוצע ממשק המשתמש מבצע ישירות את הפניות למאגרי הנתונים, מכיל פניות (במידת הצורך) לרכיבי חומרה שונים (למשל סורקים, מדפסות וכו'), כמו כן, אותו מודול מטפל גם בנושאי האותנטיקציה אותוריזציה ורישום פעולות המשתמש (במידה ואילו נדרשים), אותו מודול מטפל גם בהצפנות ופענוח (במדת הצורך). לעומת זאת, בפיתוח שכבתי נשמרים העקרונות הבאים:
1. כל שכבה נפרדת מחברתה (לעיתים באופן פיזי, כ-DLL, EXE ולפעמים רק באופן לוגי ע"י הגדרתה כמחלקה – Class אחרת)
2. כל שכבה תלויה בפלטים של השכבה שמתחתיה אבל לעולם לא בפלטים של שכבות אחרות.
3. כל שכבה מבצעת סוג משימות מוגדר. למשל: קישור למאגרי הנתונים (DAL), טיפול בממשק המשתמש (GUI), ניהול הצפנה וכו'.
היתרונות:
1. תכנון נכון של שכבות המוצר, ואני לא מתכוון לשכבות הבסיסיות הטריויאליות כגון DAL, GUI וכו' אלא חלוקה לשכבות נוספות עבור הצפנה, גישה לרכיבי חומרה, ניהול משתמשים וכו' מאפשר למוצר הסופי להיות גמיש יותר בכך שניתן להתאימו בנקל למערכות וסביבות שונות מאילו שיועדו לו במקור. חשוב להבין שאפילו תוכניות שירות קטנות בד"כ מורכבות (בשפות מסויימות) ממאות אלפי שורות קוד ולפעמים אף יותר, כך ששינוי "פעוט" כמו החלפה של שרת מסד נתונים מטכנולוגיה אחת (למשל MS-SQL) לאחרת (למשל Oracle) עשויה לחייב שינוי נרחב מאד במבנה המערכת במדה והיא נבנתה כמונולית.
2. במדה והשכבות השונות נפרדות זו מזו באופן קיצוני עוד יותר – למשל על ידי רשת התקשורת, כלומר מתקשרות ביניהן ע"י רשת התקשורת (כמובן באופן סטנדרטי ומקובל), במקרה כזה כבר למעשה מושגת גמישות רבה בהרבה – באופן כזה ניתן לפצל את המערכת (אם כי לא חייבים לעשות זאת) למספר שרתים ובכך לשפר (במדה והחלוקה לשכבות בוצעה באופן המבזר עומסים בין השכבות השונות) לעיתים במידה רבה את ביצועי המערכת. לפעמים (תלוי במבנה המדוייק של המערכת ובפרטים אחרים) ניתן לשפר באופן זה גם את שרידות המערכת תוך שימוש באמצעים תשתיתיים דוגמת Microsoft Network Load Balancer וכו'.
3. תכנון נכון של שכבות המוצר תוך שמירה על העקרונות שהוצגו לעיל מאפשר גם לפתח את כל השכבות במקביל ע"י צוותי פיתוח שונים ולבצע בדיקות QA לכל רכיב בנפרד וכך לקצר את משך הפיתוח והבדיקות של המוצר.
4. מוצר שנבנה בשכבות (ובמיוחד מוצר שנבנה בשכבות המופרדות ע"י תשתית הרשת) מאפשרים במקרה של תקלות לאתר בקלות רבה מאד (בד"כ) את השכבה בה קיימת הבעיה ע"י צעדי Troubleshooting בסיסיים ובכך לקצר את משך הזמן שדרוש לפתרון בעיות רבות שעלולות להתעורר במוצר.
החסרונות:
ברור שגם לשיטה כזו קיימים גם חסרונות:
1. משך זמן פיתוח כולל ארוך יחסית – כן, אני יודע שבסעיף 3 טענתי שאחד הייתרונות הוא משך זמן הפיתוח המתקצר אבל… במערכות מונוליתיות, במדה והתוכניתן עדיין זוכר מה צריך לכתוב ואיפה על מנת לעדכן את המוצר לדרישות האיפיון המעודכן העדכון יהיה מהיר יותר שכן אין צורך לקשר בין השכבות. כמובן שבמקרה (השכיח הרבה יותר) התוכניתן לא ימצא את המקום שעליו לעדכן ואת הקוד המדוייק שעליו לעדכן, זאת משום שבקוד מונוליתי הקוד הרלוונטי לבעיה שנמצאה עשוי להופיע במקומות שונים באותו קובץ ואפילו בקבצים אחרים. כמובן שחשוב לשים לב שלמעשה ככל שהעדכון גדול ונרחב יותר משך הזמן שיידרש לביצועו במערכות מונוליתיות יגדל במהירות בעוד שבמערכות שנבנו באופן שכבתי משך הזמן לביצוע התיקון יילך ויקטן שכן במדה והתיקון מחייב שינויים במספר שכבות יהיה אפשרי בקלות לחלק את מטלות הפיתוח למספר תוכניתנים ו
בכך לקצר את משך הזמן הדרוש לתיקון.
2. מחייב ניתוח מעמיק של המערכת טרם פיתוחה – טוב, לגבי זה לא הצלחתי להחליט אם מדובר ביתרון או חיסרון… מצד אחד זה יתרון גדול משום שזה מחייב הבנה מעמיקה של המערכת וגורם לפיתוח שלך להיות הרבה יותר מתאים לצרכי המשתמש, מצד שני זה חיסרון שכן ניתוח מעמיק שכזה לוקח זמן, מצד שלישי… אם לא תנתח באופן מעמיק את הצרכים של המשתמש אז מה בדיוק אתה מפתח?
3. זמן תגובה ארוך יותר – במערכות שבהן נושא הזמן הוא קריטי(Real Time), אבל אני מתכוון ממש ממש ממש קריטי, במערכות אלו כל אלפית שניה מיותרת עשויה לגרום לאסון (חישבו לרגע על מערכת לשיגור טילי חץ, זו צריכה לעקוב בכל אלפית שנייה ולפעמים בדיוק גבוה יותר אחר מיקום הטיל של האוייב על מנת להשיג סיכוי ממשי לפגוע בו). במערכות אלו התקשורת בין השכבות עצמה עשויה להיות לרועץ, במקרים קיצוניים כאלו אני ממליץ לשמור על הפרדה ככל שניתן – עד כמה שניתן, אם כי כמובן שהפרדה ממש מלאה קרוב לוודאי שלא ניתן יהיה ליישם.
מסקנות:
ככלל, על מנת להשיג גמישות מירבית, אפשרויות Troubleshooting הטובות ביותר ויתרונות נוספים כדאי (למרות עלויות נוספות שעלולות להיווצר) לפתח כל מערכת בגישה שכבתית כאשר ככל שניתן יש ליצור הפרדה מקסימלית וסטנדרטית בין השכבות השונות.