ما هما تقسيم الشيفرة (code splitting) وهزّ الشجرة (tree shaking)؟

Question

IT Interview Practice · Accepted Answer

كلاهما يقلّل من JavaScript الذي يُنزّله المستخدمون. يقسّم **تقسيم الشيفرة (code splitting)** الحزمة إلى أجزاء تُحمَّل عند الطلب؛ ويزيل **هزّ الشجرة (tree shaking)** الشيفرة التي لا تستخدمها أبدًا. وهما متكاملان: قسّم *ما* يُحمَّل، وهزّ الشيفرة *الميتة* داخل كل جزء.

## تقسيم الشيفرة

بدلًا من حزمة واحدة كبيرة، يُقسَّم التطبيق بحيث يصير كل مسار أو ميزة ثقيلة جزءًا منفصلًا لا يُجلَب إلا عند الحاجة:

```js
// Route-based split: the dashboard code isn't downloaded until you visit it
const Dashboard = lazy(() => import("./routes/Dashboard")); // its own chunk

// Component-based split: heavy editor loaded on interaction
button.onclick = async () => {
  const { openEditor } = await import("./editor"); // fetched on click
  openEditor();
};
```

إن `import()` الديناميكي هو الإشارة — فأداة الحزم تُصدِر ملفًا منفصلًا عند تلك الحدود.

## هزّ الشجرة

تحلّل أداة الحزم بشكل ساكن `import`/`export` في وحدات ES وتُسقِط الصادرات التي لا يشير إليها شيء. وهي تعمل فقط مع **ESM** (الساكنة القابلة للتحليل) — لا مع `require` في CommonJS:

```js
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
```

وتعتمد على `"sideEffects": false` في `package.json` والاستيراد لكل دالة؛ وملفات البرميل (barrel files) أو الوحدات ذات الآثار الجانبية يمكن أن تُبطلها.

## المفاضلات

- الإفراط في التقسيم ← طلبات صغيرة كثيرة وشلالات (waterfalls)؛ اجمع الشيفرة المترابطة.
- هزّ الشجرة هشّ — فأثر جانبي مُعلَّم بشكل خاطئ يُبقي شيفرة ميتة.

## لماذا يهم

هاتان هما الرافعتان وراء «أرسل JS أقل». يريد القائمون على المقابلات أن تعرف أن تقسيم الشيفرة يقرر *ما يُحمَّل ومتى*، وأن هزّ الشجرة يقرر *ما يوجد فيها أصلًا*، وأن هزّ الشجرة يعتمد على ESM الساكنة — تفصيل يفصل بين مَن ضبطوا حزمةً فعلًا ومَن قرؤوا عنها فقط.

تقسيم الشيفرة

هزّ الشجرة

المفاضلات

لماذا يهم

أسئلة ذات صلة