البرمجة الوظيفية (Functional Programming) 💯
.
.
البرمجة الوظيفية (Functional Programming) تعتبر نمط من الأنماط البرمجية اللي بتختلف عن النمط التقليدي اللي بنسميه الـ Imperative Programming.

الفكرة الأساسية في البرمجة الوظيفية إنها بتركز على استخدام الدوال (functions) كعنصر أساسي في كتابة الكود، وبتعتمد على فكرة إن الكود يكون واضح وسهل التتبع، بدون ما نغير الـ state أو البيانات بشكل مباشر.

———

📌 إيه اللي بيميز البرمجة الوظيفية؟

في البرمجة الوظيفية، بنستخدم حاجة اسمها pure functions، ودي دوال بتستقبل مدخلات (inputs) وتطلع مخرجات (outputs) من غير ما تأثر على أي حاجة بره الدالة نفسها.

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

كمان في البرمجة الوظيفية بنبعد تمامًا عن فكرة side effects، اللي هي تغيير في البيانات أو الـ state خارج الدالة. وده بيدي الكود ميزة إنه يبقى قابل للتوقع (predictable) وسهل الصيانة.

———

📌 الـ Higher-Order Functions؟

البرمجة الوظيفية بتعتمد بشكل كبير على نوع خاص من الدوال اسمه Higher-Order Functions. الدوال دي بتستقبل دوال تانية كمدخلات أو بتطلع دوال كمخرجات.

مثلًا في JavaScript عندنا دوال زي map, filter, reduce، ودي أمثلة ممتازة على الـ Higher-Order Functions.

الدوال دي بتخليك تقدر تعمل عمليات معقدة على البيانات بطريقة مختصرة ومنظمة، وبدون ما تكتب كود كتير. مثلًا لو عاوز تعدل قيم معينة في Array، بدل ما تستخدم for loop، ممكن تستخدم map واللي بتخليك تقدر تعيد بناء الـ Array بطريقة أسرع وأنضف.

———

📌 الـ Immutable Data

واحدة من المفاهيم الأساسية كمان في البرمجة الوظيفية هي immutable data، يعني البيانات مبتتغيرش. بدل ما نعدل على نفس الـ Array أو الـ Object، بنرجع نسخة جديدة من البيانات بعد التعديل.

ده بيدي الكود أمان أكتر، وبيمنع الأخطاء اللي ممكن تحصل لما البيانات تتغير بطريقة غير متوقعة.

البرمجة الوظيفية بتتطبق في لغات زي Haskell وElm بشكل كبير، لكن الأفكار دي كمان ممكن تتطبق في لغات زي JavaScript, Python وحتى Java و#C.

———

📌 ليه تستخدم البرمجة الوظيفية؟

- الكود بيكون واضح جدًا وسهل التتبع.

- التقليل من الأخطاء بفضل استخدام الـ pure functions.

- سهولة اختبار الكود.

- دعم الـ parallelism والـ concurrency بشكل أفضل.

يعني إيه Dead Code؟ 💀
.
.
تخيل معايا إنك في مشروع كبير، وكل يوم بتكتب فيه Features جديدة، وتعدّل على الكود القديم. مع الوقت، طبيعي جدًا يحصل تراكم أكواد غير مستخدمة…حاجات كانت مهمة زمان، بس دلوقتي مبقاش لها أي لازمة. الحاجات دي اسمها Dead Code.

الـ Dead Code هو أي كود موجود داخل المشروع، لكن لا يتم تنفيذه أو استخدامه في الـ Runtime. يعني الكود موجود في الـ Files، بس فعليًا ملوش أي تأثير على البرنامج أو الـ Output.

———

🔍 أمثلة على الـ Dead Code:

- أي Function مكتوبة ومحدش بينادي عليها في أي مكان في المشروع.
- أي Variables أو Constants متعرفة لكنها غير مستخدمة.
- أي Conditions مش ممكن تتحقق أبدًا (Unreachable Code).
- أي كود قديم استبدلناه بكود أحدث، بس نسينا نمسحه.

———

💡 طيب إيه المشكلة؟

يمكن تحس إن مفيش ضرر، لكن الحقيقة فيه مشاكل كتير:

1- زيادة حجم الكود: بيخلي المشروع تقيل ومليان حاجات ملهاش لازمة.
2- صعوبة الصيانة: لما تيجي تصلّح Bug أو تعدّل Feature، هتلف وتدور.
3- ممكن حد يشوف Function موجودة ويظن إنها بتستخدم، فيبدأ يشتغل عليها وهو مش واخد باله إنها Dead.
4- أداء أبطأ في بعض الحالات: حتى لو مش بتتنفذ، وجودها ممكن يأثر على وقت الـ Build أو حجم الـ Bundle في الـ Frontend.
5- الـ Code Smell: علامة على إن المشروع مش Managed كويس، وده بيأثر على الـ Code Quality.

———

🛠 إزاي نكتشف الـ Dead Code؟

✅ في JavaScript/TypeScript:

- استخدم Tools زي ESLint مع Rule زي no-unused-vars أو no-unreachable.
- الـ ts-prune: أداة قوية بتحددلك الـ Exports اللي مش مستخدمة.
- الـ webpack-bundle-analyzer: يعرفك إيه اللي داخل في الـ Bundle ومش محتاجه.

✅ في لغات تانية زي Java أو #C:

- الـ IDE نفسه زي IntelliJ أو Visual Studio غالبًا بيحددلك الـ Unused Code بعلامة أو لون باهت.

———

وفقكم الله لكل خير 🌿