هر انتخاب بر اساس چیزی انجام شده که از مُد روز بیشتر عمر میکند: پشتیبانی بلندمدت، جامعهٔ کاربری بزرگ بهاندازهای که نیروی متخصص پیدا شود، و رفتار قابل پیشبینی زیر بار.
توجیه کردن یک انتخاب فنی بعد از انجام کار آسان است و برگرداندنش گران. به همین دلیل هر مورد در این صفحه به یک شکل نوشته شده است: چیست، دقیقاً چه چیزی به شما میدهد، و از کجا دیگر کمکی نمیکند. اگر راهکار سادهتری همان کار را انجام بدهد، همان پیشنهاد میشود؛ حتی وقتی پروژهٔ کوچکتری باشد.
تایپ یکپارچه با TypeScript
تغییر نام یک ستون، بیلد را میشکند؛ نه صفحه را نیمهشب.
یک مجموعه تایپ، هم سطر پایگاه داده را توصیف میکند، هم تابع سمت سرور و هم فرم روی صفحه. با تغییر نام یک ستون، ویرایشگر پیش از اجرای برنامه تمام نقاطی را نشان میدهد که باید تغییر کنند. بدون این، ناسازگاری ساکت میماند تا وقتی یک کاربر واقعی فرمی واقعی را ثبت کند.
مرز کارایی
تایپ، شکل داده را بررسی میکند نه معنای آن را. فیلدی از نوع عدد، عدد اشتباه را هم بدون اعتراض نگه میدارد. آن بخش کارِ تست است.
Node.js در سمت سرور
یک زبان در کل سیستم، و کتابخانهای آماده برای تقریباً هر نیاز دیگر.
Node.js سمت سرور را با همان زبان سمت مرورگر اجرا میکند. در نتیجه یک تیم کل سیستم را میخواند و یک قاعدهٔ اعتبارسنجی یک بار نوشته میشود، نه دو بار در دو زبان که بهمرور از هم فاصله میگیرند. Node به بهترین معنا کسلکننده است: بیش از یک دهه سابقه، نسخههای با پشتیبانی بلندمدت، و بستهٔ آماده برای تقریباً هر سرویسی که لازم شود. مهمتر از همه، نیروی متخصص آن پیدا میشود؛ روزی که یکی از اعضای تیم برود، این از هر معیار سرعتی مهمتر است.
مرز کارایی
Node برای محاسبات سنگین و ممتد ابزار مناسبی نیست. در چنین مواردی آن بخش روی سرویس مخصوص خودش اجرا میشود و Node آن را صدا میزند.
PostgreSQL، بهشکل درست
قاعدهای که داخل پایگاه داده باشد، با باگِ یک صفحه دور زده نمیشود.
محدودیتها، کلیدهای خارجی، تراکنشها و سطح دسترسی سطری، قواعد را کنار خود داده میگذارند. صفحهای که باگ دارد هم نمیتواند نیمی از یک سفارش را ذخیره کند یا دادههای یک مشتری را به مشتری دیگر بدهد، چون پایگاه داده اجازه نمیدهد. PostgreSQL بیشتر از تصور رایج کار میکند: جستوجوی متن کامل، JSON، صف و زمانبندی. همین باعث میشود تعداد قطعات متحرک سیستم، و تعداد چیزهایی که میتوانند از کار بیفتند، کم بماند.
مرز کارایی
این قواعد عمداً سختگیرند، پس تغییرشان در آینده مهاجرت لازم دارد. این هزینه واقعی است، اما از هزینهٔ کشف اینکه داده هیچوقت آن چیزی نبوده که تصور میشد کمتر است.
رندر سمت سرور
صفحهای که چهار ثانیه طول بکشد، معمولاً اسکرول هم نمیشود.
صفحهها روی سرور ساخته میشوند و آماده به دست کاربر میرسند. اولین چیزی که کاربر میبیند محتواست، نه نشانهٔ در حال بارگذاری. روی موبایل و اینترنت همراه، که مسیر ورود بیشتر کاربران است، همین تفاوتِ میان نرمافزاری است که سریع به نظر میرسد و نرمافزاری که خراب به نظر میرسد.
مرز کارایی
سرعت، خاصیت کل مسیر است: کوئری، حجم پاسخ، تصویر و اسکریپتهای بیرونی. از هفتهٔ اول طراحی میشود، چون در هفتهٔ آخر اضافه نمیشود.
زیرساخت ابری به نام شما
سروری در گوشهٔ دفتر نیست که بهروزرسانیاش فراموش شود.
همهچیز روی زیرساختی اجرا میشود که حساب آن به نام شماست، نه به نام ما. مقیاسپذیری، پشتیبانگیری، گواهی امنیتی و وصلههای امنیتی وظیفهٔ پلتفرم است، نه کاری که باید کسی میان کارهای دیگر به یاد بیاورد. ظرفیت با تقاضا بالا میرود، پس یک هفتهٔ پرمراجعه به قطعی تبدیل نمیشود. اگر همکاری هم تمام شود، چیزی برای تحویل دادن نمیماند، چون کلیدها از ابتدا دست شما بوده است.
مرز کارایی
سرویسهای مدیریتشده هزینهٔ ماهانهٔ بیشتری از یک سرور اجارهای دارند و هزینهٔ سالانهٔ کمتری از زمانی که همان سرور میگیرد. جایی که پروژه واقعاً به سرور اختصاصی نیاز داشته باشد، سرور اختصاصی میگیرد.
اتوماسیون، پیش از نرمافزار بیشتر
اتلاف وقت معمولاً یک مشکل بزرگ نیست؛ بیست جابهجایی کوچک است.
دادهای که در سامانهٔ دوم دوباره تایپ میشود. گزارشی که هر دوشنبه از همان سه فایل ساخته میشود. تأییدی که با پیام پیگیری میشود. اتوماسیون این سامانهها را مستقیم به هم وصل میکند و کار تکراری را روی زمانبندی میگذارد، تا انجام شدنش به یاد آوردن کسی وابسته نباشد و کار با نبودن یک نفر متوقف نشود.
مرز کارایی
خودکار کردن فرایندی که درک نشده، فقط خرابی را سریعتر و بیصداتر میکند. اول فرایند بررسی و مکتوب میشود. گاهی همان مرحله به راهکاری سادهتر از نرمافزار میرسد و همان پیشنهاد میشود.
یکپارچهسازی و تحویل پیوسته
انتشار نسخه دیگر یک رویداد نیست.
هر تغییر همان بررسیها را با همان ترتیب اجرا میکند — تایپها، تستها، بیلد و پیشنمایش — و تا قبول نشود به محیط عملیاتی نزدیک نمیشود. انتشار پس از ادغام انجام میشود، نه دستی و نیمهشب. نسخهٔ خراب در یک مرحله برگردانده میشود، بهجای اینکه جلوی چشم کاربر رفع اشکال شود.
مرز کارایی
خط تحویل دقیقاً به اندازهٔ بررسیهای داخلش معتبر است. بیلد سبزی که پشتش تستی نباشد، چراغ سبزی است که هیچ معنایی ندارد.
تست، در چند لایه
نرمافزاری که اجرا میشود، لزوماً نرمافزاری که کار میکند نیست.
تست واحد برای منطق، تست یکپارچگی برای محل اتصال بخشها، تست سرتاسری برای همان چند مسیری که درآمد از آن میآید، و بررسی دودی بعد از هر انتشار. هر لایه دستهٔ متفاوتی از خرابی را میگیرد و لایههای ارزانِ پایین، نگه داشتن لایههای گرانِ بالا را ممکن میکنند.
مرز کارایی
تست، حالتهایی را اثبات میکند که کسی به آنها فکر کرده است. نبودِ باگ را اثبات نمیکند، و مجموعه تستی که اجرا نشود فقط مستنداتی است که دیگر درست نیست.
عمیقتر
مقالات فنی
چرا نرمافزارهایی که ظاهر کامل دارند بعد از راهاندازی خراب میشوند، و هر لایهٔ تست جلوی کدام خرابی را میگیرد.
پروژهای دارید که کار میکند اما دستی منتشر میشود؟
خط تحویل خودکار روی کدی که از قبل نوشته شده هم اضافه میشود. در یک جلسهٔ سی دقیقهای بررسی میشود که پروژه امروز چطور ساخته و منتشر میشود، و بهروشنی گفته میشود چه کاری لازم است.