ماهي التقنيات والأساليب المساعدة في تصميم مشروع كبير و متشعّب

كيف بدون تشغيله واختبار كل جزء من برنامجك قبل تكامله شئ مهم جدا ؟

أنت الآن كتبت الـ1000 سطر وهذه الألف نصف أحد الحُزم التي يحتاجها برنامجك .. كيف تختبر نصف الحزمة هذه وتتأكم من خلوها من الأخطاء ؟ أتمنى أنك فهمت قصدي

ايوة فهمت قصدك، ولكن لازم تاخد في حسبانك ان اختبار البرمجيات على عدة مستويات اصلا

إممممم ... عندما درست مادة الـ Operating System Concepts ، كان دائماً مؤلف الكتاب يذكر أهمية الفصل بين الـ Mechanism و الـ Policy بين الفترة والأخرى.

Mechanism : determine how to do something

Policy : Determine what will be done

ربما عليك التفكير بالـ policy قبل الـ Mechanism

هذا سؤال البرمجة الأزلي: هل البرمجة نوع من الهندسة أم هي فن؟ والسؤال لا زال مفتوحاً. في بداية عهد البرمجة أراد المبرمجون أن يعتقدوا أنهم مهندسون تماماً كغيرهم من المهندسين وانعكس ذلك على طريقة ادارة مشاريع البرمجة وكانت طريقتهم تلك تسمى Waterfall (بعض جامعاتنا لا زالت تدرس البرمجة بهذه الطريقة). بمعنى أنهم يجمعون عدداً من المحللين لدراسة المتطلبات أولاً وبعدها ينتقلون الى مرحلة التصميم ويقضون فترة طويلة في اعداد رسوم ومخططات كبيرة وفي النهاية يقوم مبرمجون بكتابة كود وفق تلك التصاميم. ما لاحظه علماء البرمجة آنذاك أن نسبة عالية من المشاريع الكبيرة تفشل تماماً وتحقق خسائر للشركات. السبب انه في الوقت الذي ينتهي فيه المحللون والمصممون من اعداد مخططاتهم بأن متطلبات البرنامج تكون قد تغيرت تماماً مع الوقت.

وبدأت ثورة؟ الeXtreme Programming وما تلاه من طرائق تسمي نفسها رشيقة Agile Methodologies. وهي ثورة لأنها ترفض ما تسميه Big Upfront Design (BUFD). هذه الطرق تعتمد على تناول أجزاء صغيرة من متطلبات البرنامج الكلي وتسمى User Story وبرمجتها على حدة وطلب موافقة العميل بأنها تحقق متطلباته وبعدها ينتقلون الى قصة أخرى وهكذا. هذا هو النمط السائد حالياً في أكثر الشركات. بدلاً من تصميم محكم ودقيق مسبق يبدأون من عمارة للبرنامج بسيطة ويبدأون البرمجة. طرق البرمجة هذه تعتمد عدة ممارسات في عملها بقصد التعامل مع المشكلة التي ذكرت وهي Dependencies.

أول ممارساتهم هي أنهم لا يكتبون كود البرنامج أبداً من دون كتابة كود الاختبارات أولاً وهو ما يعرف Test Driven Development. يكتبون كود الاختبارات وينفذونها فتفشل فيكتبون كود البرنامج (بأي طريقة) حتى تنجح الاختبارات. بعد أن تنجح الاختبارات يقومون بتعديل الكود Refactoring لكي يصبح أفضل ولكن الاختبارات يجب دائماً تنجح. وينتقلون الى قصة جديدة ويبدأون بالاختبارات أولاً. وهكذا دواليك. باختصار:

- اكتب فحوصات الكود أولاً (النتيجة هي الفشل) وتظهر في Test Runner كأحمر.

- اكتب كود لكي تنجج الاختبارات وتظهر في الُTest Runner كأخضر.

- عدل الكود لكي يصبح أفضل ويبدأ تصميم البرنامج بالظهور.

لاحظ أنهم لا يقومون بكتابة كود من 1000 سطر. هذا ممنوع في ممارستهم. هم يقومون بما يسمونه Baby Steps. خطوات صغيرة جداً. وبرنامج به دالة أو كلاس فيها هذا الحجم من السطور هي دالة خطأ ولذلك يستخدمون الRefactoring لتوزيع مهامها على كلاس ودوال مختلفة.

مع الوقت فان تصميم البرنامة "ينمو" مع الوقت. ممارسة الTDD تتطلب استخدام ادوات برمجية لتسهيل ذلك وهي من الأدوات الأساسية التي يجب أن يعرفها المبرمج. لكل لغة برمجة اطار عمل وأشهرها هو JUnit للغة جافا الذي انتقل منها لبقية اللغات مثلاً NUnit في الدوت نت. ولكن عند كتابة كود مثلاً يعتمد على جزيئة غير مكتوبة فما العمل؟ وهذا هو ما تسأل عنه. مثلاً اذا كنت أكتب دالة أو كلاس لحساب شيء ما متعلق بكلاس أخرى وهذه الأخيرة سيكتبها مبرمج آخر وهي ليست جاهزة بعد ما العمل؟ في ذلك يستخدم المبرمجون في اختباراتهم Mocking Framework وهو يوهم الاختبارات بان الكلاس فعلاً مكتوبة. أحد الاطارات هو مثلاً JMock وهناك نظيره في عدة لغات. يمكنك مشاهدة كيف تمارس الTDD بالبحث على يوتيوب. وطبعاً هناك عدة كتب حول الموضوع. لتعديل الكود فانهم لا يستخدمون النسخ واللصق والا فان الاختبارات ستفشل (حتى ولو لبعض الوقت) وهذا غير مقبول. لذلك كل IDE اليوم في ميزات لتعديل الكود من دون تخريبه في Eclipse و Visual Studio هناك لاىحة تسمى Refactoring وهي عبارة عن تطبيقات للأنماط التي تحدث عنها Martin Fowler في كتابه الشهير Refactoring.

أضافة لما سبق يمكنك أن تقرأ كتاب Domain Driven Design وأعتقد أنه قد يجيب على أسئلتك. كما تلاحظ البرمجة اليوم تتضمن اضافة لتعلم لغة برمجة مهارات أساسية لا بد من تعلمها أهمها:

- الاختبارات Unit Testing ومنها Mocking Framework

- Refactoring ومرجعها كتاب Martin Fowler.

- لا بد من تعلم أحد برامج الCVS مثل Subversion أو git. لأن المبرمج يجب أن يحتفظ ببرامجة في أحد هذه البرامج.

والسلام عليكم

hamany-pirio,

الحقيقة أنني أوقفت نفسي عمداً :) . السؤال الذي يبحث الأخ عن اجابته لا يمكن أن يكون مختصراً فليس هناك تكنيك يتبع فيحل المشكلة. هو نفس السؤال الذي يسأله المبرمجون وعلماء البرمجة منذ ظهور البرمجة ولهذا ابتكروا هذه الأساليب في العمل. الأخ يدرك أن المحاولات السابقة فشلت حين يقول: "كيف يمكنني أن أخطط لمشروع قبل أنّ أكتبه كي أظمن انّ ﻻ أتوه في تشعباته وأظمن مرونته . وتكون طرق عمليه وواقعيه وليست مثل مخططات التدفّق وهذه الأساليب ﻻتبدو لي فعّاله أبداً سوى في الأشياء البسيطه." وهو محق. فمحاولة كتابة برامج مثلاً من خلال تصاميم UML التي تنتج الكود أوتوماتيكياً فشلت. ولكن القصة ما زالت تتوالى فصولاً والثورة مستمرة!! ولكن هذا حديث ليوم آخر :)