להבין את המפתחים, חלק 1

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

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

לבטח יצא לכם לשמוע במסדרונות החברה, או בשיחות בקפיטירה באזזוורדס כאלו ואחרים היוצאים מפיהם של אנשי הפיתוח, הם מדברים על Angular, מתקשקשים על Node JS ומתבדחים על חשבון אלו שלא מצליחים ליישם את Redux… לנו יש את הקללות שלנו (מישהו אמר פה STD ?) ולהם יש את שלהם. אז בואו ונכיר קצת את המושגים הללו, נבין מה זה אומר.

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

ספריית קוד (Code Libraries):

ספריית קוד הינה אוסף של שורות קוד שנועד לפתור בעיות שחוזרות על עצמן, ישנן לא מעט ספריות קוד בעולם הפיתוח שנועדו לפתור מינים רבים של בעיות בתחומים שונים, למשל ספריות ל-Data Science, ספריות לבעיות מתמטיות מורכבות, ספריות ל-Machine Learning וכן, ספריות לפעולות אוטומטיות (מישהו אמר Selenium ?)

למה בכלל צריך את זה ?

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

• אותנטקציה של חיבור למערכת, הרשאות, אבטחת מידע…
• קישוריות לחיבור לבסיס נתונים
• כתיבת מערכות ניתוח ודיווח על תקלות
• האזנות לבקשות HTTP/S
• ועוד הרבה…

תסכימו איתי כי אתגרים אלו יכולים להתקיים בצוות ה-R&D של Wix או אצל המפתחים שכתבו את מערכות הניהול הפיננסיות של "מגדל". אבל בשני המקרים אותם מפתחים יכולים לקבל עזרה ממפתחים אחרים בעולם שהחליטו לכתוב פרוייקט Open Source אשר פותר את האתגרים (או אחד מהם לפחות) עימם הם מתמודדים.

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

ספריות הקוד יחשפו בפניהם API (אותו אוסף של מתודות המאפשר להם להשתמש בפתרון של אחרים) איתו ניתן לעבוד שוב ושוב ושוב (Reusable).

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

בעולם האוטומציה שלנו, יש מגוון רחב מאוד של ספריות קוד, המוכר והפופולרי ביותר הוא ה-Selenium, שהספריות שלו פותחו במגוון של שפות תכנות, מה שנקרא: Bindings, רק שימו לב כי Selenium אמנם הם ספריות הקוד, אך כלי האוטומציה הם הדרייברים למיניהם, כגון ה-ChromeDriver, GeckoDriver וכו', והתקינה (הפרוטוקול) נקרא: WebDriver, כך שאם נעשה אנלוגיה על נסיעה בכביש אז:

• ה-Selenium אלו הם הוראות הנסיעה מנקודת המוצא אל היעד, הוראות אלו יכולות להיכתב בשפות שונות
• ה-ChromeDriver הוא המנוע, כלי ההיגוי ההאצה וההאטה של הרכב, המנוע הזה למשל של ה-ChromDriver יכול להתאים רק ל"מכונית" מסוג Chrome
• הדפדפן הינו הרכב, כאמור יש לנו מגוון של רכבים, כמו Chrome, Firefox, Edge וכו', לכל מכונית המנוע שלה (GeckoDriver, EdgeDriver, ChromeDriver ועוד…)
• ה-WebDriver הוא הכביש עליו ניסע כדיי להגיע אל היעד

פריימוורקים (Frameworks):

גם הפריימוורקים נותנים לנו את יכולות ה-Reusable Code וגם הם יחשפו בפנינו API , ההבדל הוא שפריימוורקים יתנו לנו בנוסף גם איזשהו שלד או מבניות לכתיבת תוכנה, הקונספט הזה יביא איתו פתרונות לשאלות כמו:

• איך נבנה את המוצר שלנו ?
• איך נאתחל את המוצר שלנו ?
• איך נתממשק בין המוצר שלנו למוצרים אחרים ?

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

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

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

בעולם האוטומציה שלנו, כמו ספריות הקוד, יש גם לא מעט פריימוורקים, למשל ה-Katalon Studio אותו סיקרתי כמה פעמים בבלוג שלי, הוא דוגמא מצויינת ל-Framework, זוהי חבילה שמכילה בתוכה ספריות קוד של Selenium בין היתר (כמו שבמפעל ישנם מכונות שיודעות למדוד ולחתוך קרשים), ונותנת לנו פתרון מושלם יותר, כמו היכולת להריץ במקביל, היכולת להפיק דוחות ריצה, היכולת להגדיר הירארכיות של בדיקות (Step / Test / Collection / Suite) ועוד… (ל-Selenium אין את כל הדברים הללו).

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

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

ישנם לא מעט מאמרים ומצעדים של ה-Top 10 Automation Tool ברשת אשר מערבבים שם ברשימה בין ספריות ולבין פריימוורקים – מה שגורם להשוואה לא נכונה, כנראה מחוסר מודעות וחבל שכך, אני לא חושב שניתן להשוות את Selenium ל-Katalon Studio כמו שלא ניתן להשוות מסור למכונת חיתוך במפעל.

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

יש למה לצפות,

יוני