سه هفته پیش یک ابزارک رزرو برای دوستی که استودیوی یوگا اداره میکند ساختم — یک گفتگو، برنامهای که چون وسط کار دیگری بودم سریع تأیید کردم، یک اجرا، و بعد یک کارت نسخه با علامت تیک سبزی که نگاهی سرسری انداختم و رد شدم. سهشنبه او پیام داد و پرسید آیا میتواند سایت استودیوی دومی را هم به همان ساخت وصل کند. قبل از اینکه بگویم بله، برگشتم تا ببینم «تأییدشده» سه هفته پیش واقعاً به چه معنا بود، و آنجا بود که برای اولین بار یکی از این سوابق را واقعاً خواندم، نه اینکه فقط به تیک اعتماد کنم.
درست روی کارت نسخه قرار دارد، کنار پیشنمایش و اقدامات کد — همان جایی که برای استقرار مجدد یا بازگشت میروید. اولین چیزی که متوجه شدم: این محدود به همان یک نسخه است، نه کل گفتگو. من پنج بار روی این ساخت تکرار کرده بودم تا یک انتخابگر تاریخ خراب را رفع کنم، و نیمی از انتظارم این بود که سابقه داستان کل رفتوبرگشت را برایم تعریف کند. اینطور نیست. سابقهی نسخهی ۴ فقط نسخهی ۴ را توصیف میکند. هیچ خاطرهای از این ندارد که نسخهی ۲ با فرم ورودی که بیصدا شکست میخورد ارسال شده، و به من نمیگوید نسخهی ۵ آرام چیزی را که نسخهی ۳ خراب کرده بود اصلاح کرده. هر سابقه یک عکس لحظهای است، نه یک تفاوت و نه یک تاریخچهی تغییرات — اگر بخواهم تاریخچهی تغییرات از یک نسخه به نسخهی دیگر را ببینم، آن یک نمای کاملاً متفاوت است. این یکی فقط به «آیا این یکی خوب است» پاسخ میدهد.
با پایین رفتن، سابقه به شش ردیف تقسیم میشود:
| لایه | معنای عبور کردن |
|---|---|
| کارکردی / در مرورگر | ساخت در یک مرورگر واقعی اجرا شد؛ تعاملها آزمایش شدند (بازیها بازی میشوند) |
| بازبینی کد | یک بازبین فقطخواندنی هیچ نقصی که بتواند با یک فایل و رفتار مشخص اثبات کند پیدا نکرد |
| امنیت | هیچ سطح تزریق، رمز افشاشده یا الگوی ناامنی مشاهده نشد |
| لینکها و سئو | هیچ لینک شکستهای وجود ندارد؛ فراداده، robots و نقشهی سایت مرتباند |
| دسترسپذیری | اجرای خودکار axe هیچ نقض قانونی پیدا نکرد |
| انطباق | ساخت شامل همان چیزی است که برنامهی تأییدشده وعده داده بود |
هر شش مورد سبز بودند، و اولین واکنشم همان واکنش اشتباهی بود که حدس میزنم بیشتر مردم دارند: امنیت عبور کرد پس امن است؛ دسترسپذیری عبور کرد پس دسترسپذیر است. هیچکدام از این خوانشها در برخورد با آنچه بررسیها واقعاً انجام میدهند دوام نمیآورد. عبور امنیتی یعنی مسائل سطحی — الحاق رشتهای به یک کوئری، یک کلید API که در باندل سمت کلاینت افشا شده، یک eval روی چیزی که کاربر تایپ کرده — ظاهر نشدند. این یک روز با یک آزمونگر نفوذ نیست. استودیوی دوستم از طریق این ابزارک پرداختی دریافت نمیکند، فقط نام و بازههای زمانی، پس این حد کف برایش کافی بود. اگر یک فرآیند پرداخت بود، بیش از این حد کف میخواستم.
دسترسپذیری همان موردی بود که واقعاً باعث شد بایستم و چیزی را جستجو کنم، چون «عبور axe» جامع به نظر میرسد اما نیست. axe — موتور خودکاری که زیر پوسته اجرا میشود — بهطور قابلاعتماد چیزی حدود یکسوم تا نیمی از معیارهای موفقیت WCAG را تشخیص میدهد: متن جایگزین گمشده، نسبتهای کنتراست بد، فیلدهای فرم بدون برچسب، سوءاستفادههای آشکار از ARIA. نمیتواند بگوید آیا منوی کشویی انتخابگر تاریخ سفارشیای که خواسته بودم با صفحهخوان قابل استفاده است، آیا هدایت فوکوس هنگام تب زدن در جریان رزرو چندمرحلهای منطقی است، یا آیا وضعیت «تأییدشده» در مقابل «در انتظار» که سبز و زرد رنگش کرده بودم برای کسی با کوررنگی قرمز-سبز مشکلساز است. اینها به فردی نیاز دارند که با ابزارهایی که کاربران واقعاً از آنها استفاده میکنند، غیرفعالشده، ساخت را طی کند. axe سیگنال واقعی است، نه هیچ — لایهی غلطگیر املایی دسترسپذیری است، نه ویراستار.
انطباق تقریباً ردیفی بود که رد شدم، چون بوروکراتیک به نظر میرسد — «شامل همان چیزی است که برنامه وعده داده» — تا وقتی که به یاد آوردم برنامهای که تأیید کرده بودم زمانی نوشته شده بود که حواسم پرت بود، و واقعاً به یاد نمیآوردم آیا تأییدیههای ایمیلی خواسته بودم یا فقط پیامک. این لایهای است که ساخت را در برابر برنامه بررسی میکند، نه در برابر قصد واقعی من، و عبور کرد، که نشان داد ساخت با چیزی که به آن بله گفته بودم مطابقت دارد، نه لزوماً چیزی که منظورم بود. شنیدهام ساختهایی بودند که از نظر کارکردی و امنیتی مستحکم بودند و باز هم در این لایه شکست خوردند چون یک ویژگی زیر فشار زمانی آرام حذف شده بود. این لایهای است که ساخت را نسبت به گفتگویی که آن را تولید کرده صادق نگه میدارد، حتی وقتی خود گفتگو کمی سرسری بوده باشد.
زیر آن شش ردیف، فهرست بلندتری بود که به دو دسته تقسیم میشد، و این جایی بود که بیشترین زمان را صرف کردم. موارد باید-اصلاحشود چیزهایی نیستند که در حال حاضر با ساخت اشتباه است — آنها رسید هستند. یک خط نوشته بود که لایهی بازبینی موردی را علامتگذاری کرده بود که در آن یک رشتهی تاریخ مستقیماً درون یک کوئری درج شده بود، و پیش از اینکه این نسخه تکمیلشده علامتگذاری شود قبلاً اصلاح شده بود. من به یک زخم باز نگاه نمیکردم؛ به یک جایزخم نگاه میکردم. این تفاوت مهم است، چون اگر یک مورد باید-اصلاحشود را بهعنوان هشدار زنده بخوانید، وقت خود را صرف نگرانی دربارهی چیزی میکنید که از قبل بسته شده است.
فهرست توصیهای طولانیتر بود، و بیشتر چیزهایی بود که اگر داشتم کد یک همکار را بدون اینکه بخواهم مرج را مسدود کنم بررسی میکردم، خودم میگفتم: «فکر میکنم بلوک تکرارشوندهی رندر بازهی زمانی را در یک کامپوننت مشترک استخراج کنیم»، «این نقطهی پایانی هیچ محدودیت نرخی ندارد که برای یک ابزار رزرو داخلی مشکلی نیست ولی اگر عمومی شود ارزش بازنگری دارد.» هیچکدام از آن فهرست یک نقص نبود. تصمیمهای قضاوتی بودند که یک بازبین فقط با برنامه و کد جلوی چشمش گرفته بود، و برای برنامهریز داخلی یک استودیوی یوگا، هر یک از آن تصمیمها در سمت معقول قرار میگرفت. اگر استودیوی دوستم یک فرانچایز بود با ابزارک تعبیهشده در پنجاه صفحهی شعبه، میخواستم دربارهی محدودیت نرخ مخالفت کنم — دستهبندی به زمینهای بستگی دارد که بازبین فقط میتواند حدس بزند، و وقتی حدسی به نظرتان اشتباه میرسد، حرکت درست گفتن آن در گفتگو است، نه فرض اینکه برچسب نهایی است.
چیزی که مرا متعجب کرد، هنگام نگاه به یک فهرست توصیهای نسبتاً بزرگ در کنار یک ستون باید-اصلاحشود پاک، این بود که تقریباً طول آن را بهعنوان خبر بد میخواندم. اینطور نیست. ساختی با صفر یادداشت توصیهای یا عبور محدودی داشته یا شانس آورده؛ ساختی با انبوهی از موارد «فکر میکنم» و هیچ چیز باقیمانده در باید-اصلاحشود، ساختی است که واقعاً با دقت بررسی شده. ستون توصیهای همان چیزی است که قرار است بعد از رفع مشکلات واقعی باقی بماند.
کار دیگری که خودم را وادار کردم انجام دهم، چون این سابقه سه هفته کهنه شده بود، این بود که پیش از اعتماد به نتایج، بررسی کنم کدام لایهها واقعاً اجرا شدهاند. در اینجا هر شش لایه حاضر بودند، اما از آن زمان ساختی دیدهام که در آن دسترسپذیری بهسادگی از فهرست غایب بود بهجای اینکه عبور یا شکست علامتگذاری شود — این با نادیده گرفتن بهعنوان بیاهمیت یکی نیست، نشانهی این است که بررسی برای آن نوع سایت یا پیکربندی پرچم خاص اجرا نشده، و خواندن غیبت بهعنوان عبور خاموش دقیقاً همان اشتباهی است که این قالب برای کسی که سرسری نگاه میکند به آن دعوت میکند.
هیچکدام از اینها به من نگفت که آیا جریان رزرو استودیوی یوگا واقعاً به تبدیل منجر میشود، آیا مردم در مرحلهی انتخاب بازهی زمانی رهایش میکنند، یا آیا اصلاً ایدهی یک ابزارک سفارشی بهجای لینک دادن به Calendly تصمیم درستی بود. راستیآزمایی ثابت میکند ساختی همانطور که وعده داده شده کار میکند، نه اینکه وعده مسئلهی درستی برای پرداختن بوده — اینها سؤالهای جدایی هستند، و دیدهام ساختهایی که تمام لایهها را بینقص طی کردهاند و باز هم با کاربران واقعی شکست خوردهاند چون «درست کار کردن» و «حل کردن مسئلهی درست» آنقدر که امیدوارید همپوشانی ندارند. نیمهای از این که واقعاً به سؤال دوم پاسخ میدهد حلقهی سنجش است، و قرار است این دو با هم خوانده شوند. یک سابقهی راستیآزمایی پاک برای ویژگیای که هیچکس از طریق آن رزرو نمیکند، همچنان ویژگیای است که هیچکس از طریق آن رزرو نمیکند.
