بازیابی خطای جاوا اسکریپت: راهنمای الگوهای پیاده‌سازی تنزل تدریجی زیبا

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

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

این راهنمای جامع، الگوهای عملی و متمرکز بر پیاده‌سازی را برای تنزل تدریجی زیبا در جاوا اسکریپت بررسی خواهد کرد. ما فراتر از `try...catch` ساده خواهیم رفت و به استراتژی‌هایی خواهیم پرداخت که تضمین می‌کنند اپلیکیشن شما یک ابزار قابل اعتماد برای کاربران باقی بماند، صرف نظر از اینکه محیط دیجیتال چه چیزی را پیش روی آن قرار دهد.

تنزل تدریجی زیبا در مقابل بهبود تدریجی: یک تمایز حیاتی

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

• بهبود تدریجی (Progressive Enhancement): این استراتژی با یک سطح پایه از محتوا و عملکرد اصلی شروع می‌شود که روی همه مرورگرها کار می‌کند. سپس لایه‌هایی از ویژگی‌های پیشرفته‌تر و تجربیات غنی‌تر را برای مرورگرهایی که می‌توانند از آن‌ها پشتیبانی کنند، اضافه می‌کنید. این یک رویکرد خوش‌بینانه و از پایین به بالا است.
• تنزل تدریجی زیبا (Graceful Degradation): این استراتژی با تجربه کامل و غنی از ویژگی‌ها شروع می‌شود. سپس برای شکست برنامه‌ریزی می‌کنید و زمانی که ویژگی‌ها، APIها یا منابع خاصی در دسترس نیستند یا خراب می‌شوند، جایگزین‌ها و عملکردهای جایگزین ارائه می‌دهید. این یک رویکرد عمل‌گرایانه و از بالا به پایین است که بر مقاومت‌پذیری تمرکز دارد.

این مقاله بر روی تنزل تدریجی زیبا تمرکز دارد—اقدام تدافعی برای پیش‌بینی شکست و اطمینان از اینکه اپلیکیشن شما فرو نپاشد. یک اپلیکیشن واقعاً قوی هر دو استراتژی را به کار می‌گیرد، اما تسلط بر تنزل تدریجی برای مدیریت ماهیت غیرقابل پیش‌بینی وب کلیدی است.

درک چشم‌انداز خطاهای جاوا اسکریپت

برای مدیریت موثر خطاها، ابتدا باید منبع آن‌ها را درک کنید. اکثر خطاهای فرانت‌اند در چند دسته اصلی قرار می‌گیرند:

• خطاهای شبکه (Network Errors): این‌ها از رایج‌ترین خطاها هستند. یک نقطه پایانی API ممکن است از کار افتاده باشد، اتصال اینترنت کاربر ممکن است ناپایدار باشد، یا یک درخواست ممکن است زمانش به پایان برسد (time out). یک فراخوانی ناموفق `fetch()` یک مثال کلاسیک است.
• خطاهای زمان اجرا (Runtime Errors): این‌ها باگ‌هایی در کد جاوا اسکریپت شما هستند. مقصران رایج شامل `TypeError` (مثلاً `Cannot read properties of undefined`)، `ReferenceError` (مثلاً دسترسی به متغیری که وجود ندارد)، یا خطاهای منطقی هستند که به یک وضعیت ناسازگار منجر می‌شوند.
• شکست اسکریپت‌های شخص ثالث (Third-Party Script Failures): اپلیکیشن‌های وب مدرن به مجموعه‌ای از اسکریپت‌های خارجی برای تحلیل‌ها، تبلیغات، ویجت‌های پشتیبانی مشتری و موارد دیگر متکی هستند. اگر یکی از این اسکریپت‌ها نتواند بارگیری شود یا حاوی باگ باشد، به طور بالقوه می‌تواند رندر را مسدود کرده یا باعث خطاهایی شود که کل اپلیکیشن شما را از کار بیندازد.
• مشکلات محیطی/مرورگر (Environmental/Browser Issues): یک کاربر ممکن است از مرورگر قدیمی‌تری استفاده کند که از یک Web API خاص پشتیبانی نمی‌کند، یا یک افزونه مرورگر ممکن است با کد اپلیکیشن شما تداخل داشته باشد.

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

پایه و اساس: مدیریت خطای ناهمزمان با `try...catch`

بلوک `try...catch...finally` اساسی‌ترین ابزار در جعبه ابزار مدیریت خطای ماست. با این حال، پیاده‌سازی کلاسیک آن فقط برای کدهای همزمان (synchronous) کار می‌کند.

مثال همزمان:

try {
let data = JSON.parse(invalidJsonString);
// ... پردازش داده‌ها
} catch (error) {
console.error("Failed to parse JSON:", error);
// اکنون، به زیبایی تنزل دهید...
} finally {
// این کد صرف نظر از وجود خطا اجرا می‌شود، مثلاً برای پاک‌سازی.
}

در جاوا اسکریپت مدرن، اکثر عملیات ورودی/خروجی (I/O) ناهمزمان هستند و عمدتاً از Promiseها استفاده می‌کنند. برای این‌ها، ما دو راه اصلی برای گرفتن خطاها داریم:

۱. متد `.catch()` برای Promiseها:

fetch('https://api.example.com/data')
.then(response => response.json())
.then(data => { /* از داده‌ها استفاده کنید */ })
.catch(error => {
console.error("API call failed:", error);
// منطق جایگزین را اینجا پیاده‌سازی کنید
});

۲. `try...catch` با `async/await`:

async function fetchData() {
try {
const response = await fetch('https://api.example.com/data');
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
// از داده‌ها استفاده کنید
} catch (error) {
console.error("Failed to fetch data:", error);
// منطق جایگزین را اینجا پیاده‌سازی کنید
}
}

تسلط بر این اصول، پیش‌نیاز پیاده‌سازی الگوهای پیشرفته‌تری است که در ادامه می‌آیند.

الگوی ۱: جایگزین‌های سطح کامپوننت (مرزهای خطا)

یکی از بدترین تجربیات کاربری زمانی است که یک بخش کوچک و غیرحیاتی از UI با شکست مواجه می‌شود و کل اپلیکیشن را با خود پایین می‌کشد. راه‌حل این است که کامپوننت‌ها را ایزوله کنیم، تا خطای یکی از آن‌ها به بقیه سرایت نکند و همه چیز را از کار نیندازد. این مفهوم به طور مشهور به عنوان "مرزهای خطا" (Error Boundaries) در فریمورک‌هایی مانند React پیاده‌سازی شده است.

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

پیاده‌سازی در جاوا اسکریپت خالص (Vanilla)

شما می‌توانید یک تابع ساده ایجاد کنید که منطق رندر هر کامپوننت UI را در بر می‌گیرد.

function createErrorBoundary(componentElement, renderFunction) {
try {
// تلاش برای اجرای منطق رندر کامپوننت
renderFunction();
} catch (error) {
console.error(`Error in component: ${componentElement.id}`, error);
// تنزل تدریجی زیبا: رندر یک UI جایگزین
componentElement.innerHTML = `<div class="error-fallback">
<p>متاسفیم، این بخش قابل بارگذاری نبود.</p>
</div>`;
}
}

مثال کاربرد: یک ویجت آب و هوا

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

const weatherWidget = document.getElementById('weather-widget');

createErrorBoundary(weatherWidget, () => {
// منطق رندر اصلی و بالقوه شکننده
const weatherData = getWeatherData(); // این ممکن است خطا پرتاب کند
if (!weatherData) {
throw new Error("Weather data is not available.");
}
weatherWidget.innerHTML = `<h3>آب و هوای فعلی</h3><p>${weatherData.temp}°C</p>`;
});

با این الگو، اگر `getWeatherData()` شکست بخورد، به جای متوقف کردن اجرای اسکریپت، کاربر یک پیام مودبانه به جای ویجت خواهد دید، در حالی که بقیه اپلیکیشن—فید اصلی اخبار، ناوبری و غیره—کاملاً کاربردی باقی می‌ماند.

الگوی ۲: تنزل سطح ویژگی با پرچم‌های ویژگی (Feature Flags)

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

چگونه برای بازیابی خطا کار می‌کند:

1. پیکربندی از راه دور: اپلیکیشن شما در هنگام راه‌اندازی یک فایل پیکربندی را دریافت می‌کند که حاوی وضعیت همه پرچم‌های ویژگی است (مثلاً `{"isLiveChatEnabled": true, "isNewDashboardEnabled": false}`).
2. مقداردهی اولیه شرطی: کد شما قبل از مقداردهی اولیه ویژگی، پرچم را بررسی می‌کند.
3. جایگزین محلی: شما می‌توانید این را با یک بلوک `try...catch` برای یک جایگزین محلی قوی ترکیب کنید. اگر اسکریپت ویژگی نتواند مقداردهی اولیه شود، می‌توان با آن طوری رفتار کرد که انگار پرچم خاموش است.

مثال: یک ویژگی جدید چت زنده

// پرچم‌های ویژگی که از یک سرویس دریافت شده‌اند
const featureFlags = { isLiveChatEnabled: true };

function initializeChat() {
if (featureFlags.isLiveChatEnabled) {
try {
// منطق پیچیده مقداردهی اولیه برای ویجت چت
const chatSDK = new ThirdPartyChatSDK({ apiKey: '...' });
chatSDK.render('#chat-container');
} catch (error) {
console.error("Live Chat SDK failed to initialize.", error);
// تنزل تدریجی زیبا: به جای آن یک لینک 'تماس با ما' نشان دهید
document.getElementById('chat-container').innerHTML =
'<a href="/contact">نیاز به کمک دارید؟ تماس با ما</a>';
}
}
}

این رویکرد به شما دو لایه دفاعی می‌دهد. اگر یک باگ بزرگ در SDK چت پس از دیپلوی تشخیص دهید، می‌توانید به سادگی پرچم `isLiveChatEnabled` را در سرویس پیکربندی خود به `false` تغییر دهید، و همه کاربران فوراً بارگیری ویژگی خراب را متوقف خواهند کرد. علاوه بر این، اگر مرورگر یک کاربر خاص با SDK مشکلی داشته باشد، `try...catch` تجربه او را به یک لینک تماس ساده تنزل می‌دهد بدون نیاز به مداخله کامل سرویس.

الگوی ۳: جایگزین‌های داده و API

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

زیر-الگو: استفاده از داده‌های کهنه/کش شده

اگر نمی‌توانید داده‌های تازه دریافت کنید، بهترین گزینه بعدی اغلب داده‌های کمی قدیمی‌تر است. شما می‌توانید از `localStorage` یا یک service worker برای کش کردن پاسخ‌های موفق API استفاده کنید.

async function getAccountDetails() {
const cacheKey = 'accountDetailsCache';
try {
const response = await fetch('/api/account');
const data = await response.json();
// پاسخ موفق را با یک برچسب زمانی کش کنید
localStorage.setItem(cacheKey, JSON.stringify({ data, timestamp: Date.now() }));
return data;
} catch (error) {
console.warn("API fetch failed. Attempting to use cache.");
const cached = localStorage.getItem(cacheKey);
if (cached) {
// مهم: به کاربر اطلاع دهید که داده‌ها زنده نیستند!
showToast("داده‌های کش شده نمایش داده می‌شود. امکان دریافت آخرین اطلاعات وجود نداشت.");
return JSON.parse(cached).data;
}
// اگر کش وجود نداشته باشد، باید خطا را برای مدیریت در سطح بالاتر پرتاب کنیم.
throw new Error("API and cache are both unavailable.");
}
}

زیر-الگو: داده‌های پیش‌فرض یا ساختگی

برای عناصر UI غیرضروری، نشان دادن یک وضعیت پیش‌فرض می‌تواند بهتر از نشان دادن یک خطا یا یک فضای خالی باشد. این به ویژه برای مواردی مانند توصیه‌های شخصی‌سازی شده یا فیدهای فعالیت اخیر مفید است.

async function getRecommendedProducts() {
try {
const response = await fetch('/api/recommendations');
return await response.json();
} catch (error) {
console.error("Could not fetch recommendations.", error);
// بازگشت به یک لیست عمومی و غیرشخصی
return [
{ id: 'p1', name: 'پرفروش‌ترین کالا الف' },
{ id: 'p2', name: 'کالای محبوب ب' }
];
}
}

زیر-الگو: منطق تلاش مجدد API با عقب‌نشینی نمایی (Exponential Backoff)

گاهی اوقات خطاهای شبکه گذرا هستند. یک تلاش مجدد ساده می‌تواند مشکل را حل کند. با این حال، تلاش مجدد فوری می‌تواند یک سرور در حال تقلا را تحت فشار قرار دهد. بهترین روش استفاده از "عقب‌نشینی نمایی" است—بین هر تلاش مجدد به طور فزاینده‌ای زمان بیشتری صبر کنید.

async function fetchWithRetry(url, options, retries = 3, delay = 1000) {
try {
return await fetch(url, options);
} catch (error) {
if (retries > 0) {
console.log(`Retrying in ${delay}ms... (${retries} retries left)`);
await new Promise(resolve => setTimeout(resolve, delay));
// تاخیر را برای تلاش مجدد بعدی دو برابر کنید
return fetchWithRetry(url, options, retries - 1, delay * 2);
} else {
// همه تلاش‌های مجدد شکست خوردند، خطای نهایی را پرتاب کنید
throw new Error("API request failed after multiple retries.");
}
}
}

الگوی ۴: الگوی شیء پوچ (Null Object Pattern)

یک منبع مکرر `TypeError` تلاش برای دسترسی به یک ویژگی روی `null` یا `undefined` است. این اغلب زمانی اتفاق می‌افتد که شیئی که انتظار داریم از یک API دریافت کنیم، بارگیری نمی‌شود. الگوی شیء پوچ یک الگوی طراحی کلاسیک است که این مشکل را با بازگرداندن یک شیء خاص که با رابط مورد انتظار مطابقت دارد اما رفتار خنثی و بدون عملیات (no-op) دارد، حل می‌کند.

به جای اینکه تابع شما `null` برگرداند، یک شیء پیش‌فرض برمی‌گرداند که کدی که از آن استفاده می‌کند را خراب نمی‌کند.

مثال: یک پروفایل کاربری

بدون الگوی شیء پوچ (شکننده):

async function getUser(id) {
try {
// ... دریافت کاربر
return user;
} catch (error) {
return null; // این خطرناک است!
}
}

const user = await getUser(123);
// اگر getUser شکست بخورد، این خطا پرتاب می‌شود: "TypeError: Cannot read properties of null (reading 'name')"
document.getElementById('welcome-banner').textContent = `خوش آمدید، ${user.name}!`;

با الگوی شیء پوچ (مقاوم):

const createGuestUser = () => ({
name: 'مهمان',
isLoggedIn: false,
permissions: [],
getAvatarUrl: () => '/images/default-avatar.png'
});

async function getUser(id) {
try {
const response = await fetch(`/api/users/${id}`);
if (!response.ok) return createGuestUser();
return await response.json();
} catch (error) {
return createGuestUser(); // در صورت شکست، شیء پیش‌فرض را برگردانید
}
}

const user = await getUser(123);
// این کد اکنون با خیال راحت کار می‌کند، حتی اگر فراخوانی API شکست بخورد.
document.getElementById('welcome-banner').textContent = `خوش آمدید، ${user.name}!`;
if (!user.isLoggedIn) { /* دکمه ورود را نشان بده */ }

این الگو کد مصرف‌کننده را به شدت ساده می‌کند، زیرا دیگر نیازی به پر کردن آن با بررسی‌های null (`if (user && user.name)`) نیست.

الگوی ۵: غیرفعال‌سازی انتخابی عملکرد

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

این اغلب به تشخیص ویژگی (feature detection) گره خورده است—بررسی اینکه آیا یک API مرورگر قبل از تلاش برای استفاده از آن در دسترس است یا خیر.

مثال: یک ویرایشگر متن غنی (Rich Text Editor)

یک ویرایشگر متن را با دکمه‌ای برای آپلود تصاویر تصور کنید. این دکمه به یک نقطه پایانی API خاص متکی است.

// در حین مقداردهی اولیه ویرایشگر
const imageUploadButton = document.getElementById('image-upload-btn');

fetch('/api/upload-status')
.then(response => {
if (!response.ok) {
// سرویس آپلود از کار افتاده است. دکمه را غیرفعال کنید.
imageUploadButton.disabled = true;
imageUploadButton.title = 'آپلود تصاویر به طور موقت در دسترس نیست.';
}
})
.catch(() => {
// خطای شبکه، همچنین غیرفعال کنید.
imageUploadButton.disabled = true;
imageUploadButton.title = 'آپلود تصاویر به طور موقت در دسترس نیست.';
});

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

مثال دیگر بررسی قابلیت‌های مرورگر است:

const copyButton = document.getElementById('copy-text-btn');

if (!navigator.clipboard || !navigator.clipboard.writeText) {
// Clipboard API پشتیبانی نمی‌شود. دکمه را پنهان کنید.
copyButton.style.display = 'none';
} else {
// شنونده رویداد را متصل کنید
copyButton.addEventListener('click', copyTextToClipboard);
}

لاگ‌گیری و نظارت: پایه و اساس بازیابی

شما نمی‌توانید از خطاهایی که از وجودشان بی‌خبرید، به زیبایی تنزل دهید. هر الگوی مورد بحث در بالا باید با یک استراتژی لاگ‌گیری قوی همراه باشد. وقتی یک بلوک `catch` اجرا می‌شود، کافی نیست که فقط یک جایگزین به کاربر نشان دهید. شما باید خطا را نیز به یک سرویس از راه دور لاگ کنید تا تیم شما از مشکل آگاه شود.

پیاده‌سازی یک کنترل‌کننده خطای سراسری (Global Error Handler)

اپلیکیشن‌های مدرن باید از یک سرویس نظارت خطای اختصاصی (مانند Sentry، LogRocket یا Datadog) استفاده کنند. ادغام این سرویس‌ها آسان است و زمینه بسیار بیشتری نسبت به یک `console.error` ساده فراهم می‌کنند.

شما همچنین باید کنترل‌کننده‌های سراسری را برای گرفتن هر خطایی که از بلوک‌های `try...catch` خاص شما عبور می‌کند، پیاده‌سازی کنید.

// برای خطاهای همزمان و استثناهای مدیریت نشده
window.onerror = function(message, source, lineno, colno, error) {
// این داده‌ها را به سرویس لاگ‌گیری خود ارسال کنید
ErrorLoggingService.log({
message,
source,
lineno,
stack: error ? error.stack : null
});
// برای جلوگیری از مدیریت خطای پیش‌فرض مرورگر (مثلاً پیام کنسول)، true برگردانید
return true;
};

// برای رد شدن‌های (rejections) مدیریت نشده promise
window.addEventListener('unhandledrejection', event => {
ErrorLoggingService.log({
reason: event.reason.message,
stack: event.reason.stack
});
});

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

نتیجه‌گیری: ساختن فرهنگ مقاومت‌پذیری

تنزل تدریجی زیبا چیزی فراتر از مجموعه‌ای از الگوهای کدنویسی است؛ این یک ذهنیت است. این تمرین برنامه‌نویسی تدافعی، پذیرش شکنندگی ذاتی سیستم‌های توزیع‌شده و اولویت دادن به تجربه کاربر بالاتر از هر چیز دیگری است.

با فراتر رفتن از یک `try...catch` ساده و پذیرش یک استراتژی چند لایه، می‌توانید رفتار اپلیکیشن خود را تحت فشار تغییر دهید. به جای یک سیستم شکننده که با اولین نشانه مشکل در هم می‌شکند، شما یک تجربه مقاوم و سازگار ایجاد می‌کنید که ارزش اصلی خود را حفظ کرده و اعتماد کاربر را جلب می‌کند، حتی زمانی که همه چیز خراب می‌شود.

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

• کامپوننت‌ها را با مرزهای خطا ایزوله کنید.
• ویژگی‌ها را با پرچم‌های ویژگی کنترل کنید.
• شکست‌های داده را با کش کردن، مقادیر پیش‌فرض و تلاش‌های مجدد پیش‌بینی کنید.
• از خطاهای نوع با الگوی شیء پوچ جلوگیری کنید.
• فقط چیزی که خراب است را غیرفعال کنید، نه کل ویژگی را.
• همه چیز را، همیشه نظارت کنید.

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