יסודות: איך הבנאי חושב

התכנון שמדלגים עליו הוא התקלה שמתקנים אחר כך

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

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

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

איפה זה באמת משתלם

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

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

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

היכן שיש טעם בביקורת

שום דבר מזה לא חינם, ואני לא אעמיד פנים שכן. סביבות עבודה מבודדות לכל הרצה משמעותן שקובצי הידע שלך מועתקים מחדש, שום דבר לא חוזר למחשב שלך — טוב עבורך אם המחשב הנייד שלך קורס באמצע בנייה, רע מבחינת זמן תגובה, כי הקצאת סביבת עבודה, ועבור בניות מבוססות פריימוורק, הרצה של התקנת תלויות אמיתית בתוך גבול קונטיינר, לוקחת זמן אמיתי. גבול הקונטיינר הזה קיים כי בנייה מבוססת פריימוורק מריצה `npm install` וסקריפטי בנייה שרירותיים — קוד שלא כתבת, שמופעל בהרשאות זמן-בנייה — ולעשות זאת על שרת משותף ללא בידוד זה התקפת dependency-confusion אחת מרחק מלגעת בנתונים של דייר אחר. אפשרות מהירה ולא בטוחה הייתה קיימת. היא פשוט לא הייתה עסקה ששווה לעשות.

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

• בדיקת קוד
• אבטחה
• קישורים ו-SEO
• נגישות
• התאמה לתוכנית
• הרצה בפועל בדפדפן

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