יסודות: קריאת רשומת האימות של בנייה

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

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

בגלילה למטה, התיעוד מתפצל לשש שורות:

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

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

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

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

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

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

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

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