برنامهای که نادیده میگیرید، همان قطعیای است که بعداً باید رفعش کنید
هر چارچوبی در مهندسی نرمافزار به شما میگوید سریع حرکت کنید، زود منتشر کنید، در محیط تولید تکرار کنید. برای سایتهای تولیدشده با هوش مصنوعی، این معکوس است. سازنده در اینجا از استریم کردن مستقیم کد از روی درخواست شما خودداری میکند — متوقف میشود، یک برنامه مینویسد، و منتظر میماند تا شما آن را ببینید — و این امتناع همان تصمیم واحدی است که کل بقیه این خط لوله بر پایه آن ساخته شده. کندتر در ابتدا، ارزانتر در همه جای بعدی. من هر بار این معامله را میپذیرم، و فکر میکنم بیشتر افرادی که برعکس آن را استدلال میکنند واقعاً ندیدهاند یک حدس اشتباه در ادامه چه هزینهای دارد.
این حالت شکستی است که برنامه برای جلوگیری از آن وجود دارد. مینویسید «یک سایت رزرو برای استودیوی من» و دکمه شروع را میزنید. سیستم باید حدس بزند «رزرو» یعنی چه — یک ویجت تقویم، یک قطعه تعبیهشده شخص ثالث، یک سیستم رزرو واقعی با بررسی تداخل — و باید قبل از نوشتن هر چیزی حدس بزند، چون ترتیب دیگری برای این کار وجود ندارد. اگر داخل یک برنامه حدس اشتباه بزنید، تصحیح آن یک جمله است، پنج ثانیه، تمام. اگر داخل کد تولیدشده حدس اشتباه بزنید، دیگر یک جمله را ویرایش نمیکنید، بلکه ده فایل را که قبلاً به آن فرض اشتباه وابسته شدهاند باز میکنید. هر دو حالت را دیدهام. تصحیح در مرحله برنامهریزی یک تبادل است. چرخش بعد از تولید روی همان ابهام یکسان، یعنی دور انداختن و بازسازی.
برنامه فقط یک فهرست کار نیست هم، و این بخشی است که افراد از دست میدهند. یک قرارداد است، و سیستم خودش را به آن پایبند نگه میدارد: یک راستیآزمای انطباق، یکی از عاملهایی که باید قبل از انتشار یک بیلد تأییدش کند، سایت نهایی را با برنامهای که تأیید کردهاید مقایسه میکند. آیا همه صفحات برنامهریزیشده ساخته شدند؟ آیا فهرست ویژگیها با آنچه منتشر شد مطابقت دارد؟ «تمامشدن» در اینجا یک حس مبهم نیست — نسبت به یک وعده مکتوب است، که خطبهخط قابل بررسی است. این تضمین قویتری از «کد اجرا میشود» است، و فقط به این دلیل آن را دارید که سندی برای مقایسه وجود دارد. برنامه را بردارید، معیار سنجش را هم برداشتهاید.
جایی که واقعاً نتیجه میدهد
اهرم شما بهعنوان فردی که بیلد را هدایت میکند، از ابتدا سنگینتر است، چه از آن استفاده کنید چه نکنید. اگر به معماری اطلاعات، ساختار صفحه، اینکه کدام ویژگیها در نسخه اول در مقابل نسخه دوم قرار میگیرند اهمیت میدهید — آن وسواس در بازبینی برنامه ده برابر بیشتر از بعد از اولین دور تولید ارزش دارد. چهار دقیقه اضافه برای بازخوانی یک برنامه بهتر از یک رفتوبرگشت برای رفع یک بیلد است که قبلاً به مسیر اشتباه رفته است.
روشنترین مثال نوع محصول است — سایت استاتیک ساده، اپلیکیشن قابلنصب، بیلد فریمورک، اپلیکیشن متصل به سرور با پایداری واقعی. شبیه یک منوی کشویی بهنظر میرسد. نیست. ساختاریترین انتخاب در کل فرآیند است، چون بهطور بیصدا دهها چیز را تعیین میکند که هیچ ربطی به ظاهر سایت ندارند.
| نوع محصول | پیشنمایش | انتشار | حساب کاربری / پایگاه داده |
|---|---|---|---|
| سایت استاتیک ساده | فوری، چون فقط فایلهای استاتیک است | خروجی استاتیک بدون مشکل کپی میشود | ممکن نیست — درخواست ورود کاربر، درخواست چیزی است که این نوع بهصورت ساختاری نمیتواند انجام دهد |
| بیلد فریمورک | ابتدا کامپایل میشود؛ بیلد شکسته بهصورت «بدون پیشنمایش» نمایان میشود، نه «صفحه خراب» | همان مسیر کپی استاتیک تمیز، پس از کامپایل | ممکن نیست |
| اپلیکیشن متصل به سرور | — | به جایی برای اجرای واقعی یک فرآیند نیاز دارد، که متفاوت خراب میشود — یک فرآیند از کار افتاده، نه یک فایل گمشده | تنها نوعی که حساب کاربری و پایگاه داده در آن اصلاً وجود دارد |
و نمیتوانید بعداً بهراحتی نوع را ارتقا دهید. رفتن از سایت ساده به اپلیکیشن متصل به سرور یک کلید تنظیمات نیست — نزدیک به یک بیلد دوم است، چون نیمی از فرضهای برنامه (نحوه بارگذاری صفحات، محل ذخیره داده، معنای «انتشار») بر اساس نوع قبلی ساخته شدهاند. پس در زمان برنامهریزی آن را بگویید، حتی با اطمینان نصفه: «احتمالاً به حساب کاربری نیاز خواهم داشت.» برنامهریزی برای یک اپلیکیشن متصل به سرور و استفاده فقط از بخشهای استاتیک آن هیچ هزینهای ندارد. کشف اینکه بعداً به آن نیاز داشتید، هزینه بازسازی دارد.
جایی که منتقدان حق دارند
هیچکدام از اینها رایگان نیست و قصد ندارم وانمود کنم که هست. فضاهای کاری ایزوله برای هر اجرا به این معناست که فایلهای دانش شما بهصورت تازه کپی میشوند، هیچ چیزی به دستگاه شما بازنمیگردد — این برای شما خوب است اگر لپتاپتان وسط ساخت خراب شود، اما برای تأخیر بد است، چون آمادهسازی یک فضای کاری و، برای ساختهای فریمورک، اجرای یک نصب واقعی وابستگیها درون مرز یک کانتینر، زمان واقعی میبرد. آن مرز کانتینر به این دلیل وجود دارد که ساخت یک فریمورک، `npm install` و اسکریپتهای ساخت دلخواه را اجرا میکند — کدی که شما ننوشتهاید و با امتیازات زمان ساخت اجرا میشود — و انجام این کار روی یک هاست مشترک بدون ایزولهسازی، تنها یک حمله سردرگمی وابستگی (dependency-confusion) با دسترسی به دادههای مستأجر دیگر فاصله دارد. سریعولیناامن یک گزینه بود. فقط معاملهای نبود که ارزش انجام دادن داشته باشد.
همین داستان دربارهی راستیآزمایی هم صدق میکند. یک ساخت تمامشده وقتی تولید متوقف میشود از خط لوله خارج نمیشود؛ زمانی خارج میشود که مجموعهای از راستیآزمایان مستقل دیگر چیزی برای مسدود کردن پیدا نکنند:
- بازبینی کد
- امنیت
- لینکها و سئو
- دسترسپذیری
- انطباق
- یک اجرای واقعی در مرورگر
این یک بار عبور نیست، بلکه چرخهی پرچمگذاری-اصلاح-بازبررسی است که تا زمانی ادامه دارد که دیگر کسی حرفی برای گفتن نداشته باشد، چون یک بار اجرای لینتر میتواند رگرسیونی را که اصلاح خودش ایجاد کرده نادیده بگیرد. اصلاح یک لینک شکسته و شکستن ناخواستهی سلسلهمراتب عنوانها در همان صفحه، دقیقاً همان چیزی است که یک بررسی یکباره از قلم میاندازد و یک بازبررسی آن را میگیرد. هزینهی صادقانهی این چرخه، ساختی است که گاهی درست در انتها یک دقیقهی اضافه بدون دلیل قابل مشاهده طول میکشد. مردم آن یک دقیقه را متوجه میشوند. آنها متوجه شش عاملی که تازه بحث دربارهی سایتشان را تمام کردهاند نمیشوند. این یک اعتراض منصفانه دربارهی تجربه است — فقط فکر نمیکنم دلیل خوبی برای ارسال کار بدون اینکه این بحث اصلاً اتفاق افتاده باشد، باشد.
