מדוע כדאי למפתחים לאמץ פלטפורמה לפיתוח מהיר?

עודכן ב: 15 אוק 2020


הביקוש האדיר לאפליקציות דורש פיתוח מהיר.

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

האימוץ המסיבי של פלטפורמות Low-Code החל, במטרה להקל על הדרישה העצומה לפיתוח אפליקציות.

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

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

תחת חששות אלה, נשאלת השאלה כיצד רותמים אותם לשינוי? ומדוע שליטתם בכלי Low-Code כדאית להם?

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

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


כדאי שבארגז הכלים של מפתח מוביל, יהיה מכחול, אבל גם מברשת...

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

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

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

למפתח החסר את מיומנויות ה Low-Code אין מה להציע כאן. הוא יכול לפתור הכל, אולם קצב סבבי התוצר לא רלוונטיים למשתמשים. המרחק בין דרישה לפתרון עובד, רחוק באופן בלתי סביר (נכון להיום, בארגון ממוצע, קצב השינוי גבוה מקצב אספקת הפתרון). על כן מפתח המתמחה בכלי פיתוח מדור 3 (ומרגיש שהוא מצויד בנשק יום הדין) ואפילו אם הוא מפתח Full-Stack, שיחשוב שוב.


עצמאות

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

כמות התלויות של מפתח או אפילו של צוות פיתוח כיום, גבוהה מאד.

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


פתרון בעיות באמצעות פיתוח בשפה ויזואלית נהירה לכל

פלטפורמה לפיתוח מהיר מאפשרת פיתוח בצורה ויזואלית וברורה. ולכן הלוגיקה העסקית נכתבת באופן ויזואלי. במקום Programming, פיתוח כזה נקרא Modeling. הדוגמה להלן מציגה פיתוח של משפט IF בקוד מול Low-Code:



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

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

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


זירוז ה “Time to Value” באמצעות סביבות ריצה מוכנות וסט כלים מלא

פלטפורמת פיתוח מהיר טובה, תספק יכולת Deployment קלה (One Click).

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

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

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

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


Reusability & Extensibility

פלטפורמות לפיתוח מהיר, מחוללי יישומים או ה (MDD (Model-Driven Development, אשר Mendix כיום בין מוביליו, אינם תפיסה חדשה, אולם בעבר הם נתקעו בעולם ה Client-Server, או שסבלו מבעיות ביצועים או שהיו מוגבלי יכולות, מה שמוביל לסקפטיות בין המפתחים הוותיקים.

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

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

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


שיפור הקשר בין צרכי הארגון לבין מערכות המידע

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

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

פלטפורמת Low-Code טובה, תסייע בתהליך יצירת האפליקציה (ALM-Application Life Cycle Management) משלב הגדרת הנדרש, תקשור ההתקדמות, דרך ניהול הפיתוח (ניהול הגרסאות ואפשור ריבוי מפתחים), דרך אפשרות משוב נוחה, בדיקות, העברה קלה, אך מנוהלת, בין הסביבות וכל זאת, בשקיפות בין כל השותפים.


המעורבות בשינוי

הטרנספורמציה הדיגיטלית, קורית.

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

הדרישה העצומה לתוצרי פיתוח מחייבת שינוי יסודי בדפוסי האספקה (Delivery) של יחידות ה IT.

כאשר השינוי מתגלגל קדימה, עדיף שהמפתחים יהיו המובילים. ומפתחים שאוהבים באמת טכנולוגיה מהמקום של הכוח שבעשיה, מבינים שתחום ה Low-Code הכרחי עבורם.


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