לתכנן ביחד, ואז להוכיח
טסטים שעוברים ודיפלוי נקי לא אומרים ששינוי באמת עובד. מסרתי לקלוד שינוי הרשאות וגרמתי לו להוכיח את עצמו מול נתונים אמיתיים, מבחוץ פנימה, לפני שסמכתי עליו.
השבוע עשיתי שינוי הרשאות עם קלוד. הטסטים עברו והוא עלה ל-staging.
זה אומר לי שהקוד רץ. זה לא אומר לי שהוא עושה את מה שהתכוונתי. כדי לסמוך עליו, וכדי באמת לדעת שהוא עובד, מאמתים אותו. את החלק הזה אני רוצה להראות.
קלוד, במילים שלו
נתונים אמיתיים, לא רשומה מומצאת. לא המצאתי רשומת בדיקה נקייה. לקחתי מסמך שכבר היה ב-staging — כזה שהעליתי קודם כשבדקתי שההעלאה עובדת. נתונים אמיתיים שעוברים בזרימה האמיתית, לא שורה שהמצאתי כדי שהבדיקה שלי תעבור.
כל נקודת גישה, לא רק המובנת מאליה. לקובץ אפשר להגיע משתי דרכים: endpoint אחד שמחזיר אותו ברשימה, ואחד אחר שמגיש את הבייטים עצמם. שניהם השתנו בקוד, אבל אלה שני נתיבים נפרדים — ומסך שמסתיר את הרשימה בזמן שההורדה עדיין פתוחה זו דליפה לכל דבר. בדקתי כל אחד בנפרד.
ההוכחה היא בפער: אותה בקשה, זהות אחרת. הרצתי את אותה בקשה בדיוק, ושיניתי רק מי ששואל. זר שבידו רק הלינק קיבל רשימה ריקה, ו-unservable יבש על ההורדה. מי שמשויך לחשבון קיבל את כל הקבצים. אותה בקשה, אדם אחר, תשובה אחרת.
לפנות ישר לשרת, מתחת למסך. פניתי ל-backend בלי שום אפליקציה באמצע, כי ככה מישהו באמת היה ניגש לזה. השרת הוא זה שמחליט מי מקבל את הקובץ, אז לשם כיוונתי. מסך ירוק רק מראה לך שה-happy path נראה תקין, וזהו.
לאמת גם את ה”לא” וגם את ה”כן”. בדקתי את שני הכיוונים: חסום למי שלא אמור לגשת, ועדיין עובד למי שכן. שינוי הרשאות שנועל את כולם בחוץ עובר את בדיקת האבטחה בגדול — ובשקט הורג את הפיצ’ר.
להריץ את הטוגל הלוך וחזור, ואז להחזיר הכול למקום. השינוי יצא עם opt-out — בעלים יכול להחזיר את המקורות להיות ציבוריים. הדלקתי אותו דרך המסך האמיתי, ראיתי את שני ה-endpoints נפתחים שוב לזר, כיביתי, ראיתי את שניהם נסגרים, ואז החזרתי את הרשומה בדיוק איך שמצאתי אותה.
שהבדיקה עצמה לא תהפוך לדליפה. כדי לבדוק את המקרה של משתמש מחובר הייתי צריכה סשן חי, אז את הקריאה הזאת הרצתי בתוך הדפדפן — הטוקן לא יצא מהדף לרגע, ושמרתי רק את התוצאה.
לעגן כל “עבר” בפלט שאפשר לקרוא בעיניים. כלום פה לא היה “אמור לעבוד”. כל שורה הייתה משהו שאני יכולה להצביע עליו: רשימה ריקה, המילה unservable, ארבעה שמות קבצים, ok.
למה כל המסלול הזה הוא העבודה
זה היה עיצוב הרשאות חדש, לא תיקון באג. מה ששובר דבר כזה זה חוסר-עקביות: יותר מנתיב אחד מגיע לאותו קובץ, והנתיבים מפסיקים להסכים ביניהם על מי מורשה. אז השאלה היא לא אם הפיצ’ר עבד פעם אחת, אלא אם כל נתיב וכל זהות נוחתים על אותו כלל, כל פעם מחדש.
כל צעד למעלה הוא סירוב להסתפק בפחות. רשומה מומצאת, כשנתונים אמיתיים יושבים ממש שם. endpoint אחד, כשעוד אחד מגיש את אותו קובץ בדיוק. תוצאה ירוקה אחת, כשההוכחה האמיתית מתגלה רק בפער בין שתי זהויות. המסך, כשבעצם השרת הוא זה שמחליט.
למה אני יכולה לתת לו לעבוד שעות
בכל פרויקט, כל פיצ’ר, כל פיסת עבודה, אני דואגת שלקלוד תהיה דרך לאמת את עצמו. אז ברגע שחשבנו על זה ביחד, תכננו, והחלטנו מה בונים — אני יכולה לסמוך על התהליך ולתת לו לרוץ שעות.