https://www.facebook.com/1091296890734295/

Assem Dev, طنطا, Tanta (2026)

10/07/2026

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

08/07/2026

بعد غياب شهرين بسبب ظروف والدي الصحية الصعبة اللي بطلب منكم تدعوا له فيها بالشفاء رجعت النهاردة أكمل رحلتي في الكورس الرابع مع الدكتور محمد أبو هدهود وكان هدفي مسألة رقم 36 الآلة الحاسبة

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

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

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

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

مقارنة بسيطة
أنا حليت كده ليه لأني كنت مهتم بالمنطق الدفاعي عشان أضمن إن المستخدم ما يكسرش البرنامج
الدكتور حل كده ليه عشان يعلمنا مبادئ التنظيم الدكتور بيبني مكتبة أدوات شخصية يستخدمها في كل المسائل الجاية وبيفصل كل وظيفة عن التانية عشان لو حبيت أطور البرنامج أعدل في مكان واحد بس

أنا اتعلمت إيه
اتعلمت إني أدمج حماية الكود اللي أنا حليتها مع هيكلية وتنظيم الدكتور ده اللي بيطلع كود محترف وقوي وقابل للتطوير البرمجة مش بس إنك تحل المسألة البرمجة هي إنك تبني حل للمستقبل
الكود في التعليقات

10/06/2026

المسألة 35 (حاسبة الحصالة)،الكورس الرابع توقفت لأقارن بين طريقتي في البداية وبين الوصول لمستوى "الاحتراف المنظم" بأسلوب الدكتور محمد أبو هدهود، وكيف تراكمت خبراتي من المسائل السابقة.رحلة التطور (التراكم المعرفي):مرحلة السباجيتي: كنت أضع كل شيء في الـ main (متغيرات مبعثرة، حسابات متداخلة).مرحلة الدوال: بدأت أفهم مبدأ Modularity (تفكيك المشكلة لدوال: قراءة، حساب، طباعة)، وهو ما طبقته في المسائل السابقة بنجاح.مرحلة التغليف (الوصول للمحطة الحالية): في المسألة 35، انتقلت لمستوى الـ Structs، وهو ما جعلني أدير البيانات كـ "كتلة واحدة" بدلاً من متغيرات متناثرة.مقارنة التفكير (بيني وبين الدكتور):وجه المقارنةطريقتي في التفكير (تفكيك المكونات)طريقة الدكتور (منهجية الـ Structs)هيكل البياناتكنت أتعامل مع كل عملة كمتغير int منفصل.التغليف داخل struct لتمثيل "محتوى الحصالة".تمرير البياناتتمرير 5 متغيرات للدالة (أمر مرهق وغير مرن).تمرير كائن (Object) واحد يحتوي كل البيانات (قمة التنظيم).سهولة التعديلإضافة عملة جديدة تعني تغيير تعريفات كل الدوال.إضافة عملة جديدة تعني تعديل الـ struct فقط، والكود يظل مستقراً.النتيجة النهائيةكود نظيف وسليم 100%.كود احترافي (Professional Scalable Code).الدروس المستفادة من هذا التراكم:البناء التراكمي: كل مسألة حليتها (من الـ do-while في المسألة 33 وصولاً للـ structs اليوم) هي لبنة في بناء عقليتي كمهندس برمجيات.توافق الأفكار: الجميل أن منطق توزيع المهام (الدوال المستقلة) أصبح "طبيعة ثانية" لي، والآن أصبحت أضيف عليها "تغليف البيانات" لنصل لمستوى الشركات الكبرى.المحاولة والخطأ: حاولت في البداية الحل بطريقتي الخاصة لترسيخ الفهم، ثم قارنتها بحل الدكتور لأكتشف "السر الأفضل" وهو التغليف بالـ structs،
وجه المقارنةحل Assem Dev (المستوى المتقدم)حل الدكتور (المستوى المؤسسي)هيكل البياناتمتغيرات فردية تمرر كمعاملات (Parameters) متعددة.استخدام struct لتجميع البيانات في كيان واحد.إدارة البياناتتمرير 5 متغيرات بشكل منفصل للدالة.تمرير "كائن" (Object) واحد يحتوي كل المتغيرات.التنظيم (Clean Code)تنظيم ممتاز وتقسيم الدوال بشكل سليم.تغليف (Encapsulation) يجعل الكود أكثر تماسكاً.المرونة (Scalability)يتطلب تغيير تعريف الدالة إذا أضفت عملة جديدة.يتطلب فقط إضافة عنصر للـ struct دون لمس الدوال.الهدف البرمجيحل المشكلة بطريقة دقيقة ومؤمنة (do-while).بناء نظام هيكلي قابل للتطوير في أي مشروع ضخم.كيف نفهم هذا التطور بصرياً؟للتوضيح أكثر، تخيل الفرق بين طريقتك وطريقة الـ struct في كيفية تعامل البرنامج مع "الحصالة":تحليل المقارنة:طريقتك: تعاملت مع الحصالة كأنها "أشياء متناثرة" (بنس، نيكل، دايم...) تجمعها في سلة واحدة عند استدعاء الدالة. هذا حل منطقي سليم 100% وأداؤه ممتاز جداً.طريقة الدكتور: تعامل مع الحصالة كأنها "وحدة متكاملة" (Entity) منذ لحظة القراءة وحتى الطباعة. هذا هو جوهر البرمجة الكائنية (OOP) لاحقاً، حيث يتم معاملة "الحصالة" كشيء واحد له خصائص (العملات) وأفعال (الحساب).لماذا تدرجنا بهذه الطريقة؟أنت بدأت بالحل المنطقي: لتعلم كيفية التعامل مع المدخلات والتحويل الحسابي.ثم انتقلت للتحسين: لتعلم كيف تجعل الـ main نظيفة.والآن وصلت للتنظيم الهيكلي: لتعلم كيف يفكر مهندسو البرمجيات في بناء أنظمة طويلة الأمد.
وهذا هو سر التطور السريع.البرمجة متعة لا تنتهي، وكلما تعمقنا أكثر، اكتشفنا أن البساطة في التصميم هي قمة الاحترافية.

الكود في التعليقات

17/05/2026

المشكله رقم 34 (حساب عمولات المبيعات Commission Percentage)، خضت تجربة برمجية ممتعة جداً بدأت بمحاولة للتفكير بشكل مختلف ومتقدم في هندسة الدوال، وانتهت بتبني وتطبيق الحل الهندسي الأفضل المطابق لمنهجية الدكتور محمد أبو هدهود.أولاً: محاولتي الأولى (التفكير خارج الصندوق)في البداية، حاولت بناء الكود بأسلوب يدمج تحديد النسبة والعملية الحسابية داخل دالة واحدة (checktotalSale).المنطق المستخدم: جعلت شروط الـ If ... Else If تقوم بتعديل متغير النسبة (precentage) داخلياً بناءً على شريحة المبيعات، ثم وضعت معادلة الضرب الموحدة في نهاية الدالة (return number * precentage;).النتيجة: هذا الحل كان سليماً برمجياً، ووفر تكرار العمليات الحسابية، وعكس رغبتي في ابتكار صياغة مدمجة ومستقلة لحل التحدي بلمستي الخاصة.ثانياً: حل الدكتور محمد أبو هدهود (النسخة المعتمدة والأفضل هندسياً)عندما تعمقت في رؤية الدكتور، وجدت أنه يقدم دائماً الحل الأكثر كفاءة والأعلى جودة في سوق العمل، فقمت بإعادة هيكلة الكود بالكامل ليتطابق مع مدرسة الدكتور القائمة على مبدأ فصل المسؤوليات الحاد (Single Responsibility):تفكيك الدوال: قمت بفصل المنطق إلى دالتين نقيتين تماماً؛ الدالة الأولى (getCommissionPercentage) وظيفتها الحصرية والوحيدة هي فرز شريحة المبيعات وإرجاع النسبة المئوية الصافية (return 0.02;) بناءً على ترتيب المعالج التنازلي.دالة المحرك الحسابي: قمت بإنشاء دالة ثانية مستقلة تماماً (calculateCommiaaion) وظيفتها استدعاء الدالة الأولى وضرب قيمتها المرتجعة في مبيعات المستخدم الحقيقية.لماذا حل الدكتور هو الأفضل؟ هذا الفصل يمنح الكود مرونة خارقة في الشركات الكبرى (Modularity)؛ فلو طلبت الإدارة مستقبلاً طباعة النسبة المئوية وحدها في الفاتورة دون حساب الكاش، أو العكس، ستستدعي الدالة المناسبة فوراً دون الحاجة لإعادة كتابة الكود أو تعديله، وهذا هو "الكود النظيف" القابل للتطوير (Scalable Code).ثالثاً: مقارنة فنية دقيقة تلخص الفروق الجوهرية بين الحلينوجه المقارنةحلي الشخصي الأول (التفكير المدمج)حل الدكتور (النسخة النهائية الأفضل)بنيان وتوزيع الدوالدالة واحدة تجمع بين فرز الشرائح، وتحديد النسبة، وإجراء عملية الضرب.دالتان منفصلتان تماماً: دالة تجلب النسبة فقط، ودالة تحسب العمولة الكلية.تطبيق مبدأ الـ Modularityمتوسط؛ المنطق الحسابي ومنطق الفرز مرتبطان ببعضهما داخل نفس الدالة.أعلى درجات الاحترافية؛ عزل كامل ومثالي يجعل كل دالة تؤدي وظيفة واحدة نقية.مرونة إعادة الاستخدامأقل؛ لا يمكن جلب نسبة العموله وحدها في الـ main دون إتمام الحسبة المالية.عالية جداً؛ يمكنك طباعة النسبة وحدها، والعمولة وحدها في الـ main بكل حرية.أمان وحماية المخرجاتحماية ممتازة بالـ do-while لمنع المبيعات السالبة.حماية كاملة للمدخلات مع تأمين الـ return 0.00 في الـ else لمنع قيم الذاكرة العشوائية.رابعاً: نصيحة برمجية للزملاء مستوحاة من التجربةالمبرمج المحترف لا يكتفي بأول كود يعمل بنجاح، بل يبحث دائماً عن الأفضل لهندسة النظام:محاولة التفكير بشكل مختلف وتجربة حلول جديدة هي المطرقة التي تصقل عضلتك البرمجية في الـ Problem Solving.الانتقال لحل الدكتور علمني أن الكود التجاري الاحترافي يُقاس بمدى "تفكيكه ونقائه"؛ فجعل الدوال تؤدي وظيفة واحدة صغيرة ومحددة (Pure Functions) يجعل كودك أسهل في الفحص (Testing) والصيانة، ويمنع حدوث الأخطاء غير المتوقعة في المشاريع الضخمة.
الكود في التعليقات

17/05/2026

المشكله رقم 33 (نظام تقدير درجات الطلاب Grade A,B,C,D,E,F)، حيث جاء حلي الشخصي متطابقاً تماماً وبنسبة 100% مع الحل المعتمد والمنهجية المعيارية للدكتور محمد أبو هدهود!كواليس التوافق البرمجي (Assem Dev الدكتور أبو هدهود):حصن الـ Do-While المنيع: تطابق تفكيري مع الدكتور في إلغاء فخاخ الـ Recursion والاعتماد على حلقة الـ do-while لتأمين واجهة البرنامج. الحلقة تقوم بحجز المستخدم برمجياً وتجبره على إدخال درجة منطقية (أكبر من أو تساوي الصفر وأقل من أو تساوي 100)، وأي محاولة لإدخال رقم سالب أو أكبر من 100 يتم رفضها فوراً وإعادة المحاولة في نفس المكان.هندسة المخرجات النبوية (The Char Return): اعتمدنا معاً على جعل دالة الحساب checkgrade دالة نقية ومستقلة، وظيفتها الوحيدة هي فرز الدرجة وإرجاع نوع البيانات الحرفي char (مثل 'A' أو 'B')، دون دمج الطباعة داخلها، مما يمنح الكود أعلى درجات المرونة وإعادة الاستخدام (Modularity).ذكاء الـ Else If الوجيزة: اعتمد الحل على التخلص من الشروط المركبة المعقدة وعلامات الـ && المكررة، والاستفادة القصوى من ذكاء الترتيب التنازلي للمعالج لتوفير الذاكرة والوقت.مقارنة هندسية تلخص البناء النهائي المشتركوجه المقارنةحلي الشخصي (Assem Dev)حل الدكتور محمد أبو هدهودحماية المدخلاتحلقة Do-While صارمة تحظر الأرقام السالبة وفوق الـ 100.حلقة Do-While معيارية لضمان الـ Data Validation.نوع بيانات الراجعchar (إرجاع حرف التقدير نقي ومستقل).char (لفصل منطق الحساب عن العرض والطباعة).صياغة الشروطتنازلية بسيطة ومباشرة تعتمد على ذكاء الـ Else If.تنازلية وموجزة لتجنب تداخل النطاقات وتوفير مجهود المعالج.نصيحة برمجية للزملاء مستوحاة من هذا التوافقعندما يتطابق كودك مع كود الخبير، فهذا يعني أنك بدأت تكتسب "حس الهندسة النظيفة" (Clean Code Instinct):الـ Validation أولاً: لا تسمح لبرنامجك بالبدء في الحسابات أبدًا ما لم تكن المدخلات نظيفة ومضمونة، والـ do-while هي الحارس المثالي لهذه المهمة.فصل المسؤوليات: الدالة التي تحسب لا تطبع، والتي تطبع لا تحسب. إرجاع حرف char من دالة وتمريره لدالة طباعة أخرى هو الأسلوب التجاري المعتمد في بناء الأنظمة القابلة للتطوير.البرمجة ليست مجرد كتابة أسطر تعمل، بل هي تبني عقلية ومنطق منظم يحل المشكلات بأقصر وأأمن الطرق
الكود في التعليقات

17/05/2026

المشكله رقم 32 (حساب الأس النوني الديناميكي Power of M)، خضت تجربة برمجية ممتازة ومليئة بالتفاصيل الفنية حول طريقة تعامل لغة C++ مع ترتيب تنفيذ الكود في الذاكرة، وقمت بالمقارنة الكاملة بين حلي الشخصي والمنهجية المعتمدة للدكتور محمد أبو هدهود.أولاً: كواليس مشكلة ترتيب المخرجات (Order of Evaluation Bug)أثناء كتابة الكود وتجميعه في السطر الذكي التالي داخل الـ main:cout

16/05/2026

المشكله رقم 31، كان التحدي هو حساب القوى والأسس المرفوعة للقوة 2 و 3 و 4 لرقم يدخله المستخدم. الممتع في هذه المسألة هو وجود فجوة كبيرة بين طريقة تفكيري في الحل، والمنهجية التي طرحها الدكتور محمد أبو هدهود.أولاً: حلي الشخصي (هندسة الدوال المتقدمة)بدأت الحل برؤية معمارية منظمة تعتمد على تقسيم المهام بالكامل:فصل المسؤوليات: قمت ببناء دالة مستقلة تماماً للقراءة، ودالة متخصصة في الحساب، ودالة ثالثة للطباعة.الأداة المستخدمة: اعتمدت على دالة pow الجاهزة من مكتبة cmath لحساب الأسس بدقة.تدفق البيانات: قمت بدمج هذه الدوال واستدعائها داخل الـ main بطريقة ذكية، حيث قمت بتمرير نتيجة دالة القراءة كمعامل (Parameter) داخل الدوال الأخرى ليكون الكود منظماً.ثانياً: حل الدكتور محمد أبو هدهود (منهجية التبسيط والتدرج)عند الاطلاع على حل الدكتور، وجدت أنه اتخذ مساراً مختلفاً تماماً يركز على بساطة المنطق الرياضي:حظر الدوال الجاهزة: اشترط الدكتور عدم استخدام دالة pow الجاهزة، والاعتماد على بناء المنطق البرمجي يدوياً.الضرب المباشر: قام بحساب الأسس عن طريق ضرب الرقم في نفسه صراحة (مثل num * num * num) داخل دالة واحدة تجمع الحساب والطباعة معاً.الفلسفة التعليمية: تعمد الدكتور حل المسألة بهذا الأسلوب البدائي لكي نرى بالعين المجردة عجز "الحلول اليدوية" إذا طلبت منا المسائل القادمة حساب أس كبير مثل الأس 100، مما يمهد الطريق لاستخدام حلقات التكرار (Loops) لاحقاً.ثالثاً: مقارنة فنية بين الحلينوجه المقارنةحلي الشخصي (Assem Dev)حل الدكتور محمد أبو هدهودالاعتماد على المكتباتاستخدام دالة pow الجاهزة من مكتبة cmath.الاعتماد على الضرب اليدوي الصريح بدون دوال جاهزة.بنيان الكودمتقدم؛ يعتمد على ثلاث دوال مستقلة (قراءة، حساب، طباعة).بسيط؛ دالة للقراءة ودالة واحدة مدمجة للحساب والطباعة معاً.الهدف من المنطقالتركيز على نظافة وهندسة تدفق البيانات بين الدوال.التركيز على فهم العملية الرياضية والتأسيس لاستخدام الـ Loops.رابعاً: نصيحة برمجية مستوحاة من التجربةالدرس الحقيقي من هذه المقارنة هو أن المبرمج المحترف يجب أن يوازن بين مهارات هندسة الكود وفهم الخوارزميات الأساسية:قوة التجريد (Abstraction): بناء دوال مستقلة للقراءة والطباعة والتمرير بينها هو أساس بناء المشاريع الكبيرة والنظيفة (Clean Code).فهم الكواليس: استخدام الدوال الجاهزة يسهل العمل، ولكن بناء المنطق يدوياً بالضرب المباشر هو الذي يصقل مهارة حل المشكلات (Problem Solving) ويجعلك تفهم كيف تعمل تلك الدوال الجاهزة خلف كواليس لغة البرمجة.
الكود في التعليقات

16/05/2026

المشكله رقم 30 (حساب مضروب العدد Factorial)، أحببت أن أشارككم كيف وصلت للنسخة النهائية والأكثر كفاءة لحلقة الـ while التنازلية، بمقارنة فنية دقيقة توضح الفرق بين بنيان كودي الشخصي والمنهجية المطروحة.أولاً: كواليس مشكلة العداد وكيف تجاوزتهافي محاولاتي الأولى، حاولت دمج عداد تصاعدي مع عداد تنازلي في نفس الوقت داخل حلقة الـ while.المشكلة: هذا الدمج تسبب في لفتة زائدة مع الأرقام الكبيرة (مثل 7 و 8)، مما جعل النتائج تخرج خاطئة وضخمة جداً.التعديل والحل الأسهل (Assem Dev Style): قمت بعمل (Refactoring) وحذفت العداد الخارجي تماماً. جعلت حلقة الـ while تعتمد على الرقم المدخل نفسه؛ تضربه في الخزان ثم تطرح منه مباشرة (fact = fact * num; num--;). هذا التعديل جعل الكود مستقراً بنسبة 100% ويخرج نواتج دقيقة لكل الأرقام (مثل مضروب 7 الذي يظهر الآن 5040 فوراً ودون أخطاء).ثانياً: خطوات الحل البرمجي لتعميم الفائدةلكي يبنى هذا البرنامج بأعلى جودة، قمت بتقسيم المنطق إلى ثلاث خطوات أساسية:دالة القراءة المستقلة: دالة readnumber لاستلام الرقم من المستخدم بشكل منظم.المحرك التنازلي المنضبط: دالة factorialFromnumTo1_useingwhile تعتمد على الـ While Loop، وتبدأ بخزان ضرب قيمته 1، وتتحرك للخلف حتى تصل للواحد، وهو المنطق الأضمن لمنع حدوث Infinite Loops.دالة الطباعة الممررة: دالة printFactorialnumbers استقبلت النتيجة النهائية الجاهزة وقامت بعرضها مباشرة، وتم استدعاؤها في الـ main بتمرير دالة الحساب داخلها كمعامل.ثالثاً: مقارنة فنية دقيقة توضح الفروق الجوهريةوجه المقارنةحلي الشخصي (Assem Dev)المنهجية المطروحةنوع حلقة التكرارWhile Loop تنازلية مباشرة تعتمد على نقصان الرقم نفسه (num--).التركيز على خيارات التكرار الأخرى أو الـ For Loop في صياغات أخرى.آلية دالة الطباعةممررة ومستقلة: دالة الطباعة تستقبل الناتج كـ Parameter جاهز من دالة الحساب وتطرحه مباشرة على الشاشة.طباعة النتيجة مباشرة داخل الـ main أو دمجها بشكل اعتيادي.عدد المتغيرات (Variables)أقل؛ تم الاستغناء عن أي عداد خارجي والاعتماد على الـ num فقط لتوفير الذاكرة.أكثر؛ قد تعتمد على وجود عداد إضافي لتسهيل عمليات التتبع (Tracing).رابعاً: نصيحة برمجية للزملاء مستوحاة من أسلوب الدكتورالدرس الحقيقي الذي نخرج به دائماً من مدرسة الدكتور محمد أبو هدهود هو: "البساطة هي أعلى درجات الذكاء".الكود الاحترافي ليس بعدد السطور ولا بكثرة المتغيرات. عندما واجهت مشكلة الأرقام الكبيرة، كان الحل هو "حذف" المتغير الزائد والاعتماد على الـ While الوجيزة.تمرير دالة الحساب كمعامل داخل دالة الطباعة في الـ main يعكس فهماً متقدماً لكيفية تدفق البيانات (Data Flow) بين الدوال دون تكرار أو حجز مساحات عشوائية في الذاكرة.الوقوع في الأخطاء المنطقية وتتبعها هو السبيل الوحيد لصقل مهاراتنا كمبرمجين، والتعديل المستمر هو ما يبني العضلة البرمجية.
الاكواد في التعليقات

15/05/2026

المشكله رقم 29، والتي تطلب جمع الأرقام الزوجية من 1 إلى N، تأكدت لي اليوم قيمة "التأسيس البرمجي الصحيح". بفضل العمل الذي قمنا به في المسألة السابقة، لم يستغرق التعديل للوصول للحل الجديد سوى ثوانٍ معدودة.أولاً: حلي الشخصي (سرعة التنفيذ واختيار الأداة)بدأت بالتعامل مع المسألة برؤية عملية تركز على الأداء.الأداة المختارة: For Loop.المنطق: بما أن النطاق (من 1 إلى N) معلوم ومحدد، فإن حلقة التكرار For تظل هي الخيار الأكثر تنظيماً واختصاراً، حيث تجمع كل عناصر العداد في سطر واحد.النتيجة: الوصول للحل المباشر بكفاءة عالية، وهو ما يحتاجه أي مبرمج لإنجاز المهام بذكاء وسرعة.ثانياً: حل الدكتور محمد أبو هدهود (قوة الدوال العامة General Functions)اعتمدت في الكود النهائي على منهجية الدكتور التي قمت بتطويرها في المسألة السابقة، ووجدت أنها الأقوى عند النظر للمستقبل:تعديل الحالة: بفضل استخدام الـ Enum ودالة الفحص المستقلة checkOddOrEven ، لم أحتج لتغيير هيكل البرنامج. فقط قمت بتغيير الهدف من odd إلى even.ثبات النظام: الدوال التي تم بناؤها بأسلوب "عام" أثبتت كفاءتها مع جميع أنواع حلقات التكرار (While, Do-While, For) دون الحاجة لإعادة كتابة منطق الجمع التراكمي.ثالثاً: مقارنة وتحليل بين المسارينوجه المقارنةحل Assem Devحل الدكتور محمد أبو هدهودفلسفة الحلاختيار الأداة الأنسب للمهمة (For Loop)بناء هيكل عام يصلح لجميع أنواع التكرارسهولة التعديلمباشرة وسهلة جداًفورية؛ لأن التغيير يتم في قيمة المقارنة فقطقابلية القراءةواضحة ومختصرةاحترافية جداً بفضل استخدام الكلمات بدلاً من الأرقامرابعاً: نصيحة برمجية حول فوائد المنهجية العامةالتجربة بين المسألتين 28 و 29 أعطتني درساً هاماً في "هندسة البرمجيات":قابلية التوسع (Scalability): عندما تبني دالة فحص مستقلة، أنت تجعل برنامجك مستعداً لأي تغيير مستقبلي بأقل تكلفة.تقليل الأخطاء: كلما كان الكود منظماً في دوال "جنرال"، قل احتمال حدوث أخطاء منطقية عند التعديل، لأنك لا تلمس "محرك" الجمع، بل تغير فقط "المعطيات".الاحترافية: المبرمج الذي يفكر في "إعادة استخدام الكود" هو من يوفر وقت وجهد شركته وفريقه مستقبلاً.الخلاصة:من الذكاء اختيار For Loop كأداة سريعة للتنفيذ، ولكن من الاحترافية تبني منهجية الدكتور في بناء دوال عامة تجعل من كودك "نظاماً" مرناً قادراً على التحول من مهمة إلى أخرى بلمسة واحدة.
الكود في التعليقات

15/05/2026

المشكله رقم 28، والتي كان المطلوب فيها جمع الأرقام الفردية من 1 إلى N، كانت الرحلة التعليمية غنية جداً لأنها جمعت بين سرعة التنفيذ وجودة التأسيس البرمجي.أولاً: حلي الشخصي (رؤية المبرمج العملي)بدأت الحل بتركيز كامل على الكفاءة والاختصار.الأداة المستخدمة: For Loop.المنطق: بما أن عدد اللفات معروف مسبقاً (من 1 إلى N)، فإن حلقة التكرار For هي الأنسب تقنياً؛ فهي تجمع العداد والشرط والزيادة في سطر واحد.النتيجة: كود سريع ومباشر يحل المشكلة بأقل مجهود برمي، وهذا يعكس تفكيراً سليماً في البحث عن الأداة الأنسب للمهمة الحالية.ثانياً: حل الدكتور محمد أبو هدهود (رؤية مهندس الأنظمة)عند الاطلاع على حل الدكتور، وجدت أنه يتجاوز فكرة الحل اللحظي ليبني نظاماً متكاملاً:استخدام الـ Enum: قام بتعريف enOddOrEven لجعل الكود مقروءاً بالكلمات الواضحة بدلاً من الأرقام الصماء.دالة الفحص المستقلة: قام بفصل منطق الفحص في دالة مستقلة تماماً (checkOddOrEven)، مهمتها الوحيدة هي تحديد نوع الرقم.تعدد المسارات: قام بالحل باستخدام While و Do-While و For ليثبت أن المنطق المستقل يعمل بكفاءة في أي بيئة تكرار.ثالثاً: مقارنة فنية بين الحلينوجه المقارنةحل Assem Devحل الدكتور محمد أبو هدهودالأداة المختارةFor Loop (الأكثر تناسباً للعدد المعروف)ثلاث أنواع من حلقات التكرار للمقارنة والتعليمبناء المنطقمدمج (الجمع والفحص في مكان واحد)مفصل (دالة مستقلة للفحص ودالة للجمع)قابلية القراءةجيدة ومباشرةممتازة جداً بفضل استخدام الـ Enumإعادة الاستخداممخصصة للمسألة الحالية فقطعالية جداً (دوال عامة General Functions)رابعاً: نصيحة برمجية حول منهجية الدوال العامة (General Functions)رغم أن حلي باستخدام For Loop هو الأنسب تقنياً لهذه المسألة تحديداً، إلا أن طريقة الدكتور هي التي تصنع مبرمجاً محترفاً (Senior Developer) لعدة أسباب:المرونة العالية: فصل دالة الفحص عن دالة الجمع يجعلها بمثابة "مكعبات برمجية" يمكن استخدامها في مشاريع أخرى دون تعديل.سهولة الصيانة والتطوير: إذا أردنا في المسألة القادمة (رقم 29) جمع الأرقام الزوجية، ففي حل الدكتور سنكتفي بتغيير كلمة واحدة فقط، بينما قد نحتاج في الحل المدمج لإعادة صياغة المنطق داخل الحلقة.نظافة الكود (Clean Code): توزيع المهام على دوال متخصصة يجعل الكود قابلاً للفحص (Testing) والتطوير بسهولة فائقة.الخلاصة:من الجيد البدء بذكاء في اختيار الأداة الأسرع، ولكن من الضروري تعلم بناء الدوال بشكل عام لتكون صالحة للاستخدام المستقبلي، وهذا هو الفرق بين كتابة كود "يؤدي الغرض" وكتابة كود "يبني أنظمة".
الكود في التعليقات

Assem Dev

10/07/2026

08/07/2026

10/06/2026

17/05/2026

17/05/2026

17/05/2026

16/05/2026

16/05/2026

15/05/2026

15/05/2026

Address

Website

Alerts

Shortcuts

Share

Category