السابقالفهرسالتالي

الملحق C

تطوير البرامج

 

C.1 الاستراتيجيات

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

أساس كل الاستراتيجيات هي التطوير التصاعدي (incremental development)، التي تتم كما يلي

  1. ابدأ مع برنامج يعمل ينفذ شيء مرئي، مثل طباعة شيء ما.
  2. أضف عدداً قليلاً من أسطر الشفرة كل مرة، واختبر البرنامج عند كل تغيير.
  3. كرر الخطوات حتى يعمل البرنامج ما يفترض به أن يعمل.
بعد كل تغيير، يجب أن ينتج البرنامج بعض التأثيرات المرئية الناتجة عن اختبار الشفرة الجديدة. هذا الأسلوب في البرمجة يمكن أن يوفر الكثير من الوقت.

بما أنك تضيف بضعة أسطر من الشفرة فقط في كل مرة، فسيكون العثور الأخطاء النحوية سهلاً.

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

صعوبة التطوير التصاعدي تكمن في صعوبة اكتشاف مسار مناسب من نقطة البداية وحتى الوصول إلى برنامج كامل وصحيح.

توجد عدة أساليب ممكنة لتساعدك بذلك:

التغليف والتعميم (Encapsulation and generalization): إذا لم تكن تعلم بعد كيفية تقسيم الحسابات إلى عمليات، ابدأ بكتابة الشفرة في main، ثم ابحث عن القطع المتماسكة لتغلفها في عملية، وتعميمها بشكل مناسب.

النمذجة السريعة (Rapid prototyping): إذا كنت تعلم ما هي العملية التي تريد كتابتها، لكنك لا تعرف كيفية كتابتها، ابدأ بمسودة سريعة تعالج أبسط حالة، ثم اختبرها مع الحالات الأخرى، وسّعها وصححها على طول الخط.

الأدنى أولاً (Bottom-up): ابدأ بكتابة العمليات البسيطة، بعد ذلك اجمعها في حل متكامل.

الأعلى للأسفل (Top-down): استعمل الشفرة الزائفة (pseudocode) لتصميم بنية الحسابات وتعريف العمليات التي ستحتاج. ثم اكتب العمليات واستبدل الشفرة الزائفة بالشفرة الحقيقية.

على طول الطريق، قد تحتاج بعض السقالات للدعم؛ مثلاً، يجب أن يكون لكل صنف عملية toString تسمح لك بطباعة حالة الكائن بصيغة يقدر البشر على قراءتها. هذه العملية تفيد في تنقيح البرنامج، لكنها في العادة ليست جزءاً من البرنامج النهائي.

C.2 أساليب الفشل

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

التطوير غير التصاعدي (Non-incremental development): إذا كتبت أكثر من بضعة أسطر من الشفرة بدون ترجمتها واختبارها، فأنت تبحث عن المتاعب. سألت أحد الطلاب ذات مرة عن وظيفته، فأجاب، "تمام! لقد كتبتها بالكامل. بقي أن أصحح الأخطاء الموجودة فيها فقط."

الارتباط بالشفرة السيئة (Attachment to bad code): إذا كتبت أكثر من بضعة أسطر من الشفرة بدون أن تجمعها وتختبرها، فقد لا تتمكن من تنقيحها. أبداً. أحياناً يكون الحل الوحيد هو (التقط أنفاسك!) حذف الشفرة السيئة والبدء من جديد (باستخدام طريقة تصاعدية). لكن المبتدئين غالباً ما يرتبطون عاطفياً بالشفرة التي كتبوها، حتى لو لم تكن تعمل. الطريق الوحيدة للخروج من هذا الفخ هي أن تجعل قلبك قاسياً.

البرمجة عشوائية المجرى (Random-walk programming): أحياناً أعمل مع طلاب يبدو أنهم يبرمجون عشوائياً. يغيرون شيئاً ما، يشغلون البرنامج، يحصلون على خطأ، يغيرون شيئاً ما، يشغلون البرنامج، الخ. المشكلة هنا هي عدم وجود علاقة ظاهرة بين خرج البرنامج وبين التغييرات التي يجرونها.

إذا حصلت على رسالة خطأ، خذ الوقت لقراءتها. عموماً، عليك أخذ الوقت الكافي للتفكير.

الخضوع للمجمع (Compiler submission): رسائل الخطأ مفيدة، لكنها ليست صحيحة دائماً. مثلاً، إذا قالت الرسالة، "أتوقع فاصلة منقوطة في السطر 13 _ Semi-colon expected on line 13 "، فهذا يعني وجود خطأ نحوي بالقرب من السطر 13، لكن وضع فاصلة منقوطة على السطر 13 ليس الحل بالضرورة. لا ترضخ لرغبات المجمّع.

يقدم القسم التالي المزيد من المقترحات لتصحيح الأخطاء بأساليب فعالة.

السابقالفهرسالتالي