לא טוב היותה לבדה: על אינטגרציה של מערכות (מבוא)

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

זה לא בגלל שבוני המערכת לא יודעים לכתוב כזה פיצ׳ר. הרבה פעמים זה גם לא עניין של מאמץ או זמן פיתוח - אלא עניינים הקשורים למשתמשים או למערכת האחרת:

• זה יכול להיות Waze - שאין סיכוי סביר לרוב החברות להקים מאגר / קהילה מקבילה.
• זה יכול להיות פייסבוק - שרשימת החברים שלי כבר מתוחזקת שם היטב.
• זה יכול להיות גוגל דרייב - שסתם אני רגיל ואוהב להשתמש בו.

אפילו אם תספקו למשתמש אותן סט יכולות באיכות מעולה - זה לא ישתווה לשירות אליו המשתמש רגיל.

נהוג לומר:

!If you can't beat them - join them

ואם אתם לא יכולים להחליף מערכת אחרת - כדאי שתתחברו אליה.

צורות התחברות למערכת אחרת

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


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

רמה 1: הזנקת אפליקציה מרוחקת. למשל: פתיחת אפליקציה של הזמנת כרטיסים (לדף הפתיחה) מתוך האפליקציה שלנו.

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

רמה 2: שליפת נתונים חד פעמית. לדוגמה: קבלת אנשי הקשר מ LinkedIn.

רמה 3: שליפת נתונים אונליין. לדוגמה: קבלת אנשי הקשר המעודכנים, בכל רגע, מ LinkedIn.

רמה 4: עדכון נתונים חד פעמית. לדוגמה: שינוי פרטי איש-קשר ב LinkedIn.

רמה 5: סיפוק נתונים אונליין. לדוגמה: LinkedIn מציג גם את אנשי הקשר מהמערכת שלי, כאילו הם שמורים אצלם במערכת.

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

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

אמנם נתתי דוגמאות של חיבור למערכות שכולנו מכירים (Waze, טוויטר, LinkedIn) - אך חלק גדול מהאינטגרציות שנעשות בעולם מתרחש בעולם ה Enterprise - שם יש אפליקציות משעממות כגון מעקב אחר פרויקט, ריכוז חיובים, וניהול זמינות של כ"א.

אינטגרציה של הפעלה (Invocation)

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

אפליקציית Rest שלה כפתור שמזניק את Waze. שימושי.

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

• ללמוד את הפורמט/פרוטוקול להעברת context (למשל: כתובת לניווט) לאפליקציית היעד.
• (צעד רשות): לוודא שאכן האפליקציה השנייה זמינה (כי ניסיון להפעיל אותה מבלי שהיא זמינה - עלול להראות לא טוב).

דפוס חוזר של הפעלה של אפליקציה כזו הוא decoupling by intent:

• אני מבקש מאפליקציית ניווט כלשהי (ולא דווקא Waze) לענות לקריאתי - ושולח את הכתובת לסביבת הריצה שתמצא לי אפליקציה שיכולה לענות על כזו בקשה.
• סביבת הריצה מפעילה אלגוריתם החלטה (בד"כ: רשימת העדפות פשוטה) ומקשרת את ההודעה שלי לאפליקציה המתאימה ביותר (כלומר: הראשונה ברשימה).

דוגמה אחת ל decoupling by intent יכולה להיות מערכת ההפעלה "חלונות", בה ניתן "לקשור" אפליקציה (למשל Word) לסיומת של קובץ (למשל docx.*) ואז הפעלה של הקובץ (פקודת start ב command line) תפתח את הקובץ באפליקציה הקשורה. אני יכול גם להתקין Libre Office ואז קבצי ה docx.* יפתחו בעזרת אפליקציה בשם Writer.

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

אספר שבמערכות שאנו עובדים איתן ב SAP יש יכולת לנהל סט חוקים מורכב המשפיעים על אלגוריתם ההחלטה - אולם רק לקוחות מעטים באמת משתמשים ביכולות המתקדמות האלה. המערכת המורכבת היא לא רק משוכללת, אלא גם קשה להבנה ולשימוש. רוב הלקוחות משתמשים בחוקים פשוטים הדומים לאלו של מערכת ההפעלה "חלונות" (מין רשימה עם priorities, ע"פ האפליקציה הראשונה שזמינה).
פריט המידע שמועבר בין המערכת המקומית לאפליקציה המרוחקת עשוי, בתסריטים של Enterprise, להיות זיהוי של אובייקט עסקי - שאותו האפליקציה המרוחקת תוכל לערוך / לבצע עליו פעולות (על בסיס גישה משותפת של האפליקציות לבסיס הנתונים, או סוג של RESTful APIs).

מנגנון  של decoupling המתבסס על כוונה (intent) מאפשר:

• להחליף את האפליקציית המרוחקת (בעולם המובייל היא מאוד קרובה, אך אדבק בטרמינולוגיה) - מבלי לשנות קוד / קונפיגורציה באפליקציית המקור.
• לאפשר התאמה אישית למשתמשים - לבחור באיזה "אפליקצייה מרוחקת" הם רוצים להשתמש (ולשמור במערכת את הבחירה).

בתסריטים העסקיים שאני מכיר - decoupling by intent עשוי להיות שימושי ורב-עוצמה.

אינטגרציה של נתונים (data integration) - מושגים בסיסיים

נוהגים לחלק אינטגרציה של נתונים ל 4 סגנונות עיקריים [א]:

• אינטגרציה ע"י העברת נתונים בקובץ.
• אינטגרציה ע"י שיתוף בסיס נתונים.
• אינטגרציה ע"י קריאה מרוחקת (RPC).
• אינטגרציה ע"י שליחת הודעת (messaging / events-based).

כמו כן, פעולות האינטגרציה מתרכזות לרוב בסכמות הבאות:

• שכפול נתונים בין מערכות (Replication) או סנכרון נתונים בין מערכות. סנכרון זה מצב יותר בריא, בד"כ :)
• קיבוץ (Aggregation) נתונים ממקורות שונים למקום אחד - עבור דו"ח או Dashboard (לוח בקרה).
• הרכבה של תהליכים "עסקיים", הרכבת כמה אפליקציות פשוטות לאפליקציה מרוכבת ומועילה יותר (Business Processes). אני מדבר ב"שפה עסקית" אך זהו גם הסיפור של אפליקציית Rest שפותחת את WAZE שפותחת את גוגל (לקבל עוד נתונים בעקבות פרסומת בדרך).
• סיפוק שירותים נקודתיים, כדי למנוע שכפול נתונים או פונקציונליות - למשל שירות של מילון (Dictionary) או שירות קבלת כתובת דואר של עובד. שירותים אלו יכולים לשמש UI (כלומר: משתמש קצה) או מערכות אוטומטיות.

כן, אבל...

אם נדמה לנו שמאמץ האינטגרציה נגמר בהעברת נתונים או הזנקה של אפליקציה - אנו מעט אופטימיים.

אינטגרציות כוללות גם לא מעט קשיים בדרך:

• אפשור גישה ברמת הרשת.
• עבודה בפורמטים שונים.
• אינטגרציה עם מערכות Legacy.
• אימות זהות ואבטחה.
• אנשים אחרים / עולם מושגים שונה / DNA ארגוני שונה.
• מערכות Legacy / שאינן יכולות להשתנות.
• הבדלי מהירות / קיבולת בין המערכות - שלא לדבר על זמינות.
• סינכרון ו Concurrency.

ואחרי שכל האינטגרציה "הסתיימה":

• שינויים ב API / חוזה (contract) של המערכת המרוחקת.

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

אינטגרציה היא לא דבר חדש ויש Framework / מערכות לאינטגרציה, כדוגמת TIBCO (חבילת מוצרים גדולה), BizTalk של מייקרוסופט או Apache Camel (הקטן והחביב). למה לא פשוט להשתמש בהן - ולא "לשבור את הראש"?
ספריות / מערכות אלו הן כלי עזר לאינטגרציה - אך לא "פתרונות קסם" ש"מסירים מהדרך" את הבעיות הנ"ל. למשל: במקום לכתוב 100 שורות קוד בכדי להאזין לשינויים בתיקיית קבצים, לפרסר את הקובץ ולשלוח את המידע החדש שנוסף כ JMS message - תוכלו אולי לכתוב בעזרת הספריה 4-5 שורות דקלרטיביות או ב DSL שיעשו אותה עבודה. בכל זאת, לא תמצאו שם פתרונות אוטומטיים לבעיות אבטחה, הבדלי מהירות או זמינות בין המערכות וכו'. בטח שלא לבעיות של תקשורת בין בני-אדם :)
יהיה עליכם להבין את האתגרים האפשריים, לחשוב, לנתח - ולפתור.

אפרופו יש קטגוריה של פתרונות בשם ESB (קיצור של Enterprise Service Bus) - שמופיעים כמודול ברוב פתרונות ה Middleware של החברות הגדולות (IBM, Oracle, TIBCO וכו') או בגרסאות חופשיות (למשל Apache Mule).
אלו בד"כ פתרונות יותר כבדים מ"מערכות האינטגרציה" אותן הזכרתי, הם קשורים בצורה הדוקה בד"כ לארכיטקטורת SOA שמרנית, ונחשבים כלא כ"כ מוצלחים (כקונספט - אני לא מדבר על המימוש).
אני לא מנסה לדבר עליהם, ולא רוצה שתבינו בטעות שכדי לבצע אינטגרציה - זקוקים לתשתית כלשהי. כלים שכאלו כדאי להכניס לשימוש כדי לחסוך זמן (במיוחד כשיש הרבה עבודה) - לא כדי "לפתור את הבעיה".

לא קל...

תהליך אינטגרציה: ממה להיזהר? וכיצד?

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

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


אפשור גישה ברמת הרשת
אם שתי המערכות המעבירות בניהן מידע נמצאות באותה רשת מקומית - אז אין בעיה.
במקרים אחרים הן נמצאות ברשתות שונות, שבניהן מותקנים רכיבי רשת מגבילים (חומות אש, IPS או אמצעי הגנה אחרים).
לפעמים מערכת אחת יושבת בענן, והשנייה ברשת הפנימית של ארגון (ואז יש שאלה איך ניגשים מהענן לרשת הפנימית).
לפעמים משתפים מידע בין 2 רשתות פנימיות של ארגונים שונים, שחוץ מחיבור זה - זרים זה לזה.

ענייני רשת - יש לפתור נקודתית למצב הנתון.
יש כלל מנחה שאומר שאת היוזמה לתקשורת עושים מהאזור המאובטח יותר - לאזור המאובטח פחות. כך יתר קל להתמודד עם אמצעי ההגנה השונים. למשל: מן הרשת הפנימית של הארגון - לענן, או מן הרשת הפנימית של ה Data Center לרשת הארגונית ה"רגילה".
במקרים בהם אין יכולת לתקשורת ישירה (בגלל מורכבות של רשתות ה LAN בארגון) - מציבים agent או broker בדרך שיאפשר להעביר הודעות / נתונים.


עבודה בפורמטים שונים
בעוד מערכת אחת עוטפת את המידע ב XML בצורה אחת - והשנייה ב XML בצורה אחרת. עצם השימוש "המשותף" ב XML לא מוסיף לאינטגרציה כמעט דבר, אם הפורמטים שונים. גם בתוך ה XML (או JSON, CSV וכו'):מערכת אחת מתארת תאריך בפורמט ארוך - והשנייה בפורמט קצר, אחת כתובת בשדה אחד והשנייה במספר שדות שונים, וכו'.
עבור קריאות מרוחקות (RPC), ההבדלים יכולים להיות גדולים יותר: DCOM מול CORBA או RMI מול REST API - צורת התקשורת שונה, ולא רק פורמט אותו ניתן להמיר.

יש גם נושא של Data Integrity: מערכת אחת מוכנה לקבל רשומה כאשר שדה x חסר (ערך ריק) - ומערכת שניה לא מוכנה לקבל זאת. אולי תאימות בין הנתונים: מערכת אחת בודקת את ערכי השדות שיתאימו לכלל מסוים - והשנייה לא.

את המידע ממירים בעזרת Adapters (או Transformers/Normalizars במערכת מורכבת יותר) - בכדי לתאם בין הפורמטים / פרוטוקולים. לפעמים עושים תהליך נוסף של Data Quality - תיקון הנתונים בכדי לעמוד ב"סטנדרטים" של אחד הצדדים (שלמות, דיוק וכו').

עניין של פורמטים הוא בד"כ לא "נושא מורכב" (זו קרקע מצוינת לכיסוי עם Unit Tests) - אך זו עבודה. בד"כ ככל שהמידע הוא Human Friendly - ההמרה תהיה קלה יותר. המרה של מידע בינארי, נוטה להיות מורכבת יותר.


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

כאשר אנו רוצים לשלוף נתונים ממערכת Legacy שלא התאימה את עצמה ל export של המידע לו אנו זקוקים - משימת האינטגרציה יכולה להיות קשה. תת-תחום, מוכר יחסית, של נושא זה הוא העולם של Web Scrapping- שליפת נתונים ממערכות ע"י פענוח ה HTML שהן מייצרות (ולא תמיד בהסכמתן). משימות של Scraping בדרך כלל יותר נוח לעשות בשפות דינאמיות עשירות בספריות לטיפול בטקסט כמו פייטון או רובי, אם כי יש מגוון רחב של ספריות. אפשרויות אחרות הן "דיג" של נתונים מתוך לוגים או קבצי נתונים שהמערכת מספקת - אך תוכננו לצורך אחר.


אימות זהות ואבטחה
בעולם הווב / Social יש היום את OAuth שמקל על המשימה - לשלוף נתונים בצורה מאובטחת ממערכת מרוחקת. בעולם ה Enterprise התמיכה ב OAuth היא עדיין מועטה.
כאשר משתמש מזניק (invocation) אפליקציה אחרת - נרצה לחסוך ממנו הקשה נוספת של משתמש/ססמה, בעזרת SSO. כנ"ל לגבי שליפת / עדכון נתונים. בהרכבה של תסריטים עסקיים מורכבים, ייתכן והמשתמש יפעיל כמה אפליקציות שונות בכמה דקות. הקלה של ססמה כל פעם - היא שוחקת ומכבידה.

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

סנכרון ו concurrency

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

הבדלי מהירות / קיבולת בין המערכות

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

כלומר: אי-זמינות של מערכות הוא מדבק, ויש לבנות מנגנונים (נקראים Circuit Breakers) למניעת הידבקות זו.
Circuit Breakers יכולים להופיע כמנגנונים האוכפים timeout קצר בניסיון לקריאה ממערכת מרוחקת.
יש כאלו שיזהו רצף של תקלות וימנעו ניסיונות תקשורת - עד אשר תהיה התערבות ידנית / מנגנון שמזהה התאוששות יפעל.

Circuit Breaker מתוך הפוסט של מרטין פאוולר בנושא.

וריאציה אחרת היא בהבדלים במהירות או Scalability בין המערכות:
נניח שהמערכת המקומית מסוגלת לטפל באלפי בקשות בשנייה (tps) אך המערכת המרוחקת - לא ביותר מ 50 קריאות בשנייה. ברוב המקרים זה מספיק - כי רק במקרים מאוד מסוימים אנו פונים למערכת המרוחקת. מצד שני, פעם בכמה זמן יכול להיות peak בו אנו פונים למערכת המרוחקת 100 פעמים בשנייה - גורמים לה לקרוס, ואז אם אין לנו מנגנון הגנה, אנו יכולים לקרוס בהמשך בעצמנו. הכל בגלל אינטגרציה קטנה ושולית.

מנגנון הגנה אפשרי הוא ליצור (מטאפורה:) סוג של צינור מצר, בעצם זה סוג של counting lock שלא מאפשר למערכת שלנו לבצע יותר מ x קריאות למערכת המרוחקת בו-זמנית. אנו מגנים עליה - כי זה אינטרס שלנו שהיא לא תקרוס. מנגנון כזה נקרא (Throttling (controller. כמובן שהמערכת המרוחקת יכולה לקרוס מסיבות אחרות - וזה לא תחליף ל Circuit Breaker בסיסי יותר.

שינויים ב API / חוזה (contract) של המערכת המרוחקת
ה APIS במערכת המרוחקת עלולים להשתנות עם הזמן.
אפילו יותר מכך: לפעמים ה API (החלק המוצהר) נשאר כפי שהוא, אבל חלק אחר, לא מוצהר, ב contract משתנה: סדר פעולות, Exceptions שנזרקים או תופעות לוואי אחרות. כל אלו - יכולים לשבור את האינטגרציה ודורשים תחזוקה.
ישנם מקרים בהם השינויים הם תדירים מאוד (בעיקר מוצרים צעירים) - ואז התחזוקה היא מעמסה רצינית.

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

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

סגנונות אינטגרציה וכיצד הם מתמודדים עם האתגרים השונים

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

אינטגרציה ע"י העברת נתונים בקובץ

אינטגרציה זו היא בסגנון export של נתונים במערכת ב' ואז ביצוע import של הנתונים אל המערכת שלנו.

יתרונות:

• "מדלגת" על מגבלות של רשת או הרשאות. ה export/import וה transport נעשים עם הרשאות של משתמשים ספציפיים.
• פשוט למימוש

חסרונות:

• תקורה של קריאת / פענוח קבצים - מכבידה על טיפול בכמויות גדולות באמת של נתונים.
• פער זמן בין export ל import
• מתאים להעברת נתונים ולא ל invocation / הפעלת פונקציות (חד-צדדי)
• כשאופציה זו נבחרת, היא בד"כ מיושמת בצורה לא-אוטומטית

אינטגרציה ע"י שיתוף בסיס נתונים

יתרונות

• קל למימוש
• יעיל מבחינת ביצועים (גישה ל raw data)
• Consistency (יחסי) של הנתונים

חסרונות:

• אין הכמסה. מערכת אחת נוגעת במבנה נתונים של מערכת אחרת. ניתן לראות זאת כממשק מאוד מאוד רחב בין המערכות - וזו הסיבה העיקרית שגישה זו היא הכי-פחות מועדפת עלי באופן אישי, מכל הסגנונות. שינויי סכמה משפיעים מיידית על 2 המערכות.
• גישה ישירה לבסיס הנתונים עוקפת Business Logic ואימות נתונים שבא איתה, Caches של ORM או שכבות עליונות וכו'.
• בסיסי נתונים (רלציוניים בעיקר) הם מאותגרים scalability והוספת מערכת נוספת שעובדת על אותו בסיס נתונים יכולה להיות מגבילה / לדרוש שדרוג יקר של החומרה.

אינטגרציה ע"י קריאה מרוחקת (RPC)
RPC הוא קיצור של Remote Procedure Call (שם שמקורו היסטורי) והכוונה היא לכל הטכנולוגיות של הפעלת פונקציות מרחוק: REST, RMI, XML-RPC, אולי RPC ברמת מערכת ההפעלה ועוד.

יתרונות:

• הכמסה בין המערכות
• ממשק מוגדר היטב
• online

חסרונות:

• תלות חזקה בין המערכות (ממשק + ידע על מיקום/כתובת המערכת המרוחקת)
• תקשורת סינכרונית בלבד

אינטגרציה ע"י שליחת הודעת (messaging / events-based).
שליחת הודעות נעשית בד"כ דרך מנגנון לשליחת הודעות ייעודי, מה שנקרא MOM (קיצור של Message Oriented Middleware). מערכות נפוצות שבשימוש הן Apache ActiveMQ, RabbitMQ, רדיס (Redis) ומנגנון ה Pub-Sub שלו (עליו כתבתי בפוסט בעבר), Apache Kafka (ל Scale גבוה) או מימושים שונים של מנועי JEE/חברות התוכנה הגדולות.

יתרונות:

• גמישות רבה לאינטגרציות מורכבות
• פוטנציאל Scalability נהדר (בכמות הנתונים)
• אפשרות לאסינכרוניות ו reliable messaging (אולי תכונות חשובות, לא דווקא יתרונות)

חסרונות:

• תוואי רשת יכול להקשות על scalability במספר המערכות המעורבות באינטגרציה
• איתור תקלות יכול להיות מורכב ודורש לוגים / כלי Monitoring
• פרגמנטציה רבה של תשתיות זמינות

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

יש גם מרחב גדול של מימושים באמצע מבוסס REST/HTTP/JS - שזה סוג של RPC, אבל עם טכנולוגיות ווב מודרניות ופשוטות (וקצת פחות "RPC by the book")

סיכום

שוב תכננתי פוסט קצר....

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

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

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

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

אולי הדרישה לניהול מרחוק והדרישה ל"אלסטיות" של המערכות מעודדת יותר ארכיטקטורה מונחית שירותים / Micro-services? - מה שהופך את האינטגרציה לקלה יותר. לא יודע.

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

----

[א] המקור המוקדם ביותר שמזכיר חלוקה זו, שאני מכיר, הוא הספר Enterprise Integration Patterns, אולם נתקלתי בחלוקה זו שוב ושוב ממקורות שונים.

Posted with Blogsy

דפוסי עיצוב (Design Patterns): ימים יפים, ימים קשים

[הפוסט נכתב בשיתוף עם רחלי אבנר, Area Architect בחברת SAP]

[ליאור:] שוחחתי לפני כשבוע עם ארכיטקט ותיק בחברת תוכנה ישראלית. סיפרתי לו שאנו מעבירים קורס של Design Patterns בחברה.
"למה....?!" - הוא שאל, תופס את ראשו בידיו במבט מיוסר.
"כן.... גם אני לא מתלהב מהנושא" עניתי. "אבל אנשים רוצים. מה, נמנע מהם את הידע הזה??"

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

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

כיצד ומדוע עלו ה Patterns לגדולה?
מדוע אם כן יש עליהן ביקורת, והאם יש לכך הצדקה?

על כך בפוסט שלפניכם.

כריסטופר אלכסנדר

שורשים

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

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

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

מ-ש-ע-מ-ם

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

עדיין, זה לא מבנה שגורם לנו להרגיש "בבית".

הנה מבנה מוצלח יותר:

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

את שרשרת ההבחנות סיכם בשלושה ספרים, שהמשמעותי ביניהם נקרא: A Pattern Language: Town, Building, Construction.

כריסטופר אלכסנדר הציג דפוסי עיצוב כגון "כניסה ראשית", "אזור ישיבה", "גומחה" (Alcoves), "שדרה", וכו'. כל אחד מהם היה זיקוק של תובנות כיצד יש לתכנן אלמנט זה במבנה בצורה טובה יותר. הוא הגדיר אותם כדפוסי עיצוב המעודדים חיים, הוא השתמש גם בביטוי "איכות ללא שם". הספר כלל 253 דפוסי-עיצוב [ה].

ספרי דפוסי העיצוב של כריסטופר אלכסנדר

דפוסי-עיצוב בתוכנה

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

את הרעש הגדול עשו ארבעה: אריך גאמה[ב] ניהל שיחה עם ריצארד הלם בה עלו הרעיונות לספר. אח"כ הם צרפו את ראלף ג'ונסון וג'ון וילידס. ארבעתם ידועים כ "Gang Of Four" (או בקיצור GOF). רובם חוקרים / בעלי רקע משמעותי של מחקר במדעי המחשב - אבל הם כתבו את הספר, כנראה הנמכר ביותר בתחום, אחד המשפיעים ביותר ושנחשב למאוד מעשי ושהקדים את "האקדמיה" בשנים.

"הספר"

בספר הם תיארו סט של בעיות תכנות - ופתרונות Object-Oriented אלגנטיים ("דפוסי עיצוב"). דגשים עקרוניים היו הפשטה וגמישות להרחבה עתידית - עקרונות החרוטים על דגלה של פרדיגמת ה Object-Oriented.

Facade, Proxy, Adapter, Singleton ועוד - הם מושגים שהטביע בעולם התוכנה ספר זה.
"דפוסי העיצוב" היו כבר קיימים בעולם: לכל דפוס עיצוב הם סיפקו מספר דוגמאות של יישומים במערכות קיימות. בספר הם אספו אותם, תיעדו אותם ויצרו שפה חדשה להנדסת תוכנה Object Oriented.

ההצלחה של הספר הייתה חסרת תקדים, וזעזעה (לטובה) את עולם התוכנה. בעקבותיה קמה "תנועה" של Patterns ונכתבו, בזמן קצר יחסית, מספר רב של ספרים עם Patterns רבים נוספים (ביניהם סדרות כגון PLOP או POSA). ה GOF החלו אף לדבר על הוצאת מהדורה שנייה.

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


גם היום, 20 שנה אחרי, ספרים חדשים משתמשים במותג "Patterns" בכדי לקסום לנו, ולהימכר טוב יותר:

סדקים ראשונים

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

• Singletons are Pathological Liars - סינגלטונס מבלבלים והם לא OO. הם בסה"כ Global State בעולם OO. אולי אפילו - הפרה של עקרונות ה OO.
• Visitor הוא לא "שכבת הפשטה", יש לו תלות גדולה מאוד במי הוא מבקר ואז הוא כמו "משפטי If מסודרים יפה".
• הבטיחו לנו ש Patterns הם אינם תלויי-שפה, אבל פיטר נורוויג מראה שרוב ה Patterns כבר מוטמעים או מיותרים בשפות דינמיות, דפוסי עיצוב מסוימים אינם נדרשים בשפות מסוימות (ל #C יש delegate שמייתר את הצורך ב Command, דפוס העיצוב iterator הפכה לבלתי-נדרשת / implicit בשפות תכנות מודרניות רבות,  וכו').
• AreDesignPatternsMissingLanguageFeatures? וגם הוידאו הבא.

הזמן גם עבר... והאופנות קצת השתנו - ויצרו סדקים נוספים:

• תנועת האג'ייל: את התכנונים (Design) ה Top Down, החליפו ב Evolutionary Design ו Bottom Up. היכן ש Design Patterns כבר פחות מתאימים.
• בזמן הוצאת ספר דפוסי-העיצוב, תכנות OO (או תכנות מונחה היבטים - AOP) היה "הדבר הגדול הבא". היום תכנות OO הוא נפוץ מאוד - אבל "הדבר הגדול הבא" הוא משהו בין תכנות דינאמי לפונקציונלי - קצת שונה מהעקרונות של OO. לשפות אלו, דפוסי העיצוב המוכרים - פחות מתאימות.
• "אמיתות של הנדסת תוכנה" גם הן השתנו. אם פעם שימוש חוזר בקוד היה העיסוק המרכזי, היום אלו יותר פשטות של הקוד ו time-to-market. העיקרון הפתוח-סגור (Open-Closed Principle) פעם היה מאוד פופולרי (ורואים את חותמו בספר של GOF) - אך כיום הוא שנוי במחלוקת. דפוסי העיצוב מהספר של GOF מקדמים הרבה שימוש חוזר והפשטה - וקצת פחות פשטות.

את הסדק הגדול ביותר ניתן לתאר בעזרת הסיפור (לא מצאתי את המקור) על מרצה שהרצה על Design Patterns רק כדי לשים לב לאחר שנים לשאלות המוגזמות-מיסודן שמעלים אנשים: "האם עדיף להשתמש ב Flyweight או במשפט If"?
Flyweight או משפט If? האם Simplicity היא לא ערך - האם הגיוני להחליף שורת קוד אחת במבנה שלם (Flyweight)?!

דפוסי העיצוב באו להלחם בעולם עם Under-Engineering, אך יצרו עולם של Over-Engineering.

לזרוק ולשרוף?!

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

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

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

אני אסביר:
כשלמדתי עיצוב תוכנה אמרו לי בערך כך: "תרשום על דף את הדרישות, תחשוב, תעשה איזה תרשים UML והנה יש לך עיצוב תוכנה". לא הרגשתי שלמדתי תובנות משמעותיות כלשהן, או שלמדתי כיצד לעשות את התהליך נכון.
אני מניח שהחוויה של רוב האנשים בתעשייה שלנו איננה שונה בהרבה.

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

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

לו רק הייתה יותר הכוונה...

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

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

כיצד להשתמש בדפוסי עיצוב בצורה נבונה?

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

צדדים טובים:

• פתרונות מוכנים ומעולים לבעיות תכנון. נכון חלקית: אלו פתרונות טובים לבעיות מאוד מסוימות, וקיים סיכון סביר (ומוכח) - שאלו לא הפתרונות הכי טובים למערכת שלכם. זכרו: גם בספר "Design Patterns" - לא תמיד באמת מדברים עליכם.
• שפה משותפת: ברגע שגם אני וגם בין-שיחי מכירים את דפוסי העיצוב (למשל) "Strategy" - יהיה לנו הרבה יותר קל לתקשר על בעיה / פתרון טכני מסוים. מילה אחת יכולה להחליף הסבר של כמה דקות. חשוב ללמוד דפוסי-עיצוב בכדי לקבל מושגים משותף ולהפוך את התקשורת בזמן העבודה ליעילה ומדויקת יותר. כמו כן, היחסים המוכרים בין תבניות שונות מאפשרות בסיס לשיחה על מבנים מורכבים יותר (למשל: MVC). שפה משותפת היא התועלות המוסכמות ביותר בימנו המיוחסות לדפוסי-עיצוב.
• מקור השראה: לא חייבים ליישם את דפוס העיצוב כלשונו. ניתן לעשות וריאציה, ניתן לקחת רק רעיון אחד מדפוס העיצוב - ולעשות משהו אחר לגמרי. לגישה זו יש הרבה פוטנציאל, ולשם כך טוב (באופן כללי בכלל) להכיר תכנונים לא-טריוואילים של מערכות אחרות.

צדדים פחות טובים:

• הנדסת-יתר (over-engineering) - עסקנו בבעיה זו די והותר.
• פוטנציאל לקיבעון: מצב בו למישהו קשה ליישם מבנה דומה-חלקית לדפוס העיצוב, כי הוא מרגיש ש"דפוס העיצוב" חכם בוודאי ממנו - ואז הוא נגרר ליישום פחות מוצלח (אם כי שמתועד בספר אגדי).
• פוטנציאל לקיבעון כרוני: אנשים שלא מוכנים להאמין שיש פתרון טוב יותר (בהקשר המסוים) מזה המתואר בספר האגדי של "Design Patterns". לכו תשכנעו אותם.

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

הדרכים המומלצת היום להשתמש בדפוסי עיצוב הן:

• ככלל: אל תתחילו לכתוב קוד ולהשתמש בדפוסי-עיצוב. אל תעשו הכנה ל Adapters - כאשר יש רק יישום אחד מוכר. "בטח בעתיד יהיו עוד - בואו נכין את הקרקע מעכשיו" - זו לא גישה אג'ילית.
• Refactoring to Patterns - במידה והגעתם לקוד שיש בו ריחות (code smells) המצביעים על בעיה בקוד (שכפול קוד ברור, תלויות לא רצויות וכו')....
• שקלו את דפוס העיצוב המתאים. זכרו שדפוסי עיצוב מגבילים לפעמים את גמישות הקוד בכיוון מסוים. לא על כל 5 שורות קוד כפולות - כדאי להשתמש ב State, למשל.
• עשו Refactoring ושנו את הקוד כך שיישם את דפוס העיצוב שהחלטתם שהוא מוצדק - או גרסה דומה שלו. חשוב להבין "מה הקטע" של כל דפוס עיצוב - ולא סתם ליישם אותו "ע''פ הספר".

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

אפרופו: בהינתן ההבחנה ש"שפה משותפת" היא ערך עיקרי של דפוסי עיצוב ו"שימוש מופרז" היא הסכנה המרכזית - ניתן להצביע על Anti-Patterns ככלי שיכול להיות מצוין: Anti-Patterns הם תיאורים של דפוסים שליליים ולא-מומלצים מהם יש להימנע או לפחות להיזהר. אפשר לציין Anti-Patterns כגון "Gold Plating" (השקעה מופרזת באלמנט לא-חשוב), "Project Chicken" (אף אחד בפרויקט לא יכול לעמוד במשימה / לוחות הזמנים - אך כולם פוחדים להיות האדם הראשון שמודה בזה. לאחר שאחד הודה - כל השאר מצטרפים "אם הוא לא יעמוד ביעד - זה יתקע גם אותי"), "Death March" (עבודה על פרויקט ללא סיכוי הצלחה - אך מישהו "למעלה" מסרב להכיר במציאות הזו והפרויקט ממשיך) ועוד.

היופי ב Anti-Patterns הוא שאף אחד לא "ירוץ" ליישם אותם - זה לא מקור לגאווה. אין over-engineering.
החיסרון: שום מקור לא הצליח לייצר מומנטום מספיק גדול בכדי להפוך שפה כלשהי של Anti-Patterns לנפוצה מספיק בכדי שתהיה ידועה ומוסכמת בקרב קהל משמעותי [ד].

דפוסים כתהליך של התחדשות

[רחלי:] לפני שנים רבות השתתפתי בקורס שהעביר Jim Coplien בישראל (כמדומני כאורח של מכללת סלע) ובה הוא לימד איך כותבים דפוסים. בכל פרויקט תוכנה ניתן לזהות בעיות שחוזרות על עצמן ושיטות קבועות לפתרון של אותן בעיות. יש שיכנו זאת "הארכיטקטורה של המערכת". בחלק מן המקרים השיטות האלה מוכיחות את עצמן כנכונות וטובות, בהקשר של הפרויקט המדובר, ואז יש ערך רב לפרמל אותן ולתת להן שם. כדאי לתאר את הבעיה החוזרת, את ההקשר של השימוש בדפוס-העיצוב ואת הפתרון המתאים. חשוב לספק הנחיות מתי כדאי להשתמש בתבנית העיצוב - ומתי לא.

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

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

Proxy ו Observer אולי הפכו לחלק משפת JavaScript (בצורת bind ו object.observe, בהתאמה) אבל עם התפתחות השפה והאתגרים שלה נוצרו גם דפוסים המתאימים להתמודדות עם האתגרים החדשים (לדוגמה: Module).

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

סיכום

• היללנו את דפוסי העיצוב.
• השמצנו וביקרנו את דפוסי העיצוב.
• לקראת הסוף: ניסינו לספק תמונה רחבה ומאוזנת.

כדאי ללמוד על דפוסי-עיצוב כשפה, תוך כדי שימוש בדוגמאות עדכניות ורלוונטיות. למשל:
במקום ללמד על Proxy על ידי ניתוח ה UML שהובא בספר של GOF ועיקרו היה מימוש פרוקסי ב ++C, אפשר להתעכב על הרעיונות שפרוקסי מייצג, ואז לראות אותם ממומשים בשפות השונות (proxy$ בספריית jQuery או bind בג'אווהסקרפיט. Dynamic Proxy בג'אווה וכו').

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

זה קצת מרתיע לכתוב על נושא כ"כ מדובר ומקובל - במיוחד כשיש גם דברי ביקורת. האם יצא רק במקרה שכתיבת הפוסט הסתיימה ביום שישי ה-13?!


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



----

קישורים רלוונטיים:

דפוסי עיצוב של חווית משתמש (בעברית) וגם פרק בפודקאסט

----

[א] איש מדעי המחשב שעסק רבות ב concurrency והספריה שכתב כהשלמה לג'אווה - נכנסה מאוחר יותר לסט הספריות הסטנדרטיות.

[ב] מאוחר יותר היה שותף לכתיבת הספרייה JUnit והוביל את התכנון של סביבת הפיתוח Eclipse.

[ג] "All problems in computer science can be solved by another level of indirection", שפעם נחשב לאמת מקובלת. רפרנס: http://www.dmst.aueb.gr/dds/pubs/inbook/beautiful_code/html/Spi07g.html

[ד] והיו כמה ניסיונות, למשל הספר AntiPatterns או הספר Adrenaline Junkies and Template Zombies.

[ה] על עבודתו של אלכסנדר בתחום הארכיטקטורה אפשר לספר הרבה. הנה שני מקורות מעניינים מאד בעברית:
פרוייקט תרגום שיתופי לעברית של הדפוסים של אלכסנדר, והבלוג של יודן רופא, שהיה תלמידו של אלכסנדר
מי שקורא את מה שנכתב על עבודתו מגלה תאוריה עמוקה הרבה יותר מ"רשימת מכולת של דפוסים" וכוללת אלמנטים פילוסופיים כמו גם שיטות מעשיות להוצאה לפועל של התאוריות האלה. אגב, שיתוף משתמשים ועבודה איטרטיבית – שמוכרים היום כחלק מעקרונות האג'יליים בהנדסת תוכנה, היו גם חלק מהותי בשיטת העבודה של אלכסנדר, וניתן לקרוא עליהם בשני ספריו האחרים The Oregon experiment ו-  A Timeless way of building.