וייב קודינג - מה נשבר כשמגיעים משתמשים אמיתיים
מאת חן רז · פורסם:
האפליקציה עבדה. ראיתם אותה רצה על המסך, לחצתם על הכפתורים, הנתונים נשמרו, והכל התנהג בדיוק כמו שתכננתם. אחר כך העליתם אותה לאוויר ושלחתם קישור לכמה לקוחות. תוך ימים ספורים מישהו כותב לכם שהטופס לא נשלח, אתם נכנסים למערכת ומגלים שחלק מהרשומות פשוט לא שם, ואין לכם שום דרך לדעת מה קרה ומתי.
זה לא סימן שעשיתם משהו לא בסדר. זה הפער המוכר בין קוד שרץ על מחשב אחד לבין מערכת שמשרתת אנשים אמיתיים. הפער הזה קיים גם בפיתוח קלאסי, אבל וייב קודינג מקצר כל כך את הדרך אל הגרסה הראשונה שהוא גם מקרב אתכם אל הקיר הזה הרבה יותר מהר, ובלי שעברתם בדרך דרך כל השלבים שבדרך כלל מלמדים אתכם על קיומו.
הפוסט הזה עוסק בשכבה שנמצאת בין "זה עובד אצלי" לבין "זה שורד משתמשים": איפה המערכת רצה, מה קורה לנתונים, מי רואה שנשברה, ומי מתחזק אותה הלאה.
מה בעצם משתנה בין המחשב שלכם לבין העולם?
כשהאפליקציה רצה אצלכם, כמעט כל התנאים נוחים לה. משתמש אחד, רשת מקומית, אפס עומס, ואם משהו נתקע אתם פשוט מריצים מחדש. ברגע שהיא באוויר, כל אחד מהתנאים האלה מתהפך.
| מה שקורה אצלכם במחשב | מה שקורה מול משתמשים |
|---|---|
| משתמש אחד, פעולה אחת בכל רגע | כמה אנשים פועלים בו-זמנית על אותם נתונים |
| הקבצים והנתונים יושבים אצלכם ולא הולכים לשום מקום | הנתונים חיים בשרת שאפשר לאתחל, להחליף או למחוק |
| אם משהו נתקע, אתם רואים את זה מיד | התקלה קורית לגולש בשתיים בלילה ואף אחד לא מדווח |
| אתם מכירים את הקלט שאתם מזינים | אנשים מזינים דברים שלא חשבתם עליהם |
| אין תעבורה, אין עלויות, אין תוקפים | יש תעבורה, יש חשבונית חודשית, ויש סורקים אוטומטיים |
השורה התחתונה: הדגמה מוצלחת בודקת שהקוד יכול לעבוד. פרודקשן (production, סביבת הייצור) בודק שהוא ממשיך לעבוד גם כשהתנאים לא נוחים.
איפה האפליקציה רצה עכשיו, ואיזה אחסון אתרים היא בכלל צריכה?
השאלה הראשונה שאני שואל כשמגיעה אליי מערכת שנבנתה מהר היא פשוט "איפה זה רץ". התשובות הנפוצות הן "בענן של הכלי שבניתי איתו", "על איזה שרת שהוקם בהתחלה" ולעיתים "אני לא בטוח".
זה הבדל מהותי, כי לא כל אחסון אתרים מתאים לכל דבר:
- אחסון שיתופי (shared hosting) מתאים לאתר תוכן סטטי או לאתר וורדפרס קטן. אפליקציה שמריצה תהליך שרת משלה לרוב לא תרוץ שם כמו שצריך.
- שרת וירטואלי (VPS) נותן לכם שליטה מלאה, ואיתה גם את האחריות המלאה: עדכוני מערכת, הרשאות, חומת אש וניטור.
- פלטפורמת אירוח מנוהלת מקצרת הרבה מהעבודה הזאת, אבל מגלגלת אותה למחיר חודשי שגדל עם התעבורה, ולעיתים כובלת אתכם לספק אחד.
בנוסף לשאלת האחסון, יש כאן שלושה דברים שכמעט תמיד חסרים בפרויקט שנבנה מהר:
- הפרדה בין סביבות - סביבת פיתוח שבה מנסים דברים, סביבת בדיקות (staging) שנראית כמו האמיתית, וסביבת ייצור שהלקוחות רואים. בלי ההפרדה הזו כל ניסוי מתבצע ישירות מול המשתמשים.
- תהליך עלייה לאוויר מסודר (deployment) - דרך ברורה להעלות גרסה חדשה, לדעת איזו גרסה באוויר, ולחזור אחורה כשמשהו משתבש. אפשר לקרוא איך זה נראה כשעושים את זה נכון בעמוד על פריסה רציפה ואינטגרציה אוטומטית.
- דומיין ותעודת SSL תקינה - כולל חידוש אוטומטי. תעודה שפגה הופכת את האתר לחסום בדפדפן בתוך דקות.
למה מסד הנתונים מתאפס או מתמלא בזבל?
זה החלק שהכי כואב, כי נתונים אבודים לא חוזרים.
בהרבה פרויקטים שנבנים מהר, מסד הנתונים נולד כתופעת לוואי: המודל צריך איפה לשמור, אז הוא מייצר קובץ נתונים מקומי בתוך תיקיית האפליקציה. זה עובד מצוין עד הרגע שבו מעלים גרסה חדשה, והשרת מקים את האפליקציה מחדש מאפס. הקובץ נעלם, ואיתו הרשומות.
גם כשהחיבור למסד תקין, יש כמה דברים שכמעט אף פעם לא נעשים לבד:
- תכנון סכימה - אילו טבלאות, מה היחסים ביניהן, מה חובה ומה לא. בלי זה מקבלים בסיס נתונים שבו אותו לקוח מופיע בארבע גרסאות שונות ואי אפשר להוציא ממנו דוח אמין.
- אינדקסים - בלעדיהם שאילתה שרצה מיידית על חמישים רשומות לוקחת נצח על חמישים אלף.
- מיגרציות (migrations) - דרך מסודרת לשנות את מבנה הנתונים בלי למחוק את מה שכבר נצבר. בלעדיהן כל שינוי מבני הוא הימור.
- גיבוי אוטומטי ובדיקת שחזור - וזה שני דברים נפרדים. גיבוי שלא ניסיתם לשחזר ממנו הוא לא גיבוי, הוא תקווה.
אם המערכת שלכם מחזיקה נתוני לקוחות, זו הנקודה שבה כדאי לעצור ולבדוק, עוד לפני שמדברים על עיצוב או על פיצ'רים נוספים.
איפה שמורים המפתחות והסיסמאות של האפליקציה?
כל מערכת שמדברת עם משהו חיצוני מחזיקה סודות: סיסמת מסד הנתונים, מפתחות API של שירותי תשלום או דיוור, טוקנים של ספקים. בפיתוח מהיר הם נוטים להיכתב ישר לתוך הקוד, כי ככה הכי מהר לגרום לזה לעבוד.
הבעיה היא שקוד לא נשאר במקום. הוא נדחף למאגר קוד, נשלח למישהו שיעזור, מועתק לכלי חדש. כל אחת מהתחנות האלה היא הזדמנות לדליפה, וכשמפתח דולף אף אחד לא מודיע לכם על כך. אתם מגלים דרך חשבונית חריגה או דרך לקוח שמתלונן.
מה שצריך להיות שם במקום:
- משתני סביבה (environment variables) שמוגדרים בשרת עצמו ולא בקוד.
- קובץ סודות מוחרג ממאגר הקוד, עם קובץ דוגמה ריק שמתעד אילו מפתחות דרושים.
- הרשאות מינימליות לכל מפתח - מפתח שמיועד לקריאה לא צריך הרשאת מחיקה.
- יכולת להחליף מפתח בלי לפרק את המערכת, כי בסופו של דבר תצטרכו.
זו רק הקצה של נושא האבטחה, ויש לו גם היבטים משפטיים ורגולטוריים כשמדובר במידע על לקוחות. כאן אני נוגע בו רק מהצד התפעולי.
למה האתר מאט כשנכנסים עשרים אנשים בבת אחת?
שיפור מהירות אתר הוא בדרך כלל הדבר הראשון שמרגישים, כי הוא נראה לעין. הסיבות חוזרות על עצמן:
- שאילתות שרצות בלולאה - במקום שאילתה אחת שמביאה מאה רשומות, נשלחות מאה שאילתות נפרדות. על המחשב שלכם זה נעלם בתוך מילישניות, בשרת אמיתי זה נערם.
- אפס שכבת מטמון (cache) - כל בקשה מחשבת הכל מחדש, גם כשהתשובה זהה לזו שניתנה לפני שנייה.
- תמונות וקבצים במשקל מלא - נכסים שנשלחים בגודל המקורי במקום בגודל שנדרש למסך.
- תהליך שרת יחיד - בקשה אחת כבדה תוקעת את כל השאר בתור מאחוריה.
- עלות שמטפסת עם התעבורה - הרבה פלטפורמות אירוח מחייבות לפי שימוש, וקוד לא יעיל מתורגם ישירות לחשבונית.
מהירות היא לא רק נוחות. היא משפיעה על יחס ההמרה ועל הדירוג בגוגל, ולכן היא שיקול עסקי ולא רק טכני. פירטתי את הנושא בהרחבה בעמוד על שיפור ביצועים ומהירות גלישה.
איך תדעו בכלל שמשהו נשבר?
בהדגמה, אתם המשתמש והצופה בו-זמנית. בפרודקשן, רוב התקלות קורות כשאתם לא מסתכלים, ולרוב הגולש לא מדווח אלא פשוט עוזב.
המינימום שאני מצפה לראות בכל מערכת שמשרתת לקוחות:
- תיעוד שגיאות (logging) שנשמר במקום שאפשר לחפש בו, ולא רק נכתב למסך שנעלם עם ההפעלה מחדש.
- התראה על נפילה - הודעה במייל או בוואטסאפ כשהשירות לא עונה, במקום גילוי אחרי יומיים.
- בדיקת זמינות (uptime monitoring) שדוגמת את האתר כל כמה דקות ממקום חיצוני.
- טיפול מסודר בשגיאה מול המשתמש - מסך שמסביר מה קרה ומציע דרך המשך, במקום דף לבן.
בלי השכבה הזאת אין לכם מערכת בניהול, יש לכם מערכת בתקווה.
מי מתחזק קוד שלא כתבתם ולא קראתם?
זה החלק שהכי פחות מדברים עליו, והוא זה שנמשך הכי הרבה זמן. תחזוקת אתר או מערכת היא לא אירוע חד-פעמי אלא הוצאה מתמשכת, והיא מורכבת יותר כשהקוד נוצר במהירות:
- ספריות צד שלישי מתיישנות ודורשות עדכון, ולפעמים עדכון אבטחה דחוף.
- גרסאות שפה ותשתית משתנות, ומה שרץ היום יכול להפסיק לרוץ בעוד שנה.
- כל שינוי קטן דורש הבנה של מה שכבר קיים, וכשמבקשים מהמודל להוסיף פיצ'ר בלי שהוא רואה את כל התמונה, הוא לפעמים כותב שוב משהו שכבר קיים או שובר משהו אחר.
- אין בדיקות אוטומטיות, ולכן אין דרך לדעת שהשינוי האחרון לא הרס משהו שעבד.
- אין תיעוד, ולכן כל מפתח חיצוני שייגש לזה בעתיד יתחיל מקריאה ארוכה של קוד לא מוכר.
התוצאה המעשית: אתם הבעלים של מערכת שאתם לא יכולים לשנות בעצמכם, ולא יכולים גם להסביר למישהו אחר. זו לא בעיה טכנית, זו תלות עסקית.
למה דווקא קוד שנוצר בבינה מלאכותית נוטה לפספס את השכבה הזאת?
לא בגלל שהמודל לא יודע. אם תשאלו אותו ישירות על גיבויים או על אינדקסים, הוא יענה תשובה טובה. הפער נובע ממקום אחר:
- הוא עונה על מה שנשאל. הבקשה הייתה "תבנה לי מערכת שמנהלת הזמנות", לא "תבנה מערכת שתשרוד מאתיים משתמשים ותשמור על הנתונים גם אחרי עדכון".
- קוד רץ הוא יעד קל למדוד, קוד יציב הוא לא. הצלחה מיידית נמדדת במסך שעובד, ולכן זה מה שמקבלים.
- ההקשר מוגבל. כל שיחה רואה חלק מהמערכת, לא את השלם, ולכן החלטות רוחביות כמו מבנה נתונים או אסטרטגיית שגיאות לא נלקחות במקום אחד.
- אין לו צלקות תפעוליות. ההחלטות שמפתח מנוסה מקבל אוטומטית נובעות מדברים שנשברו לו בעבר, לא מהתיאוריה.
לכן זה לא מאבק בין "אנשים" ל"בינה מלאכותית". אני עצמי משתמש בכלי AI בעבודה יומיומית. ההבדל הוא מי מגדיר את הדרישות שמעבר לפיצ'ר, ומי אחראי כשמשהו נופל.
ומה עם פלטפורמות No-Code? זה לא בדיוק אותו סיפור?
לא, וזו הבחנה שכדאי לעשות מוקדם.
בפלטפורמת No-Code או Low-Code אתם בונים בתוך מערכת שמישהו אחר מתפעל. האחסון, מסד הנתונים, הגיבויים והעדכונים הם באחריות הספק. בתמורה אתם מוותרים על חלק מהשליטה ומשלמים דמי שימוש חודשיים. סקרתי את הפלטפורמות המרכזיות בפוסט על אפליקציות עסקיות וקוד מועט, והוא הפוסט הנכון לקרוא כשאתם עדיין בוחרים על מה לבנות.
וייב קודינג הוא סיפור אחר לגמרי. בסופו יש בידיכם קוד אמיתי שאתם הבעלים שלו, על תשתית שאתם שוכרים בעצמכם. זה גם היתרון הגדול, כי אין תקרה ואין תלות בספק, וגם המקור לכל מה שתואר למעלה: אין ספק שיגבה במקומכם, יעדכן במקומכם או יקבל טלפון כשזה נופל.
ההבדל בקצרה: הפוסט ההוא עוזר לבחור פלטפורמה. הפוסט הזה עוסק במה שקורה אחרי שהקוד כבר נכתב והוא שלכם.
מה עדיף, לתקן את מה שיש או לבנות מחדש?
זו שאלה כנה ולא תמיד התשובה נוחה. כלל האצבע שלי:
כדאי לשמר ולחזק כאשר:
- לוגיקת הליבה נכונה ומשקפת את התהליך העסקי האמיתי.
- מבנה הנתונים סביר גם אם צריך ניקוי.
- הבעיות מרוכזות בשכבה התפעולית: אחסון, גיבוי, ניטור, מהירות.
עדיף לבנות מחדש כאשר:
- אותם נתונים מפוזרים בכמה מקומות בלי מקור אמת אחד.
- אין דרך להוסיף פיצ'ר בלי לשבור שניים אחרים.
- הפער בין מה שהמערכת עושה למה שהעסק צריך רק גדל מאז שהיא נבנתה.
חשוב לומר: גם כשבונים מחדש, מה שנבנה לא הלך לפח. אב-טיפוס עובד הוא האפיון הכי מדויק שיש, והוא חוסך זמן רב בסבב השני. בפועל, כשמגיעים לבנייה מחדש כדאי לחשוב על התקציב כמו על כל פרויקט אחר, ועל זה כתבתי בנפרד בפוסט על איך קובעים תקציב לאתר.
רשימת בדיקה לפני שמכניסים משתמשים אמיתיים
עברו על זה לפני שאתם שולחים את הקישור החוצה:
- יש הפרדה בין סביבת ניסוי לסביבת ייצור.
- מסד הנתונים חי במקום קבוע ולא בתוך תיקיית האפליקציה.
- יש גיבוי אוטומטי, וניסיתם לשחזר ממנו לפחות פעם אחת.
- שום סיסמה או מפתח לא נמצא בתוך הקוד.
- יש דומיין עם תעודת SSL וחידוש אוטומטי.
- יש דרך לדעת שהמערכת נפלה בלי שלקוח יספר לכם.
- השגיאות נשמרות איפשהו שאפשר לחפש בו.
- בדקתם את המערכת עם יותר ממשתמש אחד בו-זמנית.
- יש דרך להעלות גרסה חדשה ולחזור אחורה אם היא בעייתית.
- אתם יודעים מה עולה החודש, ומה יקרה לחשבון אם התעבורה תוכפל.
אם סימנתם פחות משבע, יש עבודה לפני השקה. אם סימנתם פחות מארבע, כדאי לא לחכות לתקלה הראשונה.
שאלות ותשובות
אפשר להשאיר את זה כמו שזה ולטפל בבעיות כשהן מגיעות?
אפשר, ולפעמים זה אפילו סביר כשמדובר בכלי פנימי לשני עובדים. זה מפסיק להיות סביר ברגע שהמערכת מחזיקה נתוני לקוחות או כסף. אובדן נתונים ותקלה בשעת עומס הן בדיוק הבעיות שאי אפשר לתקן בדיעבד.
כמה זמן לוקח להכשיר מערכת כזאת לפרודקשן?
זה תלוי בעיקר במצב מסד הנתונים. כשהלוגיקה תקינה והבעיות תפעוליות, לרוב מדובר בכמה ימי עבודה מרוכזים על אחסון, גיבויים, סודות וניטור. כשצריך לתכנן מחדש את מבנה הנתונים ולהעביר אליו מידע קיים, זה כבר פרויקט בפני עצמו. אי אפשר להעריך את זה בלי להסתכל על הקוד ועל הנתונים.
אפשר פשוט לבקש מהמודל לתקן את כל זה?
חלקית. מודל טוב יוסיף לכם קובץ הגדרות סביבה, יכתוב מיגרציה ויציע ספריית לוגים, וזה שווה משהו. מה שהוא לא יעשה בשבילכם זה להחליט אילו נתונים קריטיים, מה מותר לאבד, כמה עומס אתם באמת צפויים לקבל, ומי מקבל את ההתראה בשתיים בלילה. אלה החלטות עסקיות, והן אלה שמכתיבות את הפתרון הטכני.
מה ההבדל בין אחסון אתרים רגיל לבין שרת לאפליקציה?
אחסון אתרים קלאסי מיועד להגיש דפים וקבצים. אפליקציה שנבנתה בקוד מריצה תהליך חי שמקבל בקשות, מדבר עם מסד נתונים ומחזיק מצב. היא צריכה סביבה שמאפשרת להריץ תהליך כזה, לנטר אותו ולהפעיל אותו מחדש אוטומטית כשהוא נופל. זו הסיבה שהעלאה של אפליקציה לאחסון שיתופי זול לרוב פשוט לא עובדת.
מה עושים קודם אם התקציב מוגבל?
לפי הסדר: גיבוי שנבדק, הוצאת סודות מהקוד, והתראה על נפילה. שלושת אלה מונעים את הנזקים שאי אפשר להחזיר. מהירות, עיצוב ופיצ'רים נוספים יכולים לחכות לסבב הבא.
סיכום
וייב קודינג מביא אתכם לגרסה ראשונה עובדת מהר מאי פעם, וזה יתרון אמיתי. מה שהוא לא מביא איתו זו השכבה שהופכת גרסה עובדת למערכת שאפשר לסמוך עליה: אחסון מתאים, מסד נתונים מתוכנן עם גיבויים, סודות מחוץ לקוד, ביצועים תחת עומס, ניטור שמספר לכם מה קרה, ותוכנית תחזוקה להמשך.
הפער הזה ניתן לסגירה, והוא כמעט תמיד זול יותר לפני שהגיעו הלקוחות מאשר אחרי.
יש לכם מערכת שכבר עובדת חלקית ואתם לא בטוחים אם היא מוכנה למשתמשים? שלחו לי קישור ותיאור קצר של מה שהיא עושה, ואחזור אליכם עם רשימה ממוקדת: מה חייב טיפול לפני השקה, מה יכול לחכות, ומה עדיף לבנות מחדש. אם תרצו שגם אקח את זה לקו הסיום, אני עובד ישירות מול הלקוחות בלי סוכנות ובלי מתווכים, ואפשר לראות איך זה נראה בעמוד בניית אתרים ומערכות.
צרו קשר ונתחיל מהמפה, לא מהקוד.