يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.
اسمحوا لي أبدأ معكم بقصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه. كنا شغالين على نظام جديد لشركة توصيل، والمطلوب كان ميزة “ذكية” لتخطيط المسارات. الفكرة كانت بسيطة نظرياً: إيجاد أقصر طريق للسائق ليزور مجموعة من النقاط ويرجع للمستودع. أنا، وبكل ثقة، كتبت دالة تعاودية (Recursive Function) أنيقة جداً، بتحسب كل الطرق الممكنة وبتختار الأفضل. في الاختبارات الأولية على 3 أو 4 نقاط، كانت شغالة زي الحلاوة.
لكن يوم الكارثة، لما العميل جرب النظام على بيانات حقيقية فيها 15 نقطة توصيل… النظام تجمد. السيرفر توقف عن الاستجابة، ورسائل الخطأ “Timeout” صارت تملأ الشاشة. كانت الساعة 2 بالليل، وأنا بالمكتب لحالي بحاول أفهم “شو القصة؟ ليش الكود بموت؟”. كنت على وشك أفقد الأمل.
في هداك الوقت، مرّ من عندي مهندس مبتدئ معنا بالفريق، شاب ذكي اسمه أحمد. ألقى نظرة على الكود وسألني بهدوء: “عمي أبو عمر، مش إحنا بنحسب نفس المسارات الفرعية مرة ورا مرة؟ يعني الطريق من النقطة أ لـ ب لـ ج، بنرجع نحسبه واحنا بنجرّب طريق تاني؟ ليش ما نخزن نتيجة الحساب أول مرة وبس؟”.
سؤاله البسيط كان زي الصاعقة. إحنا ما كنا بس بنعيد حساب مسافات، إحنا كنا بنعيد حلّ مسائل كاملة مراراً وتكراراً. كنا، وبكل معنى الكلمة، “نعيد اختراع العجلة” ملايين المرات في كل ثانية. هذيك الليلة، ما صلحنا خطأ برمجي وبس، بل تبنينا فلسفة كاملة غيّرت طريقة تفكيرنا: فلسفة البرمجة الديناميكية.
ما هو جحيم “إعادة اختراع العجلة”؟
المشكلة اللي واجهتني اسمها التقني هو “التعقيد الأسي” (Exponential Time Complexity). ببساطة، كلما زاد حجم المدخلات (عدد نقاط التوصيل في قصتي) زيادة بسيطة، كان الوقت اللازم لإيجاد الحل يزداد بشكل انفجاري.
لنفهم الفكرة، دعونا نأخذ مثالاً كلاسيكياً وبسيطاً جداً: حساب متتالية فيبوناتشي (Fibonacci Sequence). القاعدة هي أن كل رقم هو مجموع الرقمين اللي قبله (…,1, 1, 2, 3, 5, 8). لو أردنا كتابة دالة لحساب الرقم N، الحل التعاودي المباشر سيبدو هكذا (باستخدام Python كمثال):
def fib(n):
if n <= 1:
return n
return fib(n-1) + fib(n-2)
هذا الكود يبدو بريئاً وأنيقاً، أليس كذلك؟ لكنه يخفي كارثة. لنرى ماذا يحدث عندما نحاول حساب fib(5):
لاحظوا الكارثة: لحساب fib(5)، احتجنا لحساب fib(3) مرتين، و fib(2) ثلاث مرات، وهكذا. كل استدعاء للدالة لا “يتذكر” أن ابن عمه قد قام بنفس الحساب قبل قليل! هذا هو بالضبط ما كان يحدث في نظام تخطيط المسارات الخاص بي، ولكن على نطاق أوسع وأكثر تعقيداً.
المنقذ يصل: البرمجة الديناميكية (Dynamic Programming)
البرمجة الديناميكية، أو “DP” كما نحب أن نسميها، ليست لغة برمجة أو إطار عمل، بل هي طريقة تفكير لحل المشاكل. فكرتها الجوهرية بسيطة بشكل عبقري: “إذا واجهتك مسألة فرعية قمت بحلها من قبل، لا تقم بحلها مرة أخرى. فقط استخدم الحل المحفوظ”.
لتطبيق هذه الفلسفة، لدينا طريقتان أساسيتان:
1. التخزين المؤقت (Memoization) – النهج من الأعلى للأسفل
هذه الطريقة هي الأقرب للحل التعاودي الطبيعي. الفكرة هي أن نحتفظ بالدالة التعاودية كما هي، ولكن نضيف “ذاكرة تخزين مؤقت” (Cache)، والتي تكون عادةً قاموساً (Dictionary) أو مصفوفة (Array). قبل أن نقوم بأي عملية حسابية، نتحقق أولاً: “هل قمنا بحساب هذه القيمة من قبل؟”.
- إذا نعم: نرجع القيمة المخزنة مباشرة.
- إذا لا: نقوم بالحساب، ثم نخزن النتيجة في الذاكرة المؤقتة قبل إرجاعها، لاستخدامها في المستقبل.
لنطبق هذا على مثال فيبوناتشي:
# ذاكرة التخزين المؤقت، نبدأها بالحلول الأساسية
memo = {0: 0, 1: 1}
def fib_memo(n):
# هل قمنا بحساب هذه القيمة من قبل؟
if n in memo:
return memo[n]
# إذا لا، قم بالحساب وخزّن النتيجة
result = fib_memo(n-1) + fib_memo(n-2)
memo[n] = result
return result
# الآن حساب fib_memo(50) سيتم في جزء من الثانية!
هذا التعديل البسيط يحوّل الخوارزمية من التعقيد الأسي (O(2^n)) إلى التعقيد الخطي (O(n)). تغيير بسيط له أثر هائل!
2. الجدولة (Tabulation) – النهج من الأسفل للأعلى
هذه الطريقة تتخذ منحى مختلفاً. بدلاً من البدء من المشكلة الكبيرة (الأعلى) والنزول للأسفل، نبدأ من أصغر الحلول (القاعدة) ونبني طريقنا للأعلى حتى نصل إلى الحل المطلوب.
في مثال فيبوناتشي، نحن نعلم أن fib(0)=0 و fib(1)=1. يمكننا استخدام هاتين القيمتين لحساب fib(2)، ثم نستخدم النتائج لحساب fib(3)، وهكذا، حتى نصل إلى fib(n). نحن نملأ “جدولاً” بالحلول خطوة بخطوة.
def fib_tab(n):
if n <= 1:
return n
# إنشاء جدول (مصفوفة) لتخزين النتائج
# حجم الجدول n+1 لأننا نريد الوصول إلى F[n]
table = [0] * (n + 1)
table[1] = 1
# ملء الجدول من الأسفل للأعلى
for i in range(2, n + 1):
table[i] = table[i-1] + table[i-2]
return table[n]
# هذه الطريقة أيضاً سريعة جداً وتتجنب عمق التعاود (Recursion Depth)
نصيحة من أبو عمر: بشكل عام، طريقة التخزين المؤقت (Memoization) أسهل في التحويل من حل تعاودي ساذج. أما الجدولة (Tabulation) فتكون أحياناً أكثر كفاءة لأنها تتجنب الحمل الزائد لاستدعاءات الدوال (function call overhead) وقد تستهلك ذاكرة أقل في بعض الحالات.
متى أفكر في استخدام البرمجة الديناميكية؟
هذا هو السؤال الذهبي. البرمجة الديناميكية ليست حلاً لكل المشاكل، بل هي مناسبة لنوع معين من المشاكل التي تمتلك خاصيتين رئيسيتين:
- المسائل الفرعية المتداخلة (Overlapping Subproblems): هذا ما رأيناه في فيبوناتشي. الخوارزمية تحتاج إلى حل نفس المسألة الفرعية مراراً وتكراراً. البرمجة الديناميكية تستغل هذا التكرار لتخزين النتائج.
- البنية التحتية المثلى (Optimal Substructure): هذا يعني أن الحل الأمثل للمشكلة الكبيرة يمكن بناؤه من الحلول المثلى للمسائل الفرعية الأصغر منها. في مثال أقصر طريق، أقصر طريق من المدينة (أ) إلى (د) مروراً بـ (ب) و(ج) يجب أن يحتوي على أقصر طريق من (أ) إلى (ب)، وأقصر طريق من (ب) إلى (ج)، وهكذا.
إذا رأيت هاتين الخاصيتين في مشكلة ما، فهذه إشارة قوية أن البرمجة الديناميكية قد تكون هي الحل.
الخلاصة: لا تعيد اختراع العجلة! ⚙️
البرمجة الديناميكية قد يبدو اسماً مخيفاً، لكنها في جوهرها مبدأ بسيط: “لا تحلّ نفس المشكلة مرتين”. سواء كنت تبني نظاماً مالياً، أو خوارزمية لمعالجة الصور، أو مخططاً للوجستيات، ستواجه حتماً مشاكل يمكن حلها بكفاءة أكبر عبر تذكر الحسابات السابقة.
في المرة القادمة التي تجد فيها أن الكود الخاص بك بطيء بشكل غير مبرر عند زيادة حجم المدخلات، توقف لحظة واسأل نفسك سؤال أحمد البسيط: “هل أنا أعيد اختراع العجلة؟ هل أقوم بحسابات متكررة؟”. قد يكون الجواب هو مفتاحك للانتقال من جحيم التعقيد الأسي إلى نعيم الكفاءة الخطية.
نصيحة أخيرة: أفضل طريقة لتتقن البرمجة الديناميكية هي الممارسة. ابدأ بحل مسائل بسيطة على منصات مثل LeetCode أو HackerRank، ابدأ بفيبوناتشي، ثم انتقل لمسائل مثل “Coin Change” و “Knapsack”. مع كل مسألة تحلها، ستنمو قدرتك على التعرف على هذه الأنماط وتطبيق الحل المناسب بسهولة. حلّوا مسائل يا جماعة، فالممارسة هي التي تصنع الخبير.
وفقكم الله، ونراكم في مقال آخر بإذن الله.
