מ-MVP לפרודקשיין. טיפים לקוד קלוד טור #17 מאת אלכס
הי חברים יקרים 😍 כמו בכל שבוע, מה שתקראו פה בא מהניסיון שלי ורק מהניסיון שלי. ברשת יש אינספור "תעשה ככה וככה", אבל אני כותב אחרי בערך שנה של עבודה עם קלוד קוד וכמה פרויקטים מעניינים שבניתי איתו. אז בטור שעבר סוף סוף סגרתי את החוב ודיברנו על GuardRails. היו שם שני דברים: רשימת deny בקובץ settings.json , שחוסמת פקודות כמו מחיקת היסטוריה ב GIT או מחיקת קבצים פיזית מהמחשב ו-Hook מסוג PreToolUse שבודק כל פקודה לפני שהיא רצה, כמו סלקטור בכניסה למועדון. וגם הדגשתי שמעקה בטיחות הוא לא תחליף לגיבוי. והיום? היום מדברים על... (פם פם... 🔔) הרגע שבו הצעצוע צריך להפוך למוצר. או בשפה המקצועית: מ-MVP לפרודקשיין. נושא שאני מודה שגם מעסיק את עצמי ודיסקליימר חשוב אני נתקל באותה בעיה בדיוק. עצם זה שאני מעלה את הנושא לא הופך אותי לגורו , אבל אני רושם מתוך נקודת המבט שלי. יש לי כמה מוצרים בשלב ה MVP
וגם לי יש את ה To-Do להפוך אותם למוצר סקיילבילי ומוצר שיכול להתפתח יחסית מהר בפיצ'רים .
והפעם בכוונה זה לא טור טכני. יותר טור של מחשבות וטיפים, ושל המקומות שבהם בדרך כלל נופלים במעבר הזה... עם קצת הומור גיקי, כי בלי זה מה הטעם 😄
רגע, מה זה MVP ומה זה פרודקשיין?
MVP זה קיצור של Minimum Viable Product. במילים פשוטות: הגרסה הכי קטנה של הרעיון שעדיין עובדת, ומספיקה כדי לבדוק אם הוא שווה משהו. סוג של אבטיפוס!
פרודקשן (Production) זה כשהמוצר רץ "באמת". אנשים אמיתיים משתמשים בו, הדאטה אמיתי, ואם משהו נשבר מישהו מרגיש את זה.
אני אוהב לחשוב על זה במונחים של המשחקים מפעם. ה-MVP הוא הדמו (שוב סוג של פרומו.. ) , השלב האחד ששיחקנו בו שוב ושוב. פרודקשן זה המשחק המלא בקופסה, שאנשים קנו ומצפים שלא יקרוס להם באמצע השלב השביעי.
ומכאן הפילוסופיה הקטנה שלי לטור הזה:
MVP שואל: "האם זה עובד?"
פרודקשיין שואל: "מה קורה כשזה לא עובד?"
כל הטור הזה הוא בעצם על השאלה השנייה.
נפילה ראשונה שקרתה לי : "אבל אצלי זה עובד!"
בתור בודק תוכנה, זה אולי המשפט הכי מפורסם בעולם שלנו חח
ב-MVP בודקים בעיקר את "המסלול הרגיל והפשוט " (Happy Path): המשתמש מכניס בדיוק מה שציפינו, האינטרנט עובד והשירות החיצוני עונה. בפרודקשן המציאות פחות נחמדה. יש שדות ריקים, קלט מוזר, API שלא עונה, ושתי פעולות שקורות באותה שנייה.
והחדשות הטובות: קלוד מעולה בלחשוב על מה יכול להישבר. פשוט תבקשו:
Act as a QA engineer. List the edge cases and failure scenarios this project doesn't handle yet
במילים אחרות: תחשוב כמו בודק תוכנה QA , ותגיד לי מה עלול להישבר, מהמסוכן ביותר והלאה.
ואחרי שיש רשימה וטסטים , אפשר לתת להם לרוץ כל לילה, כמו שדיברנו בטור #7 על Routines (הפעלת בדיקות וריפקציות על PR או על חלקים מסויימים בקוד.. )
נפילה שנייה: אף אחד לא מספר לכם שזה נפל
ב-MVP אתם יושבים מול המסך ורואים כל שגיאה בזמן אמת. בפרודקשן? אתם ישנים, בעבודה או בחתונה של בן דוד, והתהליך נופל בשלוש בלילה בשקט מוחלט...ואז מה עושים?
לחץץ... פה נכנסים ה-Powerups מטור #4: Resend שישלח מייל כשמשהו נכשל, או Green API שישלח ווצאפ. אצלי, כמו שסיפרתי שם, תהליך ה-Scraping הלילי לאתר הרטרו שולח לי מייל בכל פעם שהוא נכשל. עצם זה שנדווח זה כבר המון מהפתרון..כי איך נדע אם ..לא נדע :) תודו שלא חשבתם על המשפט הזה חח
בקיצור: כלל אצבע פשוט: אם משהו רץ בלי שאתם מסתכלים עליו, הוא חייב לדעת לצעוק.
נפילה שלישית: הדאטה (שזה תכלס הכל !! )
זה המקום שבו MVP נשבר הכי מהר, ובצורה הכי מביכה.
נזכיר בקצרה את הסיפור מטור #6. פרויקט הווצאפ שלי התחיל ב-Airtable, שהוא כלי מעולה ל-MVP. אבל כל הכללים נאכפו רק בקוד, בשיטת "בדוק ואז כתוב". אם שתי ריצות מתנגשות באותה שנייה, שתיהן בודקות, שתיהן רואות ש"עוד לא נשלח", ושתיהן שולחות. המנוי מקבל את אותה הודעה פעמיים 😬 וזה עוד סצנריו קליל....
עם 10 אנשים זאת בעיה קטנה. כשהתוכנית היא להגיע לאלפים, זאת כבר בעיה אחרת לגמרי. בגלל זה עברתי ל-PostgreSQL, ושם כלל כזה הופך לאילוץ ייחודיות בתוך מסד הנתונים עצמו. המסד פשוט לא מאפשר לרשום את אותה שליחה פעמיים.
הטיפ שלי: לפני שעולים לאוויר, תשאלו את קלוד אילו כללים "חיים רק בקוד" ואפשר להעביר אותם אל מסד הנתונים.
עוד טיפ חשוב: לבדוק את איכות הדאטה.. לראות שאין חוסרים , לראות שהדאטה יושב בצורה מאורגנת ומסודרת ב- DB , לוודא אם איש DBA אם שום דבר לא פוספס.. והדאטה לא רק שיושב טוב אלא גם אפשר לטייב אותו אם צריך, יש גיבויים , יש נהלים מסודרים כגון: Switch Over או Fail over (איש הדאטהבייס שהגדיר לכם ה- DB יבין על מה מדובר.. )
נפילה רביעית: סודות בתוך הקוד
ב-MVP זה כל כך מפתה... זורקים את ה-API Key ישר בקוד, "רק לבדיקה". ואז שוכחים. ואז עושים Push.
דיברתי על זה כבר כמה פעמים (טורים #9, #10 ו-#11), אבל במעבר לפרודקשן זאת כבר לא המלצה, זאת חובה. מה זה אומר בפועל?
מפתחות וסיסמאות עוברים למשתני סביבה (Environment Variables).
הקובץ .env שמחזיק אותם נכנס ל-.gitignore ולא עובר ל GIT! סופר חשוב.אני לא רוצה אפילו לומר כמה פעמים אנשים נפלו בזה...
אם מפתח כבר נדחף פעם ל-Repo, לא מספיק למחוק אותו מהקוד, כי הוא עדיין יושב בהיסטוריה של Git. מחליפים אותו במפתח חדש וזהו. מה שנקרא ROTATE בעגה המקצועית.
ואפשר כמובן לתת לקלוד לעשות את הסריקה:
Scan the project for hardcoded API keys, passwords or tokens, and move them to environment variables
נפילה חמישית: הכלים שהיו מושלמים ל-MVP
הרבה כלים מעולים לשלב האבטיפוס ופחות מתאימים לשלב שבו יש אנשים אמיתיים על הקו. זה לא כי הם רעים, אלא כי הם נבנו בשביל משהו אחר.
כמה דוגמאות מטורים קודמים:
Green API הוא כלי לא רשמי. הוא מעולה לשלוח לעצמי או לכמה חברים, אבל כבר בטור #4 אמרתי שלשליחה בהיקף גדול עדיף ה-API הרשמי של Meta, שנבנה ל-Scale ולאבטחה. ובטח שמעתם שאתמול השרתים של GREEN API נפלו ??
מודלים חינמיים כיפיים לניסויים, אבל לא הייתי שולח אליהם קוד סודי או מידע של משתמשים.
תוכניות חינמיות עם מגבלה על קריאות או משתמשים, שמספיקות לגמרי. עד שהן לא.
אז לפני שעולים, שווה לעבור על כל רכיב ולשאול: הוא נבנה בשביל מה שאני עומד לעשות איתו?
נפילה שישית: "השרת? הוא פשוט רץ..."
אם הפרויקט עולה ל-VPS (טור #15), זכרו שזה השרת שלכם, ולכן גם האחריות שלכם: עדכונים, גיבויים ואבטחה. במיוחד כשיש עליו דאטה של אנשים אמיתיים.
וגם הקלאסיקה: תהליך שהורץ סתם ככה בחלון SSH, החלון נסגר, ו... התהליך מת יחד איתו. בפרודקשן תהליך כזה צריך לרוץ כשירות (service), שגם יעלה מחדש לבד אם השרת עושה ריסטארט. ואם זה נשמע לכם כמו סינית, אל תתרגשו... קלוד מכיר את זה מעולה ויכול להגדיר תהליכים שירוץ באופן חלק יותר בשרת.
נפילה שביעית: Main זה כבר לא ארגז חול
ב-MVP אפשר לפעמים לעשות Commit ישר ל-Main בלי לחשוב פעמיים. בפרודקשן, Main הוא מה שהמשתמשים מקבלים.
אז כאן נכנס כל מה שדיברנו עליו בטורים #3 ו-#11: עובדים ב-Branch, פותחים PR, עושים Review, ורק אז Merge. ומעל כל זה ה-GuardRails מהשבוע שעבר, כדי ש-git push --force לא יקרה "בטעות" כלומר למנוע דריסה של קוד של יוזרים ושחזור של מצב קודם הרבה יותר מסובך עד כדי בלתי אפשרי .
ובונוס קטן: קובץ ה-PR_Change_Log מטור #3. בעוד שלושה חודשים, כשמשהו נשבר בפרודקשן, תודו לעצמכם שיש תיעוד של מה השתנה ומתי.
אז כמה רחוק ללכת?
וחשוב לי לאזן את כל זה, כדי שלא תצאו מפה עם רשימת מטלות של חצי שנה.
המטרה של MVP היא ללמוד מהר אם הרעיון בכלל שווה. לבנות פרודקשן מושלם לרעיון שעוד לא נבדק זה כמו להדפיס קופסה מפוארת למשחק שעוד לא כתבתם.
אז אותו עיקרון כמו ב-GuardRails: מתחילים קטן, ומרחיבים כשיש סיבה. MVP שהוכיח את עצמו? מעולה. עכשיו עוברים על הנפילות האלה אחת אחת.
💡 הטיפ שלי: תשאלו את השותף לפשע
בטור #2 סיפרתי שמדי פעם אני מבקש מקלוד להפסיק לפרגן ולהיות כן עד הסוף. אין רגע מתאים לזה יותר מהרגע שלפני שעולים לאוויר:
Be brutally honest: is this project ready for production? What would break first with real users, and what must be fixed before launch?
במילים אחרות: בלי לייפות, האם זה מוכן? מה יישבר ראשון כשיגיעו משתמשים אמיתיים, ומה חייב להיות מתוקן לפני ההשקה??
התשובה לא תמיד נעימה לשמוע נו טוב..אף פעם לא נעימה לשמיעה... . אבל עדיף לשמוע אותה ממנו עכשיו מאשר מהמשתמשים אחר כך.
השורה התחתונה:
ה-MVP מוכיח שהרעיון חי. הפרודקשן מוכיח שהוא שורד את העולם האמיתי.
והמעבר בין השניים הוא לא קסם. הוא בעיקר הרגל לשאול כל הזמן: "ומה קורה כשזה לא עובד?"
ומשהו אחרון: אל תתביישו ב-MVP שלכם. הוא לא אמור להיות יפה, הוא אמור לענות על שאלה. את השאר בונים אחר כך, צעד אחרי צעד, ביחד עם חברנו היקר קלוד.
זהו להפעם! מי שיש לו שאלות מוזמן לשאול בשרשור ואשמח לענות. ומי שכבר העלה MVP לפרודקשן, אשמח לשמוע איפה אתם נפלתם (כולנו נפלנו איפשהו...).
באהבה, אלכס! 🥰
נ.ב. נזכרתי בהמון חברות סטאראפ מקובל להקים סביבת אינטגרציה שהיא תואמת פרודקשיין ועליו אפשר לשים פיתוחים חדשים , ובמידה הפיתוחים נבדקו ועברו בהצלחה
כלומר עברו את הבדיקות המתאימות ובמקים מסויימים גם Stress Test ו Code Review ובדיקות אפליקטיביים , ורק אז אפשר לעדכן את ה Repo (או הגיטלאב) של הפרודקשיין . אז זהו..מקווה שנהניתם מהטיפים...
קצת עליי: קוראים לי אלכס גולדבלט, במקצוע שלי אני בודק תוכנה בחברה גדולה ואחד התחביבים שלי הוא מחשבי וינטאג' 8 ביט. אתם יכולים לבקר אותי כאן: