מה ההבדל בין אוטומציה לפיתוח רגיל

מבוא

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

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

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

קודם כל, מה זה פיתוח אוטומציה?

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

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

לפי ההגדרה הזו, כתיבת הספרייה selenium היא כתיבת אוטומציה, אם ניקח את זה קצת יותר רחוק, גם כתיבת המערכת jenkins היא אוטומציה.
האם Jason Huggins ו Simon Stewart, שניים מהמפתחים הראשיים של הספרייה סלניום, הם מפתחי תוכנה? הם מפתחי אוטומציה? האם זה בכלל משנה?

הסוגים השונים של תשתיות האוטומציה

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

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

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

אוטומציה ללא תשתית

קיימים בשוק מפתחים וצוותים רבים שמתנהלים ללא תשתית (או עם תשתית מאוד מינימלית), הדרך הקלה לראות את זה היא להסתכל על קבצי הטסטים שלהם ולראות איזה ספריות הם מייבאים (import), ככל שיש יותר ייבוא של ספריות צד שלישי בקבצים שמכילים את הבדיקות, כך כנראה התשתית באה לידי ביטוי פחות.
במילים אחרות, אם אתם נכנסים לפרויקט ותחת קבצי הטסטים אתם רואים הרבה שימושים ב - selenium, appium, requests, restAssured, restsharp, sshClient, paramiko וכו׳ וכו׳. סימן שאין לכם הרבה תשתית.

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

תשתית לשימוש עצמי

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

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

תשתית לשימוש פנים ארגוני/מעט משתמשים חיצוניים

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

משתמשי התשתית: פעמים רבות בתשתית כזו, משתמשיה לא יוכלו לדעת עד הסוף מי ישתמש בתשתית ואיך.

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

מוצר אוטומציה

כאן כבר מדובר על מוצר של ממש.
לקטגוריה הזו כל ״מוצרי האוטומציה״. אפשר למצוא שם מספריות כבדות כמו selenium ו appium ועד תשתיות ענקיות שנמכרות כמו מוצר כמו testim.io, Test Project, Applitools ועוד הרבה. אלו מוצרים גדולים, עם צוותי פיתוח, צוותי בדיקות ולפעמים אפילו צוותי בינה מלאכותית. 

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

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

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



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

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



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

אז תכלס, מה ההבדל?

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

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

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

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

סיכום

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

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

השאלות שעלינו לשאול בשביל להשוות הן - מה אני כותב, איך אני כותב ולמי אני כותב?

תגובות

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

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

      מחק
  2. מאמר מעניין , מעשיר. תודה!!

    השבמחק

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

תכנות מונחה עצמים | Dependency Inversion Principle

מהם קבצי DLL ואיך להשתמש בהם?