מהו Low code ואיך בונים בעזרתו תוכנה
Low code, או פיתוח במעט קוד, הוא גישה לבניית תוכנה באמצעות מסכים חזותיים, רכיבים מוכנים ותהליכי עבודה מוגדרים. במקום לכתוב כל רכיב מאפס, מרכיבים חלקים קיימים ומוסיפים קוד כשנדרשת התאמה שהכלי החזותי אינו מספק. זו ההגדרה שמציגה IBM בהסבר על הגישה.
למשל, אפשר להרכיב טופס להזנת בקשה, לחבר אותו למאגר נתונים ולהגדיר מה יקרה לאחר השליחה. התאמה מיוחדת, כמו חישוב עסקי מורכב או חיבור למערכת שאינה נתמכת ישירות, עשויה לדרוש עבודת פיתוח נוספת.
לפי IBM, הגישה משמשת בין היתר לסוגי הפתרונות האלה:
- יישומים עסקיים ואוטומציה של תהליכי עבודה
- מידול ואוטומציה של תהליכים עסקיים (BPM)
- אפליקציות ללקוחות ואפליקציות לנייד
- ממשקי API ושילוב נתונים
- לוחות מחוונים לניתוח נתונים
- יישומים מבוססי מסד נתונים
IBM מתארת שתי קבוצות משתמשים. הראשונה היא אנשי עסק עם ניסיון מועט בקוד, כמו אנליסטים ומנהלי פרויקטים, שמכונים "מפתחים אזרחיים" (citizen developers). השנייה היא מפתחים מקצועיים, שמשתמשים בכלים כדי לחסוך כתיבה של קוד שחוזר על עצמו ולהקדיש את המאמץ ל"המייל האחרון" של הפיתוח.
היקף העבודה שאפשר לבצע בלי מתכנת תלוי בפלטפורמה ובדרישות היישום. המונח עצמו אינו מבטיח שאפשר להשלים כל פרויקט ללא ידע בתכנות.
| מאפיין | המשמעות |
|---|---|
| בנייה חזותית | הרכבת מסכים ותהליכים באמצעות רכיבים מוכנים |
| הרחבה בקוד | הוספת התאמות מעבר לאפשרויות הבנייה החזותיות |
| פיתוח ללא קוד | בניית הפתרון באמצעות הכלים החזותיים שמספקת הפלטפורמה |
| חפיפה בין הקטגוריות | צריך לבדוק את יכולות הכלי בפועל, מעבר להגדרה השיווקית |
מקור: IBM: ההבדלים בין פיתוח במעט קוד לפיתוח ללא קוד
ההבדל מפיתוח ללא קוד ומיצירת קוד בבינה מלאכותית
בפיתוח ללא קוד, המכונה No code, בונים את הפתרון באמצעות האפשרויות החזותיות שהמערכת מציעה. בפיתוח במעט קוד קיימת גם אפשרות להרחיב את הפתרון באמצעות קוד. לפי ההשוואה של IBM, יש חפיפה בין הקטגוריות, ולכן צריך לבחון את יכולות הכלי בפועל.
IBM מציבה את ההבדלים כך: Low code מיועד בעיקר למפתחים מקצועיים, והמערכת פתוחה להרחבה בתוספים ובמחברים מותאמים. No code מיועד לאנשי עסק עם ידע מועט בתכנות או בלעדיו, והמערכת סגורה יותר ומורחבת רק דרך יכולות מובנות. IBM מציינת גם שספקים מטשטשים לעיתים את הגבול, ושמתייחסים ל־No code לא פעם כתת־קבוצה של Low code.
לפי IBM, No code מתאים יותר ליישומים פשוטים, ללוחות מחוונים, לכלים פנימיים ולדוחות. Low code מתאים יותר ליישומים מורכבים, לשילוב בין מערכות ולמערכות קריטיות לעסק. אם התהליך שלכם מתאים כולו לרכיבים מוכנים, ייתכן שתוכלו להסתפק בפתרון ללא קוד. המאמר על בניית אפליקציות ותהליכים ללא קוד מרחיב על הגישה הזאת.
בינה מלאכותית היא יכולת נפרדת שיכולה להשתלב בסביבת הפיתוח. לדוגמה, התיעוד של Power Apps מתאר יצירת יישום מתיאור בשפה טבעית לצד אפשרויות עריכה והרחבה בקוד. עצם האפשרות לבקש תוכנה בשיחה אינה מספיקה כדי להבין כיצד מתחזקים אותה או מה אפשר לשנות בה בהמשך.
IBM מזהירה בהקשר הזה מפני vibe coding, כלומר יצירת קוד בלי הבנה של יסודות התכנות, ומציינת שהוא כרוך בסיכונים ביישומים ארגוניים. על ההבדל בין אבטיפוס למוצר אפשר לקרוא במאמר על vibe coding ובניית תוכנה בשיחה.
מה הגישה נותנת ואילו מגבלות יש לה
לפי IBM, היתרונות העיקריים הם אספקה מהירה יותר של יישומים, פחות תלות במומחים נדירים בשפות תכנות מסוימות, ואפשרות לאנשים שאינם מתכנתים להשתתף בבנייה. מפתחים מנוסים יכולים גם להספיק יותר, כי חלק מהקוד החוזר נוצר עבורם.
מנגד, IBM מציינת כמה מגבלות:
- שליטה מול מהירות: פלטפורמות חזותיות מסורתיות מחליפות חלק מהשליטה במהירות, וזה עלול להגביל התאמות.
- תלות בספק: רכיבים שמיוחדים לפלטפורמה מקשים על מעבר לספק אחר.
- למידה ובדיקה חוזרת: Low code דורש יותר הכשרה מ־No code, וקוד מותאם צריך לעבור בדיקה חוזרת כשהפלטפורמה משודרגת.
- Shadow IT: כלים שעובדים בלי פיקוח של גורם טכנולוגי בארגון עלולים ליצור תשתית בלתי מנוטרת עם סיכוני אבטחה.
לכן כדאי לשאול כבר בתחילת הדרך מי אחראי על היישום אחרי שהוא עולה לאוויר, ומה יקרה אם תרצו לעבור לכלי אחר.
אילו תהליכים בעסק מתאימים לבדיקה
נקודת פתיחה שימושית היא תהליך שבו ברור איזה מידע נכנס, מי מטפל בו ומה צריך לקרות בכל שלב. יישומים לניהול בקשות, תהליכי אישור וכלים פנימיים הם דוגמאות לסוגי פתרונות הנכללים בשימושים שמתארת IBM בפיתוח במעט קוד.
נניח שעסק מקבל בקשות שירות בדואר אלקטרוני ומעתיק אותן ידנית לטבלה. פתרון אפשרי יהיה טופס קליטה, רשימת בקשות ומסך לעדכון מצב הטיפול. זו דוגמה היפותטית: לפני בחירת כלי צריך לבדוק שהוא תומך בנתונים, בהרשאות ובפעולות הנדרשות.
אם כבר יש לכם מערכת מתאימה וחסרה רק העברת מידע בין שלבים, הגדירו קודם את הפעולה שחוזרת על עצמה. המאמר על משימות שאפשר להעביר לטיפול אוטומטי יכול לעזור לנסח את הצורך לפני שמחליטים לבנות יישום נוסף.
כדאי לרשום לפני הבחירה: אילו שדות נאספים, מי רשאי לראות ולערוך אותם, לאילו מערכות הנתונים צריכים להגיע ומי מאשר שינויים בתהליך. רשימה כזאת מקצרת את ההשוואה בין כלים, כי אפשר לבדוק כל כלי מול אותן דרישות.
מה נשאר לבדוק גם כשכותבים מעט קוד
החיבור למידע דורש בדיקה פרטנית. בתיעוד המחברים של Power Apps מוסבר שמחבר עשוי לספק טבלאות נתונים, פעולות או את שתיהן. לכן הופעת שם המערכת ברשימת החיבורים אינה מספיקה: בדקו שהחיבור מאפשר בדיוק את הקריאה או העדכון שאתם צריכים. התיעוד מפרט את ההבדלים בין סוגי המחברים.
התיעוד מוסיף כמה פרטים מעשיים. מחברים רגילים (standard) אינם דורשים רישוי מיוחד, ואילו מחברים אחרים עשויים לדרוש. מומלץ להגביל יישום לא יותר מ־10 מחברים ו־20 הפניות לחיבורים, כי חריגה עלולה להאט את הטעינה ולגרום לבעיות בשמירה. בנוסף, חיבורים משותפים שנוצרו אחרי ינואר 2024 מאובטחים כברירת מחדל, אבל יישומים ישנים צריך לפרסם מחדש כדי ליהנות מכך.
גם יישום שנבנה חזותית דורש ניהול שינויים ותחזוקה. התיעוד של Microsoft לניהול מחזור חיי יישומים כולל בדיקות, הרשאות גישה, אבטחת נתונים, מעקב שינויים וחזרה לגרסה קודמת. לפי התיעוד, בקרת גרסאות היא מקור האמת לרכיבי היישום, ומערכות אוטומטיות לבנייה ולפריסה יכולות לשמש להעברה בין סביבות. הקלות שבה מרכיבים מסך אינה מעידה שהיישום מוכן לשימוש עסקי. המסגרת לניהול מחזור חיי היישום מבהירה אילו תחומי אחריות נשארים לאורך הדרך.
הרישוי נבדק לפני ההתחייבות. לפי סקירת Power Apps, אפשר לבנות יישומים בחינם בסביבת פיתוח, אבל נדרש רישיון כדי להפעיל את היישומים שנבנו. מחירים ותנאים משתנים, ולכן בדקו אותם באתר היצרן לפני רכישה.
לפני התחייבות, בקשו הדגמה של התהליך שלכם עם נתוני דמה. בדקו מה קורה כשחסר שדה, כשהחיבור נכשל וכשמשתמש מנסה לבצע פעולה שאינה בסמכותו. בקשו גם פירוט של הרישוי הנדרש, דרך הוצאת הנתונים וזהות האדם שיטפל בתקלות ובשינויים. אלה שאלות לבירור מול הספק, והתשובות משתנות בין כלים ופתרונות.
