در تحلیل استاتیک ماژول‌های جاوااسکریپت عمیق شوید. بیاموزید چگونه ابزارهایی مانند TypeScript و JSDoc از باگ‌ها جلوگیری کرده و کیفیت کد را در تیم‌های جهانی بهبود می‌بخشند.
تسلط بر بررسی نوع ماژول‌های جاوااسکریپت با تحلیل استاتیک: راهنمای جامع برای توسعه‌دهندگان جهانی
در دنیای توسعه نرم‌افزار مدرن، جاوااسکریپت به عنوان زبان وب فرمانروایی می‌کند. انعطاف‌پذیری و ماهیت پویای آن، همه چیز را از وب‌سایت‌های ساده گرفته تا اپلیکیشن‌های پیچیده در مقیاس سازمانی، قدرت بخشیده است. با این حال، همین انعطاف‌پذیری می‌تواند یک شمشیر دولبه باشد. با بزرگ شدن مقیاس پروژه‌ها و نگهداری آنها توسط تیم‌های توزیع‌شده و بین‌المللی، نبود یک سیستم نوع داخلی می‌تواند منجر به خطاهای زمان اجرا، بازسازی کد دشوار و تجربه چالش‌برانگیز برای توسعه‌دهندگان شود.
اینجاست که تحلیل استاتیک وارد عمل می‌شود. ابزارهای تحلیل استاتیک با تجزیه و تحلیل کد بدون اجرای آن، می‌توانند طیف گسترده‌ای از مشکلات بالقوه را قبل از رسیدن به مرحله تولید شناسایی کنند. این راهنما یک بررسی جامع از یکی از تأثیرگذارترین اشکال تحلیل استاتیک ارائه می‌دهد: بررسی نوع ماژول. ما بررسی خواهیم کرد که چرا این امر برای توسعه مدرن حیاتی است، ابزارهای پیشرو را تشریح می‌کنیم و توصیه‌های عملی و قابل اجرا برای پیاده‌سازی آن در پروژه‌های شما، صرف نظر از اینکه شما یا اعضای تیمتان در کجای جهان هستید، ارائه می‌دهیم.
تحلیل استاتیک چیست و چرا برای ماژول‌های جاوااسکریپت اهمیت دارد؟
در هسته خود، تحلیل استاتیک فرآیند بررسی کد منبع برای یافتن آسیب‌پذیری‌های بالقوه، باگ‌ها و انحراف از استانداردهای کدنویسی است، همه اینها بدون اجرای برنامه. آن را به عنوان یک بازبینی کد خودکار و بسیار پیچیده در نظر بگیرید.
وقتی تحلیل استاتیک برای ماژول‌های جاوااسکریپت به کار می‌رود، بر روی 'قراردادها' بین بخش‌های مختلف برنامه شما تمرکز می‌کند. یک ماژول مجموعه‌ای از توابع، کلاس‌ها یا متغیرها را صادر (export) می‌کند و ماژول‌های دیگر آنها را وارد (import) و استفاده می‌کنند. بدون بررسی نوع، این قرارداد بر اساس فرضیات و مستندات استوار است. برای مثال:
- ماژول A یک تابع `calculatePrice(quantity, pricePerItem)` را صادر می‌کند.
- ماژول B این تابع را وارد کرده و با `calculatePrice('5', '10.50')` فراخوانی می‌کند.
در جاوااسکریپت خالص، این ممکن است به جای یک محاسبه عددی، منجر به یک الحاق رشته‌ای غیرمنتظره (`"510.50"`) شود. این نوع خطا ممکن است تا زمانی که باعث یک باگ قابل توجه در تولید نشود، مورد توجه قرار نگیرد. بررسی نوع استاتیک این خطا را در ویرایشگر کد شما تشخیص می‌دهد و برجسته می‌کند که تابع انتظار عدد دارد، نه رشته.
برای تیم‌های جهانی، مزایا چند برابر می‌شود:
- وضوح در میان فرهنگ‌ها و مناطق زمانی: انواع (Types) به عنوان مستندات دقیق و بدون ابهام عمل می‌کنند. یک توسعه‌دهنده در توکیو می‌تواند فوراً ساختار داده مورد نیاز یک تابع نوشته شده توسط همکارش در برلین را درک کند، بدون نیاز به جلسه یا توضیح.
- بازسازی کد امن‌تر: هنگامی که نیاز به تغییر امضای یک تابع یا شکل یک شیء در یک ماژول دارید، یک بررسی‌کننده نوع استاتیک فوراً تمام مکان‌هایی را در کد که نیاز به به‌روزرسانی دارند به شما نشان می‌دهد. این به تیم‌ها اعتماد به نفس می‌دهد تا کد را بدون ترس از شکستن چیزی بهبود بخشند.
- ابزارهای ویرایشگر بهبود یافته: تحلیل استاتیک ویژگی‌هایی مانند تکمیل خودکار هوشمند کد (IntelliSense)، رفتن به تعریف (go-to-definition) و گزارش خطای درون‌خطی را تقویت می‌کند و بهره‌وری توسعه‌دهندگان را به طور چشمگیری افزایش می‌دهد.
تکامل ماژول‌های جاوااسکریپت: یک مرور سریع
برای درک بررسی نوع ماژول، درک خود سیستم‌های ماژول ضروری است. از نظر تاریخی، جاوااسکریپت هیچ سیستم ماژول بومی نداشت، که منجر به راه‌حل‌های مختلف جامعه-محور شد.
CommonJS (CJS)
CommonJS که توسط Node.js محبوب شد، از `require()` برای وارد کردن ماژول‌ها و `module.exports` برای صادر کردن آنها استفاده می‌کند. این سیستم همزمان (synchronous) است، به این معنی که ماژول‌ها را یکی یکی بارگذاری می‌کند، که برای محیط‌های سمت سرور که فایل‌ها از دیسک محلی خوانده می‌شوند، مناسب است.
مثال:
// utils.js
const PI = 3.14;
function circleArea(radius) {
return PI * radius * radius;
}
module.exports = { PI, circleArea };
// main.js
const { circleArea } = require('./utils.js');
console.log(circleArea(10));
ماژول‌های ECMAScript (ESM)
ESM سیستم ماژول رسمی و استاندارد شده برای جاوااسکریپت است که در ES2015 (ES6) معرفی شد. این سیستم از کلمات کلیدی `import` و `export` استفاده می‌کند. ESM ناهمزمان (asynchronous) است و برای کار در هر دو محیط مرورگر و سمت سرور مانند Node.js طراحی شده است. همچنین مزایای تحلیل استاتیک مانند 'tree-shaking' را ممکن می‌سازد—فرآیندی که در آن صادرات‌های استفاده نشده از بسته نهایی کد حذف می‌شوند و اندازه آن کاهش می‌یابد.
مثال:
// utils.js
export const PI = 3.14;
export function circleArea(radius) {
return PI * radius * radius;
}
// main.js
import { circleArea } from './utils.js';
console.log(circleArea(10));
توسعه مدرن جاوااسکریپت به طور گسترده‌ای از ESM طرفداری می‌کند، اما بسیاری از پروژه‌های موجود و بسته‌های Node.js هنوز از CommonJS استفاده می‌کنند. یک پیکربندی تحلیل استاتیک قوی باید قادر به درک و مدیریت هر دو باشد.
ابزارهای کلیدی تحلیل استاتیک برای بررسی نوع ماژول‌های جاوااسکریپت
چندین ابزار قدرتمند مزایای بررسی نوع استاتیک را به اکوسیستم جاوااسکریپت می‌آورند. بیایید برجسته‌ترین آنها را بررسی کنیم.
TypeScript: استاندارد بالفعل
TypeScript یک زبان منبع باز است که توسط مایکروسافت توسعه یافته و با افزودن تعاریف نوع استاتیک، بر پایه جاوااسکریپت ساخته شده است. این یک 'فرا مجموعه' (superset) از جاوااسکریپت است، به این معنی که هر کد معتبر جاوااسکریپت، کد معتبر TypeScript نیز هست. کد TypeScript به جاوااسکریپت ساده ترنسپایل (کامپایل) می‌شود که می‌تواند در هر مرورگر یا محیط Node.js اجرا شود.
چگونه کار می‌کند: شما انواع متغیرها، پارامترهای توابع و مقادیر بازگشتی خود را تعریف می‌کنید. سپس کامپایلر TypeScript (TSC) کد شما را در برابر این تعاریف بررسی می‌کند.
مثال با تایپینگ ماژول:
// services/math.ts
export interface CalculationOptions {
precision?: number; // پراپرتی اختیاری
}
export function add(a: number, b: number, options?: CalculationOptions): number {
const result = a + b;
if (options?.precision) {
return parseFloat(result.toFixed(options.precision));
}
return result;
}
// main.ts
import { add } from './services/math';
const sum = add(5.123, 10.456, { precision: 2 }); // صحیح: مجموع برابر با 15.58 است
const invalidSum = add('5', '10'); // خطا! تایپ‌اسکریپت این را در ویرایشگر مشخص می‌کند.
// آرگومان از نوع 'string' به پارامتر از نوع 'number' قابل اختصاص نیست.
پیکربندی برای ماژول‌ها: رفتار TypeScript توسط یک فایل `tsconfig.json` کنترل می‌شود. تنظیمات کلیدی برای ماژول‌ها عبارتند از:
"module": "esnext": به TypeScript می‌گوید که از آخرین سینتکس ماژول ECMAScript استفاده کند. گزینه‌های دیگر شامل `"commonjs"`، `"amd"` و غیره است."moduleResolution": "node": این رایج‌ترین تنظیم است. این به کامپایلر می‌گوید چگونه ماژول‌ها را با تقلید از الگوریتم تفکیک Node.js (بررسی `node_modules` و غیره) پیدا کند."strict": true: یک تنظیم بسیار توصیه شده که طیف گسترده‌ای از رفتارهای سختگیرانه بررسی نوع را فعال می‌کند و از بسیاری از خطاهای رایج جلوگیری می‌کند.
JSDoc: ایمنی نوع بدون ترنسپایل
برای تیم‌هایی که آماده پذیرش یک زبان جدید یا یک مرحله ساخت (build step) نیستند، JSDoc راهی برای افزودن حاشیه‌نویسی‌های نوع (type annotations) مستقیماً در کامنت‌های جاوااسکریپت فراهم می‌کند. ویرایشگرهای کد مدرن مانند Visual Studio Code و ابزارهایی مانند خود کامپایلر TypeScript می‌توانند این کامنت‌های JSDoc را بخوانند تا بررسی نوع و تکمیل خودکار را برای فایل‌های جاوااسکریپت ساده فراهم کنند.
چگونه کار می‌کند: شما از بلوک‌های کامنت ویژه (`/** ... */`) با تگ‌هایی مانند `@param`، `@returns` و `@type` برای توصیف کد خود استفاده می‌کنید.
مثال با تایپینگ ماژول:
// services/user-service.js
/**
* یک کاربر در سیستم را نشان می‌دهد.
* @typedef {Object} User
* @property {number} id - شناسه منحصر به فرد کاربر.
* @property {string} name - نام کامل کاربر.
* @property {string} email - آدرس ایمیل کاربر.
* @property {boolean} [isActive] - فلگ اختیاری برای وضعیت فعال بودن.
*/
/**
* یک کاربر را با شناسه او واکشی می‌کند.
* @param {number} userId - شناسه کاربری که باید واکشی شود.
* @returns {Promise
برای فعال کردن این بررسی، می‌توانید یک فایل `jsconfig.json` در ریشه پروژه خود با محتوای زیر ایجاد کنید:
{
"compilerOptions": {
"checkJs": true,
"target": "es2020",
"module": "esnext"
},
"include": ["**/*.js"]
}
JSDoc یک راه عالی و کم-اصطکاک برای معرفی ایمنی نوع به یک کدبیس جاوااسکریپت موجود است، که آن را به گزینه‌ای عالی برای پروژه‌های قدیمی یا تیم‌هایی که ترجیح می‌دهند به جاوااسکریپت استاندارد نزدیک‌تر بمانند، تبدیل می‌کند.
Flow: یک دیدگاه تاریخی و موارد استفاده خاص
Flow که توسط فیسبوک توسعه یافته، یکی دیگر از بررسی‌کننده‌های نوع استاتیک برای جاوااسکریپت است. در روزهای اولیه رقیب قدرتمندی برای TypeScript بود. در حالی که TypeScript تا حد زیادی سهم ذهن جامعه جهانی توسعه‌دهندگان را به دست آورده است، Flow هنوز به طور فعال توسعه می‌یابد و در برخی سازمان‌ها، به ویژه در اکوسیستم React Native که ریشه‌های عمیقی دارد، استفاده می‌شود.
Flow با افزودن حاشیه‌نویسی‌های نوع با سینتکسی بسیار شبیه به TypeScript، یا با استنتاج انواع از کد کار می‌کند. برای فعال شدن در یک فایل، نیاز به یک کامنت `// @flow` در بالای آن فایل دارد.
در حالی که هنوز یک ابزار توانا است، برای پروژه‌های جدید یا تیم‌هایی که به دنبال بزرگترین پشتیبانی جامعه، مستندات و تعاریف نوع کتابخانه‌ها هستند، TypeScript به طور کلی انتخاب توصیه شده امروز است.
بررسی عمیق عملی: پیکربندی پروژه شما برای بررسی نوع استاتیک
بیایید از تئوری به عمل برویم. در اینجا نحوه راه‌اندازی یک پروژه برای بررسی قوی نوع ماژول آمده است.
راه‌اندازی یک پروژه TypeScript از ابتدا
این مسیر برای پروژه‌های جدید یا بازسازی‌های عمده است.
مرحله ۱: راه‌اندازی پروژه و نصب وابستگی‌ها
ترمینال خود را در یک پوشه پروژه جدید باز کرده و اجرا کنید:
npm init -y
npm install typescript --save-dev
مرحله ۲: ایجاد `tsconfig.json`
یک فایل پیکربندی با پیش‌فرض‌های توصیه شده ایجاد کنید:
npx tsc --init
مرحله ۳: پیکربندی `tsconfig.json` برای یک پروژه مدرن
فایل `tsconfig.json` تولید شده را باز کرده و آن را اصلاح کنید. در اینجا یک نقطه شروع قوی برای یک پروژه وب مدرن یا Node.js با استفاده از ماژول‌های ES آمده است:
{
"compilerOptions": {
/* بررسی نوع */
"strict": true, // فعال کردن تمام گزینه‌های سختگیرانه بررسی نوع.
"noImplicitAny": true, // ایجاد خطا در عبارات و تعاریفی که نوع 'any' ضمنی دارند.
"strictNullChecks": true, // فعال کردن بررسی‌های دقیق null.
/* ماژول‌ها */
"module": "esnext", // مشخص کردن نحوه تولید کد ماژول.
"moduleResolution": "node", // تفکیک ماژول‌ها با استفاده از سبک Node.js.
"esModuleInterop": true, // فعال کردن سازگاری با ماژول‌های CommonJS.
"baseUrl": "./src", // دایرکتوری پایه برای تفکیک نام ماژول‌های غیرنسبی.
"paths": { // ایجاد نام‌های مستعار برای وارد کردن‌های تمیزتر.
"@components/*": ["components/*"],
"@services/*": ["services/*"]
},
/* پشتیبانی جاوااسکریپت */
"allowJs": true, // اجازه دادن به کامپایل فایل‌های جاوااسکریپت.
/* خروجی */
"outDir": "./dist", // هدایت ساختار خروجی به این دایرکتوری.
"sourceMap": true, // تولید فایل '.map' متناظر.
/* زبان و محیط */
"target": "es2020", // تنظیم نسخه زبان جاوااسکریپت برای جاوااسکریپت خروجی.
"lib": ["es2020", "dom"] // مشخص کردن مجموعه‌ای از فایل‌های تعریف کتابخانه همراه.
},
"include": ["src/**/*"], // فقط فایل‌های موجود در پوشه 'src' را کامپایل کن.
"exclude": ["node_modules"]
}
این پیکربندی تایپینگ سختگیرانه را اعمال می‌کند، تفکیک ماژول مدرن را تنظیم می‌کند، قابلیت همکاری با بسته‌های قدیمی‌تر را فعال می‌کند و حتی نام‌های مستعار وارد کردن مناسبی ایجاد می‌کند (مثلاً `import MyComponent from '@components/MyComponent'`).
الگوها و چالش‌های رایج در بررسی نوع ماژول
همانطور که تحلیل استاتیک را ادغام می‌کنید، با چندین سناریوی رایج روبرو خواهید شد.
مدیریت وارد کردن‌های پویا (`import()`)
وارد کردن‌های پویا یک ویژگی مدرن جاوااسکریپت است که به شما امکان می‌دهد یک ماژول را در صورت تقاضا بارگذاری کنید، که برای تقسیم کد (code-splitting) و بهبود زمان بارگذاری اولیه صفحه عالی است. بررسی‌کننده‌های نوع استاتیک مانند TypeScript به اندازه کافی هوشمند هستند تا این را مدیریت کنند.
// utils/formatter.ts
export function formatDate(date: Date): string {
return date.toLocaleDateString('en-US');
}
// main.ts
async function showDate() {
if (userNeedsDate) {
const formatterModule = await import('./utils/formatter'); // TypeScript نوع formatterModule را استنتاج می‌کند
const formatted = formatterModule.formatDate(new Date());
console.log(formatted);
}
}
TypeScript می‌فهمد که عبارت `import()` یک Promise را برمی‌گرداند که به فضای نام ماژول (module's namespace) حل می‌شود. این به درستی `formatterModule` را تایپ می‌کند و تکمیل خودکار را برای صادرات‌های آن فراهم می‌کند.
تایپ کردن کتابخانه‌های شخص ثالث (DefinitelyTyped)
یکی از بزرگترین چالش‌ها، تعامل با اکوسیستم گسترده کتابخانه‌های جاوااسکریپت در NPM است. بسیاری از کتابخانه‌های محبوب اکنون با TypeScript نوشته شده‌اند و تعاریف نوع خود را همراه دارند. برای آنهایی که ندارند، جامعه جهانی توسعه‌دهندگان یک مخزن عظیم از تعاریف نوع با کیفیت بالا به نام DefinitelyTyped را نگهداری می‌کند.
شما می‌توانید این انواع را به عنوان وابستگی‌های توسعه (development dependencies) نصب کنید. به عنوان مثال، برای استفاده از کتابخانه محبوب `lodash` با انواع:
npm install lodash
npm install @types/lodash --save-dev
پس از این، هنگامی که `lodash` را به فایل TypeScript خود وارد می‌کنید، بررسی کامل نوع و تکمیل خودکار را برای تمام توابع آن دریافت خواهید کرد. این یک تغییر دهنده بازی برای کار با کد خارجی است.
پل زدن بین شکاف: قابلیت همکاری بین ماژول‌های ES و CommonJS
شما اغلب خود را در پروژه‌ای خواهید یافت که از ماژول‌های ES (`import`/`export`) استفاده می‌کند اما نیاز به مصرف یک وابستگی دارد که با CommonJS (`require`/`module.exports`) نوشته شده است. این می‌تواند باعث سردرگمی شود، به خصوص در مورد صادرات‌های پیش‌فرض (default exports).
فلگ `"esModuleInterop": true` در `tsconfig.json` بهترین دوست شما در اینجاست. این یک صادرات پیش‌فرض ترکیبی (synthetic default export) برای ماژول‌های CJS ایجاد می‌کند و به شما امکان می‌دهد از یک سینتکس وارد کردن تمیز و استاندارد استفاده کنید:
// بدون esModuleInterop، ممکن است مجبور باشید این کار را انجام دهید:
import * as moment from 'moment';
// با esModuleInterop: true، می‌توانید این کار را انجام دهید:
import moment from 'moment';
فعال کردن این فلگ برای هر پروژه مدرنی به شدت توصیه می‌شود تا این ناهماهنگی‌های فرمت ماژول را هموار کند.
تحلیل استاتیک فراتر از بررسی نوع: لینترها و فرمت‌کننده‌ها
در حالی که بررسی نوع بنیادی است، یک استراتژی تحلیل استاتیک کامل شامل ابزارهای دیگری است که با بررسی‌کننده نوع شما هماهنگ کار می‌کنند.
ESLint و پلاگین TypeScript-ESLint
ESLint یک ابزار لینتینگ قابل پلاگین برای جاوااسکریپت است. این فراتر از خطاهای نوع می‌رود تا قوانین سبکی را اعمال کند، ضدالگوها را پیدا کند و خطاهای منطقی را که سیستم نوع ممکن است از دست بدهد، تشخیص دهد. با پلاگین `typescript-eslint`، می‌تواند از اطلاعات نوع برای انجام بررسی‌های حتی قدرتمندتر استفاده کند.
برای مثال، می‌توانید ESLint را برای موارد زیر پیکربندی کنید:
- اعمال یک ترتیب وارد کردن ثابت (قانون `import/order`).
- هشدار در مورد `Promise`هایی که ایجاد شده‌اند اما مدیریت نمی‌شوند (مثلاً await نشده‌اند).
- جلوگیری از استفاده از نوع `any`، و وادار کردن توسعه‌دهندگان به صریح‌تر بودن.
Prettier برای سبک کد ثابت
در یک تیم جهانی، توسعه‌دهندگان ممکن است ترجیحات متفاوتی برای قالب‌بندی کد داشته باشند (تب در مقابل فاصله، سبک نقل قول و غیره). این تفاوت‌های جزئی می‌توانند در بازبینی‌های کد نویز ایجاد کنند. Prettier یک فرمت‌کننده کد خودرأی است که با قالب‌بندی مجدد خودکار کل کدبیس شما به یک سبک ثابت، این مشکل را حل می‌کند. با ادغام آن در گردش کار خود (مثلاً هنگام ذخیره در ویرایشگر یا به عنوان یک هوک pre-commit)، تمام بحث‌ها در مورد سبک را حذف کرده و اطمینان حاصل می‌کنید که کدبیس برای همه به طور یکنواخت خوانا است.
توجیه تجاری: چرا در تحلیل استاتیک برای تیم‌های جهانی سرمایه‌گذاری کنیم؟
پذیرش تحلیل استاتیک فقط یک تصمیم فنی نیست؛ این یک تصمیم تجاری استراتژیک با بازگشت سرمایه واضح است.
- کاهش باگ‌ها و هزینه‌های نگهداری: تشخیص خطاها در حین توسعه به طور تصاعدی ارزان‌تر از رفع آنها در تولید است. یک کدبیس پایدار و قابل پیش‌بینی به زمان کمتری برای اشکال‌زدایی و نگهداری نیاز دارد.
- بهبود فرآیند ورود توسعه‌دهندگان جدید و همکاری: اعضای جدید تیم، صرف نظر از موقعیت جغرافیایی‌شان، می‌توانند کدبیس را سریع‌تر درک کنند زیرا انواع به عنوان کد خود-مستند عمل می‌کنند. این زمان رسیدن به بهره‌وری را کاهش می‌دهد.
- افزایش مقیاس‌پذیری کدبیس: با رشد برنامه و تیم شما، تحلیل استاتیک یکپارچگی ساختاری مورد نیاز برای مدیریت پیچیدگی را فراهم می‌کند. این بازسازی در مقیاس بزرگ را امکان‌پذیر و ایمن می‌سازد.
- ایجاد یک "منبع واحد حقیقت": تعاریف نوع برای پاسخ‌های API یا مدل‌های داده مشترک شما به منبع واحد حقیقت برای هر دو تیم فرانت‌اند و بک‌اند تبدیل می‌شود و خطاهای یکپارچه‌سازی و سوء تفاهم‌ها را کاهش می‌دهد.
نتیجه‌گیری: ساخت اپلیکیشن‌های جاوااسکریپت قوی و مقیاس‌پذیر
ماهیت پویا و انعطاف‌پذیر جاوااسکریپت یکی از بزرگترین نقاط قوت آن است، اما لازم نیست به قیمت از دست دادن ثبات و پیش‌بینی‌پذیری تمام شود. با پذیرش تحلیل استاتیک برای بررسی نوع ماژول، شما یک شبکه ایمنی قدرتمند را معرفی می‌کنید که تجربه توسعه‌دهنده و کیفیت محصول نهایی را متحول می‌کند.
برای تیم‌های مدرن و توزیع‌شده در سطح جهان، ابزارهایی مانند TypeScript و JSDoc دیگر یک تجمل نیستند—آنها یک ضرورت هستند. آنها یک زبان مشترک از ساختارهای داده را فراهم می‌کنند که از موانع فرهنگی و زبانی فراتر می‌رود و به توسعه‌دهندگان امکان می‌دهد تا برنامه‌های پیچیده، مقیاس‌پذیر و قوی را با اطمینان بسازند. با سرمایه‌گذاری در یک پیکربندی تحلیل استاتیک محکم، شما فقط کد بهتری نمی‌نویسید؛ شما در حال ساختن یک فرهنگ مهندسی کارآمدتر، مشارکتی‌تر و موفق‌تر هستید.