بياناتنا كانت تتغير من تحت أقدامنا: كيف أنقذتنا ‘اللامتغيرية’ (Immutability) من جحيم الآثار الجانبية الخفية؟

يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه طول عمري في البرمجة. كنا شغالين على نظام داشبورد معقد لمتجر إلكتروني كبير، بيعرض بيانات المبيعات والأرباح والمخزون بشكل لحظي. كل شيء كان تمام في مرحلة التطوير، والأمور ماشية زي الحلاوة.

بعد إطلاق المشروع بأسبوع، بلشت توصلنا شكاوي غريبة. المدير المالي بيتصل معصّب وبيحكي: “يا أبو عمر، أرقام الأرباح على الداشبورد قاعدة بتتغير بشكل عشوائي! قبل دقيقة كانت 10,000 دولار، وهلأ صارت 7,500 دولار، وبعدها رجعت 10,000! شو القصة يا زلمة؟”.

صدقوني، “ولعت الدنيا” عنا في الفريق. قضينا يومين كاملين بنفتش في الكود، بنراجع سجلات قاعدة البيانات، وبنتأكد من الـ API. البيانات اللي بتوصل من السيرفر صحيحة 100%. المشكلة كانت بتصير “بعد” ما توصلنا البيانات، جوا التطبيق نفسه. حطينا `console.log` في كل زاوية من الكود لدرجة إنه المتصفح صار يعلّق. كنا حاسين حالنا بندور على إبرة في كومة قش، والبيانات بتتغير من تحت أقدامنا وإحنا مش عارفين مين السبب.

بعد تحقيق بوليسي طويل، اكتشفنا الجاني. كانت دالة بريئة المظهر، وظيفتها توليد تقرير عن المنتجات الأكثر مبيعًا في فئة معينة. هاي الدالة كانت بتاخد مصفوفة الطلبات الكاملة كوسيط (argument)، وبتستخدم الدالة `splice()` عشان تفلتر الطلبات اللي بدها ياها. المشكلة إنه `splice()` بتعدّل على المصفوفة الأصلية مباشرة! فكانت هاي الدالة، وبدون قصد، قاعدة بتحذف طلبات من الحالة (State) الرئيسية للتطبيق، ولما الداشبورد يرجع يحسب المجموع، بيلاقيه ناقص. كانت كارثة صامتة.

هذا الموقف المرير كان هو مدخلي الحقيقي لعالم “اللامتغيرية” (Immutability)، المفهوم اللي أنقذنا من هذا الجحيم، وصار حجر أساس في كل كود بكتبه اليوم.

ما هي “اللامتغيرية” (Immutability) وليش هي مهمة؟

بكل بساطة، اللامتغيرية هي مبدأ بيقول: “بمجرد إنشاء قيمة أو كائن (Object)، لا يمكن تغييره أبدًا”.

لحظة، كيف يعني ما بنقدر نغيره؟ وإذا بدي أضيف مستخدم جديد على قائمة المستخدمين أو أعدّل اسم مستخدم موجود؟

الجواب هو: أنت لا “تُعدّل” على القائمة القديمة، بل “تُنشئ” قائمة جديدة تمامًا تحتوي على التغيير المطلوب. تخيلها مثل عقد موقّع، ما بتقدر تمحي بند وتكتب فوقه، لازم تعمل ملحق جديد للعقد أو تكتب عقد جديد بالكامل. نفس المبدأ تمامًا.

“اللامتغيرية لا تعني أن حالتك لا تتغير، بل تعني أن الطريقة التي تتغير بها حالتك هي عبر إنشاء حالات جديدة بدلًا من تعديل الحالات القديمة.”

التغيرية (Mutability): العدو الخفي في الكود

المشكلة اللي واجهناها في قصتي سببها كان “التغيرية” (Mutability)، وهي السماح بتعديل البيانات بعد إنشائها. هاي الممارسة، مع إنها تبدو أسهل في البداية، إلا إنها بتفتح باب لثلاث مشاكل رئيسية:

1. الآثار الجانبية (Side Effects)

لما دالة (function) تعدّل على بيانات خارج نطاقها الخاص (مثل تعديل متغير عام أو وسيط تم تمريره لها)، بنسمي هاد “أثر جانبي”. هذا يجعل الكود غير متوقع. أنت تستدعي دالة لتنفيذ مهمة محددة، فتتفاجأ بأنها غيّرت شيئًا آخر في مكان لا تتوقعه، تمامًا مثلما فعلت دالة التقارير في قصتنا.

2. جحيم تتبع الأخطاء (Debugging Hell)

عندما تكون بياناتك قابلة للتغيير من أي مكان في الكود، يصبح تتبع مصدر الخطأ مهمة شبه مستحيلة. إذا تغيرت قيمة بشكل خاطئ، من هو المسؤول؟ هل هي الدالة A أم B أم C؟ رح تضطر تفتش في كل مكان يمكن أن يصل إلى هذه البيانات، وهذا مضيعة هائلة للوقت والجهد.

3. مشاكل التزامن (Concurrency Issues)

في التطبيقات الأكثر تعقيدًا التي تستخدم تعدد الخيوط (Multi-threading)، تصبح التغيرية كابوسًا حقيقيًا. تخيل خيطين (threads) يحاولان تعديل نفس الكائن في نفس الوقت. النتيجة؟ حالة من الفوضى وبيانات تالفة (Data corruption) يصعب جدًا إعادة إنتاجها أو إصلاحها.

تطبيق اللامتغيرية: كيف نبدأ؟ (مع أمثلة كود)

الكلام النظري جميل، لكن كيف نطبق هذا عمليًا؟ خلونا ناخذ أمثلة بلغة JavaScript، لأنها لغة مرنة جدًا في هذا الموضوع.

التعامل مع المصفوفات (Arrays) بشكل لامتغير

لنفترض أن لدينا مصفوفة من المستخدمين:

const users = [
  { id: 1, name: 'عمر' },
  { id: 2, name: 'فاطمة' },
];

الطريقة الخطأ (Mutable):

// إضافة عنصر جديد (يعدل المصفوفة الأصلية)
users.push({ id: 3, name: 'أحمد' }); 

// حذف عنصر (يعدل المصفوفة الأصلية)
users.splice(1, 1); 

هنا، أي جزء آخر من الكود يستخدم مصفوفة `users` الأصلية سيتأثر بهذه التغييرات بشكل غير متوقع.

الطريقة الصح (Immutable):

// إضافة عنصر جديد
const newUser = { id: 3, name: 'أحمد' };
const newUsers = [...users, newUser]; // استخدام Spread Syntax

// newUsers is now: [{id: 1, name: 'عمر'}, {id: 2, name: 'فاطمة'}, {id: 3, name: 'أحمد'}]
// The original `users` array is UNTOUCHED!

// حذف عنصر (مثلاً حذف فاطمة صاحبة id: 2)
const usersAfterDelete = users.filter(user => user.id !== 2);

// usersAfterDelete is now: [{id: 1, name: 'عمر'}]
// The original `users` array is still UNTOUCHED!

// تعديل عنصر (مثلاً تغيير اسم عمر إلى أبو عمر)
const updatedUsers = users.map(user => {
  if (user.id === 1) {
    return { ...user, name: 'أبو عمر' }; // ننشئ كائن جديد بالتعديل
  }
  return user; // نرجع الكائن الأصلي كما هو
});

// updatedUsers is now: [{id: 1, name: 'أبو عمر'}, {id: 2, name: 'فاطمة'}]
// The original `users` array is still UNTOUCHED!

لاحظوا كيف أننا في كل عملية نُنشئ مصفوفة جديدة (`newUsers`, `usersAfterDelete`, `updatedUsers`) بدلًا من تعديل المصفوفة الأصلية. المصفوفة `users` تبقى سليمة ونقية.

التعامل مع الكائنات (Objects) بشكل لامتغير

نفس المبدأ ينطبق على الكائنات.

const book = {
  title: 'مقدمة ابن خلدون',
  author: 'ابن خلدون',
  year: 1377
};

الطريقة الخطأ (Mutable):

// تعديل خاصية
book.year = 1378; // هذا يغير الكائن الأصلي مباشرة

الطريقة الصح (Immutable):

// تعديل خاصية
const updatedBook = {
  ...book, // انسخ كل الخصائص القديمة
  year: 1378, // ادهس على الخاصية التي تريد تغييرها بقيمة جديدة
  edition: 'طبعة محققة' // أضف خاصية جديدة
};

// updatedBook is a NEW object. The original `book` object is UNTOUCHED.

استخدام الـ Spread Syntax (`…`) هو صديقك المفضل في عالم اللامتغيرية في JavaScript.

نصائح من خبرة أبو عمر

• اجعلها العادة، لا الاستثناء: في البداية، قد تشعر أن كتابة الكود بهذه الطريقة تتطلب جهدًا إضافيًا. لكن مع الممارسة، ستصبح طبيعة ثانية. درّب نفسك على التفكير دائمًا: “كيف يمكنني إجراء هذا التغيير دون تعديل الأصل؟”.
• لا تخف من الأداء مبكرًا: قد يقول قائل: “إنشاء كائنات ومصفوفات جديدة في كل مرة سيء للأداء!”. في 99% من الحالات، هذا القلق في غير محله. محركات JavaScript الحديثة محسّنة جدًا لهذه العمليات، والفوائد التي تجنيها من استقرار الكود وسهولة صيانته تفوق بكثير أي تكلفة أداء ضئيلة. لا تقم بالتحسين إلا بعد أن تحدد مشكلة أداء حقيقية عبر قياسات (Profiling).
• استخدم Object.freeze() في التطوير: هي دالة في JavaScript تمنع تعديل الكائن (بشكل سطحي). استخدامها أثناء مرحلة التطوير يمكن أن يساعدك على كشف أي محاولة تعديل غير مقصودة لكائناتك، حيث ستطلق خطأ برمجيًا.

  const trulyImmutableUser = Object.freeze({ name: 'علي' });
  trulyImmutableUser.name = 'خالد'; // This will throw an error in strict mode
      

• استكشف مكتبات مساعدة: في المشاريع الكبيرة ذات الحالات المعقدة والمتشعبة، قد يصبح التعامل مع اللامتغيرية يدويًا مرهقًا. هنا يأتي دور مكتبات مثل Immer، التي تسمح لك بكتابة كود يبدو وكأنه متغير (mutable)، لكنها تقوم بتحويله إلى تحديث لامتغير آمن خلف الكواليس.

الخلاصة: كود أكثر أمانًا وعقل مرتاح 🧘‍♂️

تبني اللامتغيرية ليس مجرد تقنية برمجية، بل هو تغيير في العقلية. هو قرار واعي بكتابة كود يمكن التنبؤ بسلوكه، ويسهل تتبعه، وأقل عرضة للأخطاء الخفية. عندما تكون بياناتك لامتغيرة، فأنت تبني تطبيقك على أساس صلب.

في المرة القادمة التي تجد فيها نفسك على وشك كتابة `object.property = value` أو `array.push(item)`، توقف للحظة واسأل نفسك: “هل يمكنني فعل هذا بطريقة لامتغيرة؟”. صدقني، مستقبلك (وزملاؤك في الفريق) سيشكرونك على هذا القرار. إنه استثمار صغير في وقت الكتابة، ولكنه يوفر ساعات لا تحصى من ألم تصحيح الأخطاء.