چطور یک نمونه اولیه ساخته‌شده با هوش مصنوعی را به محیط واقعی ببریم

برای انتقال یک نمونه اولیه ساخته‌شده با هوش مصنوعی به محیط واقعی، فاصله بین «وقتی امتحانش می‌کنم کار می‌کند» و «وقتی دیگران استفاده می‌کنند هم کار می‌کند» را پر می‌کنید. در عمل یعنی پنج کار: هر بار که چیزی را تغییر می‌دهید جریان‌های اصلی را آزمون کنید، مشخص کنید چه کسی چه را ببیند و تغییر دهد، مطمئن شوید خطاها را قبل از اینکه کاربران به شما بگویند می‌شنوید، از داده‌ها پشتیبان بگیرید و ثابت کنید می‌توانید بازیابی‌شان کنید، و اپ را روی گوشی به‌اندازه کافی سریع نگه دارید. هیچ‌کدام به بازنویسی کامل نیاز ندارد — این یک فهرست است که همراه با همان هوش مصنوعی که نمونه اولیه را ساخته، گام‌به‌گام انجامش می‌دهید.

نمونه اولیه در برابر محیط واقعی: واقعاً چه چیزی تغییر می‌کند

نمونه اولیه یک کاربر دقیق دارد: خودتان. می‌دانید کدام دکمه‌ها را بزنید، ورودی معقول تایپ می‌کنید و اگر چیزی خراب شد، شانه بالا می‌اندازید و از هوش مصنوعی می‌خواهید درستش کند. محیط واقعی کاربران زیاد و بی‌دقت دارد، چند کنجکاو و گاهی یک کاربر خصمانه. کد لازم نیست «سازمانی» شود؛ باید موقعیت‌هایی را مدیریت کند که نمونه اولیه هرگز با آنها روبه‌رو نمی‌شود.

بقیه این راهنما هر ردیف را توضیح می‌دهد.

گام ۱: محدوده را ببندید و جریان‌های اصلی را بنویسید

قبل از سخت‌سازی هر چیزی، تصمیم بگیرید نسخه اول چیست. سه تا شش جریانی را که مهم‌ترین‌اند فهرست کنید — برای نمونه «ثبت‌نام، ساخت پروژه، دعوت هم‌تیمی، پرداخت». اینها می‌شوند اسکریپت آزمون، هدف‌های پایش و چیزهایی که بعد از هر تغییر بررسی می‌کنید.

هر چیزی که در این فهرست نیست یا حذف می‌شود یا روشن به‌عنوان نسخه بتا علامت می‌خورد. ساختن چهار جریان قابل‌اعتماد خیلی آسان‌تر از چهارده جریان است.

گام ۲: مثل یک غریبه آزمون کنید، سپس تکرارپذیرش کنید

سازنده‌های هوش مصنوعی در تولید کدی که در مسیر خوشبختانه کار می‌کند خوب‌اند. مشکلات محیط واقعی در مسیرهای ناخوشایند زندگی می‌کنند. هر جریان اصلی را با این موارد آزمون کنید:

• ورودی بد: فیلدهای اجباری خالی، نامی با ۵٬۰۰۰ کاراکتر، ایمیلی بدون @، مقدار منفی، تاریخی در گذشته.
• تازه‌سازی و دکمه بازگشت: وسط تسویه صفحه را رفرش کنید؛ بعد از ارسال فرم دکمه بازگشت را بزنید. آیا چیزی دو بار ساخته می‌شود؟
• دو تب، دو کاربر: با دو حساب مختلف وارد شوید و سعی کنید صفحه‌های یکدیگر را با تغییر شناسه در نشانی باز کنید.
• کند و کوچک: صفحه به‌اندازه گوشی و اتصال محدودشده (ابزارهای توسعه‌دهنده مرورگر می‌توانند یکی را شبیه‌سازی کنند).
• حالت‌های خالی: یک حساب تازه بدون داده. نمونه‌های اولیه اغلب با داده نمونه ساخته می‌شوند و بدون آن خراب به نظر می‌رسند.

سپس بررسی را تکرارپذیر کنید. حداقل یک فهرست مکتوب نگه دارید و قبل از هر انتشار اجرایش کنید. بهتر این است که از هوش مصنوعی بخواهید آزمون خودکار برای جریان‌های مهم بنویسد:

آزمون‌های خودکار سرتاسری برای این جریان‌ها اضافه کن: ثبت‌نام با ایمیل، ساخت یک پروژه، دعوت کاربر دوم، و تکمیل پرداخت در حالت آزمایشی Stripe. همچنین آزمون‌هایی اضافه کن که تأیید کنند کاربر نمی‌تواند با تغییر نشانی، پروژه کاربر دیگری را ببیند یا ویرایش کند.

آزمون‌هایی که ثابت می‌کنند کاربر نمی‌تواند کاری را انجام دهد، همان‌هایی هستند که نمونه‌های اولیه اغلب ندارند.

گام ۳: مبانی امنیت که نمونه‌های اولیه رد می‌کنند

بیشتر مشکلات امنیتی در اپ‌های ساخته‌شده با هوش مصنوعی عجیب و غریب نیستند. بررسی‌های جاافتاده‌اند. این فهرست را مرور کنید و فهرست کامل امنیت برای اپ‌های ساخته‌شده با هوش مصنوعی را هم ببینید:

• مجوز دسترسی در سرور. پنهان کردن یک دکمه امنیت نیست. هر درخواستی که داده را می‌خواند یا تغییر می‌دهد باید در سرور بررسی کند که کاربر واردشده مجاز است. اگر اپ شما از پایگاه داده با قوانین سطح ردیف استفاده می‌کند، مطمئن شوید روشن و آزمایش شده‌اند.
• رازها بیرون از مرورگر. کلیدهای API برای پرداخت، ایمیل یا ارائه‌دهندگان هوش مصنوعی باید در متغیرهای محیطی سمت سرور باشند، هرگز در کد سمت کاربر. اگر مطمئن نیستید این یعنی چه، متغیرهای محیطی و رازها چه هستند را بخوانید.
• اعتبارسنجی در سرور. مرورگر را می‌شود دور زد، پس هر بررسی مهم را در سرور هم تکرار کنید.
• ورود به درستی انجام شود. از یک کتابخانه یا سرویس احراز هویت که به‌خوبی آزمون شده استفاده کنید، نه ذخیره دستی رمز عبور. راهنمای ما درباره افزودن ورود به اپ گزینه‌ها را پوشش می‌دهد.
• محدودیت نرخ برای ورود، ثبت‌نام، بازنشانی رمز عبور و هر چیزی که ایمیل می‌فرستد یا یک API پولی را صدا می‌زند.
• خطاهای دوستانه. کاربران باید «مشکلی پیش آمد» ببینند؛ جزئیات به گزارش‌های شما می‌رود، نه روی صفحه.
• هر کلیدی که نشت کرده را عوض کنید. اگر یک کلید زنده هرگز در گفت‌وگو، کامیت یا اسکرین‌شات چسبانده شده، آن را نزد ارائه‌دهنده عوض کنید.

یک دستور که چند مورد را با هم پوشش می‌دهد:

این اپ را برای امنیت محیط واقعی بررسی کن. بررسی کن که هر مسیر API تأیید کند کاربر واردشده مالک رکوردی است که می‌خواند یا تغییر می‌دهد، هیچ کلید سری به مرورگر ارسال نشود، ورودی‌ها در سرور اعتبارسنجی شوند، و ورود و بازنشانی رمز عبور محدودیت نرخ داشته باشند. قبل از تغییر هر چیزی، فهرست آنچه پیدا کردی را بده.

اینکه ابتدا فهرست بخواهید به شما اجازه می‌دهد مشکلات را ببینید و ترتیب را خودتان تعیین کنید، به‌جای اینکه یک تغییر بزرگ یک‌جا دریافت کنید.

گام ۴: بدانید کی خراب می‌شود — ثبت رویدادها و پایش

در پیش‌نمایش خطاها را همان لحظه‌ای که رخ می‌دهند می‌بینید. در محیط واقعی باید اپ به شما خبر دهد. سه لایه، از ارزان‌ترین به مفیدترین:

1. گزارش‌های سرور. مطمئن شوید خطاها با زمینه کافی ثبت می‌شوند تا بشود بازتولیدشان کرد: کدام مسیر، کدام شناسه کاربر (نه رمز عبور یا کارت)، و شکل ورودی. اگر اپ فقط در کنسول چاپ می‌کند، از هوش مصنوعی بخواهید ثبت ساختاریافته اضافه کند.
2. پیگیری خطا. سرویسی مانند Sentry یا ابزار مشابه، استثناهای سمت کاربر و سرور را جمع می‌کند، گروه‌بندی می‌کند و برایتان ایمیل می‌فرستد. برای یک اپ کوچک، طرح‌های رایگان این سرویس‌ها اغلب کافی است؛ محدودیت‌های فعلی را در سایت خودشان بررسی کنید.
3. بررسی در دسترس بودن. یک سرویس خارجی که هر چند دقیقه صفحه اصلی و یک مسیر کلیدی API را بارگذاری می‌کند و اگر شکست خورد هشدار می‌دهد. این مشکل‌هایی را می‌گیرد که اپ را از ثبت هر چیزی باز می‌دارد.

یک عادت دیگر اضافه کنید: بعد از هر انتشار، اپ زنده را باز کنید و فهرست جریان‌های اصلی را روی نشانی واقعی اجرا کنید، نه فقط روی پیش‌نمایش.

گام ۵: پشتیبان‌گیری و راه بازگشت

دو چیز متفاوت نیاز به محافظت دارند و به‌راحتی با هم اشتباه گرفته می‌شوند.

• کد. پروژه را در کنترل نسخه نگه دارید تا هر تغییری قابل برگشت باشد. بسیاری از سازنده‌های هوش مصنوعی نقطه بازگشت از فایل‌های شما نگه می‌دارند؛ همگام‌سازی با یک مخزن Git یک نسخه بیرون از سازنده هم به شما می‌دهد.
• داده. برگرداندن کد، پایگاه داده را برنمی‌گرداند. یک مهاجرت بد یا یک دکمه حذف معیوب می‌تواند ردیف‌هایی را نابود کند که هیچ نقطه بازگشت کدی برنمی‌گرداند.

برای داده، پشتیبان‌گیری منظم تنظیم کنید که جایی غیر از میزبانی خود اپ ذخیره شود — برای یک پایگاه داده Postgres، یک pg_dump زمان‌بندی‌شده به فضای ذخیره‌سازی جدا رویکرد رایج است، و بسیاری از میزبان‌های مدیریت‌شده پایگاه داده پشتیبان خودکار یا بازیابی به یک نقطه زمانی ارائه می‌دهند. سپس کاری را انجام دهید که بیشتر مردم جا می‌گذارند: یک پشتیبان را در یک پایگاه داده آزمایشی بازیابی کنید و بررسی کنید داده‌ها آنجا هستند.

همچنین از هوش مصنوعی بخواهید اقدامات مخرب را ایمن‌تر کند: یک مرحله تأیید برای حذف، و «حذف نرم» (علامت‌گذاری ردیف‌ها به‌عنوان حذف‌شده به‌جای پاک کردنشان) برای هر چیزی که کاربران ممکن است بخواهند برگردانند.

گام ۶: عملکردی که روی گوشی هم دوام بیاورد

نمونه‌های اولیه سریع به نظر می‌رسند چون شما تنها کاربر هستید و داده‌ها بسیار کوچک‌اند. قبل از راه‌اندازی:

• داده با اندازه واقعی بارگذاری کنید. از هوش مصنوعی بخواهید چند هزار ردیف وارد کند و ببیند کدام صفحه‌ها کند می‌شوند. فهرست‌ها معمولاً به صفحه‌بندی نیاز دارند و پایگاه داده معمولاً به ایندکس روی ستون‌هایی که فیلتر و مرتب می‌کنید.
• تصاویر را کوچک کنید. تصویر بزرگ شایع‌ترین دلیل کند بارگذاری یک صفحه است. تصاویر تغییراندازه‌شده و فشرده و بارگذاری تنبل زیر خط تا را درخواست کنید.
• اندازه بگیرید. Lighthouse را در ابزارهای توسعه‌دهنده کروم روی نشانی زنده در حالت موبایل اجرا کنید. شاخص‌های اصلی وب گوگل هدف منطقی‌اند: بزرگ‌ترین نمایش محتوا زیر ۲٫۵ ثانیه، واکنش تا نمایش بعدی ۲۰۰ میلی‌ثانیه یا کمتر، و جابه‌جایی تجمعی چیدمان ۰٫۱ یا کمتر.
• تأخیر «بیدارشدن» را زیر نظر بگیرید. میزبانی که وقتی بیکار است می‌خوابد هزینه را کم می‌کند، اما بازدید اول بعد از یک دوره آرام را کندتر می‌کند. برای یک اپ تازه این معمولاً معامله خوبی است؛ بدانید که این اتفاق می‌افتد.

صفحه پروژه‌ها با ۵٬۰۰۰ ردیف کند است. صفحه‌بندی سمت سرور (۲۵ مورد در هر صفحه) اضافه کن، ایندکس‌های پایگاه داده برای ستون‌هایی که فیلتر و مرتب می‌کنیم بساز، و وقتی صفحه بعدی بارگذاری می‌شود وضعیت در حال بارگذاری نشان بده.

گام ۷: مبانی عملیاتی

چند چیز کوچک یک اپ سرگرمی را از اپی که مردم به آن اعتماد می‌کنند جدا می‌کند:

• دامنه اختصاصی با HTTPS. ببینید چطور دامنه اختصاصی وصل کنیم.
• ایمیل تراکنشی از یک دامنه تأییدشده برای تأیید ثبت‌نام و بازنشانی رمز عبور — در چطور ایمیل از اپ بفرستیم پوشش داده شده است.
• سیاست حریم خصوصی و شرایط که آنچه واقعاً جمع می‌کنید را شرح دهد. ادعاهای انطباق را که به دست نیاورده‌اید کپی نکنید.
• مسیر پشتیبانی — حتی یک نشانی ایمیل که رصد می‌شود.
• کلیدهای آزمایشی و زنده جدا برای پرداخت و ایمیل، و یادداشت روشن درباره اینکه کدام محیط از کدام کلید استفاده می‌کند.

گام ۸: تحویل تمیز

دیر یا زود یک نفر دیگر روی اپ کار خواهد کرد: یک فریلنسر، یک هم‌بنیان‌گذار تازه، یا خودتان بعد از شش ماه. آن را آسان کنید:

• یک README که توضیح دهد چطور اجرایش کنید، به کدام متغیرهای محیطی نیاز دارد (فقط نام‌ها، هرگز مقدارها) و چطور منتشرش کنید.
• فهرست جریان‌های اصلی و آزمون‌های خودکار.
• یادداشت کوتاه معماری: بخش کاربری، بخش سرور، پایگاه داده، سرویس‌های خارجی و محل میزبانی هر کدام.
• فهرست دسترسی: چه کسی دسترسی مدیر به دامنه، میزبانی، پایگاه داده، حساب‌های پرداخت و ایمیل دارد. این حساب‌ها را زیر یک ایمیل کسب‌وکار قرار دهید، نه ایمیل شخصی.
• کد در Git، ترجیحاً همگام‌سازی‌شده با یک مخزنی که خودتان دارید. اگر بعداً قصد دارید میزبانی را عوض کنید، چطور اپ ساخته‌شده با هوش مصنوعی را خروجی بگیریم و روی سرور خودمان میزبانی کنیم را بخوانید.

هوش مصنوعی می‌تواند بیشتر این‌ها را برایتان پیش‌نویس کند:

یک README برای این پروژه بنویس برای توسعه‌دهنده‌ای که آن را هرگز ندیده: اپ چه کاری می‌کند، پشته فناوری چیست، چطور به‌صورت محلی اجرایش کنیم، هر متغیر محیطی که می‌خواند (فقط نام و کاربرد)، ساختار پایگاه داده چطور سازمان‌دهی شده، و چطور منتشرش کنیم.

فهرست آمادگی برای محیط واقعی

• جریان‌های اصلی نوشته و آزمون شده‌اند، از جمله «به داده دیگران نمی‌توان دسترسی داشت»
• مجوز دسترسی و اعتبارسنجی در سرور روی هر مسیر داده
• هیچ کلید سری در کد سمت کاربر نیست؛ کلیدهای نشت‌کرده عوض شده‌اند
• محدودیت نرخ روی احراز هویت و هر چیزی که هزینه دارد
• پیگیری خطا و هشدار در دسترس بودن به صندوقی که می‌خوانید وصل است
• پشتیبان‌های پایگاه داده بیرون از میزبانی اپ، با یک بازیابی آزمایشی موفق
• صفحه‌بندی و ایندکس‌ها با داده واقع‌گرایانه بررسی شده‌اند
• دامنه اختصاصی، دامنه ارسال تأییدشده، سیاست حریم خصوصی
• README و فهرست دسترسی برای نفر بعدی

انجام این کار با Mythex

اگر نمونه اولیه را در Mythex ساخته‌اید، بیشتر این گام‌ها در همان پروژه به شکل دستور هستند. تایپ کنید /test و Mythex پیش‌نمایش زنده را مثل یک کاربر کلیک می‌کند و جریان‌های خراب را گزارش می‌دهد — ببینید آزمون اپ. کلیدها به‌جای گفت‌وگو در رازهای پروژه قرار می‌گیرند، هر نوبت موفق عامل از فایل‌های شما یک نقطه بازگشت ذخیره می‌کند که می‌توانید به آن برگردید، و انتشار یک نشانی زنده با میزبانی می‌دهد که میزبانی و پایگاه داده‌اش از همان موجودی اعتبار حساب می‌شوند (محدودیت‌های میزبانی توضیح می‌دهد اپ‌ها و پایگاه داده‌ها چطور می‌خوابند و بیدار می‌شوند). نقطه‌های بازگشت فایل‌ها را پوشش می‌دهند، نه ردیف‌های پایگاه داده، پس باز هم پشتیبان داده‌هایتان را برنامه‌ریزی کنید. در طرح Pro می‌توانید دامنه اختصاصی وصل کنید، یا کد را خروجی بگیرید یا با مخزن GitHub خودتان همگام کنید تا تحویل آسان شود.

پرسش‌ها