2009/03/01

Programming

من خلال تجوالي في الإنترنت وجدت مدونة المبرمج السعودي (تركي العسيري) المليئة بالمعلومات البرمجية القيمة، ولكن ماشد إنتباهي هي مجموعة من الحكم والأمثال المتعلقة بالبرمجة والتي سماها (هكذا علمتني البرمجة) أنشرها هنا مع بعض التعليقات من وجهة نظري:

  1. اياك ثم اياك ان تكتب نفس الشيفرة المصدرية Source Code اكثر من مرة في برنامجك!(بروس مكيني)، الجميع يعرف هذه الحكمة لكن قليلاً مانلتزم بها.
  2. لا تجعل هدف برنامجك ان يسهل الامور (قدر) المستطاع، ولكن اجعل هدفه ان يسهل الامور (اكثر من) المستطاع (بروس مكيني)، مهمة صعبة لكنها ليست مستحيلة.
  3. من الغريب ان تكون الواجهات Interfaces [التي تستخدم مع الفئات Classes] اقل استخداما في أي مشروع، بالرغم من انها اكثر مبدأ برمجي اثبت وعوده [الكائنية التوجه Object Oriented] على مر التاريخ (بروس مكيني)، لاتعليق.
  4. لا بأس من تدارك الاخطاء المتوقعة Handling Expected Errors في الاصدار الثاني (لارس ويرزينيوس)، كثيراً ما أقوم بتأجيلها حتى الإصدار العاشر.
  5. ليس عيبا عليك ظهور اخطاء في المخرجات Outputs ان كانت المدخلات [من المستخدم] خاطئة (لارس ويرزينيوس)، والأفضل منع المستخدم من إدخال مدخلات خاطئة قدر المستطاع.
  6. السرعة مهمة، ولكن امكانيات برنامجك تبقى اهم (لارس ويرزينيوس)، لاتعليق.
  7. الذي لم يلامس لغة C في حياته، من الافضل ان لا يعتبر نفسه مبرمج ابدا (مارك فينيو)، لاتعليق.
  8. تعلم البرمجة سهل جدا ولكنها اكثر تعقيدا مما تتصور (ستيف ديسبنسا)، كلام جميل يلامس الواقع.
  9. المبرمج الحقيقي لابد ان لا يخشى المستقبل ابدا (دانيا ريد)، كلام مبالغ فيه.
  10. استخدامك لمولدات الشفرات Code Generators قد يجعلك تكتب شفرات أكثر مما لو لم تعتمد عليها! (جستن جيميس)، ليس دائماً، عندما تستعملها بذكاء ستجد أنها توفر عليك وقتاً طويلاً.
  11. صحيح انه يبدو لك ان برنامجك يعمل ما تأمره به، ولكن ذلك لا يعني انك كتبت البرنامج بشكل صحيح (ك. س. ب)، أعتقد أن منتهى الغرور عندما تقول ان برنامجي مكتوب بشكل صحيح.
  12. ان لم يعمل كودك بشكل صحيح، فلا تمدحه ابدا [مهما كانت طريقة كتابته] (ك. س. ب)، شكار العروسة :)

كذلك توجد مجموعة أخرى من الحكم البرمجية ناتجة من تجارب (تركي العسيري) وهي:

  1. كلما زادت الانتاجية Productivity كلما –مع الاسف- قلت كفاءة التنفيذ Performance، للأسف كلام صحيح :(
  2. ان يكون المختبر Tester هو نفسه المبرمج، فهو من المحرمات في عقيدة صناعة البرمجيات، هو من أشد المحرمات.
  3. قلة عدد سطور البرنامج لا تعني (دائما) ان تنفيذها اسرع!، المهم هو صحة الألجوريثم الذي كتبت الأسطر على أساسه.
  4. عندما تبدأ بكتابة الاصدار الاول لبرنامجك، فكر دائما بالإصدار الثاني (حتى لو كان الاصدار الاول هو الاخير)، أحاول دائماً أن أقوم بذلك.
  5. اكبر خطأ يعتقده الكثير من المبرمجين هو امكانية كتابة برنامج دون اخطاء، صح 100% فالمستحيل بذاته هو وجود برنامج خالي من الأخطاء ولعل الوندوز خير دليل على ذلك.
  6. عندما تضع موعد لتسليم مهمة معينة Deadline، اضرب الفترة التي وضعتها في 2، أحياناً الضرب في 3 أفضل بكثير.
  7. البرامج Software هي المشاريع الوحيدة التي لها بداية ولكن ليس لها نهاية، صح 100%.
  8. وهي ايضا اكثر مشاريع (على مستوى الصناعات المختلفة) يتم الغائها!
  9. كتابة 1000 سطر لبرنامج جديد من الصفر خير من تنقيح وتعديل كود برنامج ذا 100 سطر، الغريب أن الأمر صحيح.
  10. كلما زادت جمل الشرط If في شفراتك المصدرية، كلما زاد ذكاء برنامجك، هل تعتقد ذلك؟ أفضل جملة Switch في السي شارب.
  11. البرمجة كائنية التوجه OOP عبارة ساحرة للمبرمجين ولكنها لا تعني شيئا للمستخدمين (فلا تهتم لكودك وتنسى برنامجك)، الغريب أن هذا الكلام صحيح.
  12. لا تثق في الاختبار الاول لبرنامجك الذي يعتمد على مسارات تنفيذ متعددة Multi-Threading، فنجاح التجربة الاولى والثانية والثالثة ليس دليلا على نجاح التجربة العاشرة!
  13. الكثير منا يعرف كيف يكتب شفرات Code، ولكن القليل (جدا قليل) يعرف كيف يكتب برامج Software، كلام جميل.
  14. المضحك في كتابة التعليقات Comments انها تضيع الوقت سواء استخدمتها أم لم تستخدمها!، هذا الكلام صحيح كذلك مع أن الكثيرين يدعون العكس.
  15. التحقق من المدخلات Validating Inputs عمل ممل ويتطلب جهد اضافي، ولكنه ساتر للكثير من الفضائح!، هذا هو لب البرنامج الناجح حسب إعتقادي فكلما منعت الإدخالات الخاطئة كانت نتائجك اصح.
  16. كلنا ننصح بعدم استخدام Goto، ولكن الحقيقة اننا (جميعا) نستخدمها في السر، اعيد في السر :)
  17. الذي يدعي ان لغته هي افضل لغة برمجة، فاعلم انه مستخدم وليس مبرمج، صح فمتلي الأول هو”لا تقل ما تستطيع أن تعمله لغة البرمجة لي بل قل ما أستطيع أنا أن أعمله بلغة البرمجة“.
  18. علمتني البرمجة ان افضل طريقة لتحليل المتطلبات Analysing Requirments هي رسم الشاشات Prototyping.
  19. كلما جعلت وحداتك البرمجية Programming Modules مغلفة اكثر Encapsulated، كلما زادت استقامة برنامجك.
  20. برنامج ((وهمي)) لا يقوم بأي عمل ولكنه ذو واجهة استخدام جذابة، يرسم ابتسامة واندهاش ويكسب اعجاب اكثر للمستخدم من برنامج ((حقيقي)) ذو واجهة استخدام سيئة!، للأسف هذا الكلام صحيح 1000%.

هل لديك حكم استنتجتها من البرمجة وتحب أن تشاركنا بها؟

2 comments:

alfasla said...

السلام عليكم
موضوع رائع فعلا يجعلك تبتسم احيانا على سذاجتك البرمجيه اكثر من مره
( اتحدث عن نفسي )

اكثر ما اضحكني هذه المقوله

التحقق من المدخلات
Validating Inputs
عمل ممل ويتطلب جهد اضافي، ولكنه ساتر للكثير من الفضائح!،

اذكر مره استفزني موقف ما مع اداة معينه لا اذكرها الان وكانت تعاندني في قبول ما ادخله من بيانات خاطئه كانت ام صواب .. فقررت ان اعاندها بالمثل
فبعد ان جربت ان اكتب الاختبار واختمه بمسج بوكس يفيد القضيه..
اتضح ان كل ما كتبته لم يجدي نفعه .. فتهورت وقمت بتغيير طريقة وجمل الvalidation
وكتبت له الجمله التاليه
msgbox "يفتحلك ربي "

والغريب ان بعدها سار على الصراط المستقيم

Tarek Siala said...

أهنئك على وصولك لحل لمشكلتك مع أن الحل غريب :)
وكما يقولون ان احسن الحلول للمشاكل المعقدة هي تلك الحلول التي تكون في غاية البساطة