الاختبار و الصيانة:
عملية الصيانة هي من أمتع العمليات في صنعة البرمجيات لأنها عبارة عن اتصال بين المبرمجين و المستخدمين. أي مبرمج يحب أن يرى مشروعه يعمل و يحب أن يرى الاستحسان على وجه مستخدميه و خصوصاً عند اصلاح خطأ ما بسرعة و هذا هو السبب الذي يجعلى اسطوات البرمجة مهتمين جداً بعمل برامج قابلة للصيانة. اما في هندسة البرمجيات ففكرة ان آخرين سيقومون بالصيانة تمثل حافز خفي للمبرمج لاستخدام عادات برمجية سئية لأنها قد توّفر عليه بعض الوقت.
بدلاً من تطوير النسخة الأولى من المشروع ملبيةً لجميع متطلبات النظام, تعتمد صنعة البرمجيات على تقديم نسخة أولى تحقق المتطلبات الأساسية ثم اضافة التحسينات و المميزات و اصلاح الاخطاء تباعاً في النسخ التالية. ذلك لأن عمر استخدام البرنامج يجب ان يكون اقصى ما يمكن لتقليل نفقات الانتقال الى برامج جديدة. النسخ التالية للنسخة الأولى يكون تصميمها بالاعتماد على الfeedback القادم من مستخدمي النظام.
اما عملية الصيانة و غيرها فتكون مسئولية نفس الفريق الذي طوّر النسخة الأولى أو على الأقل في حالة خروج عضو من الفريق فيجب على هذا العضو تدريب خليفة له.
البرنامج يجب ان يتم تطويره بحيث يمكن صيانته فيما بعد. هناك استراتيجيتين ناجحتين هنا:
1. تطوير البرنامج بحيث يكون مرناً جداً و يمكن تظبيطه لمناسبة اي تغيير قد يطرأ على المتطلبات.
2. تطوير البرنامج بحيث ان ان التعديلات المستقبلية عليه تكون بسيطة جداً و غير معقدة.
طبعاً الاستراتيجية الثانية أرخص و لكنها قد تكلفك الكثير على المدى البعيد اذا كانت المتطلبات دائمة التغير. و الأفضل ان تدمج بين الاستراتيجيتين.
التقنيات التي يجب استخدامها:
يفضل الكاتب استخدام اللغات المستقرة و التي يزيد عمرها عن 10 سنوات لأن استمراريتها شئ مضمون و الأفضل منها هي لغات المصدر المفتوح(مثل python و ruby). أما اللغات الحديثة (مثل الجافا و هذا هو المثال الوحيد الذي ذكره الكاتب اسماً) ففيها مخاطر جمة لانك لا تضمن استمراريتها ..
الكاتب شطح شطحة آخرى عندما تكلم عن قواعد البيانات و قال ان حتى الstandards غير مضمونة مثل الSQL و ان قواعد البيانات كلها حالياً من قواعد البيانات العلائقية و هي تقنية جديدة لا تزيد عن 15 عام و بالتالي يجب عليك توقع ان المستقبل قد يحمل لك الكثير من المفاجأت اذا لم تصمم برنامجك ليسهل نقله الى قواعد بيانات آخرى في 10 او 15 او حتى 20 عام!!!!!!
نقطة آخرى يجب وضعها في الحسبان و هي أن يطور فريق العمل اختبارات آلية خاصة بالبرنامج.. هذه الاختبارات مفيدة جداً و خصوصاً عند تعديل البرنامج مستقبلاً للتأكد ان هذه التعديلات لم تكسر شيئاً سليماً حالياً.
طبعاً الأخطاء الغير معروفة لن يمكن كشفها بهذه الطريقة و لكنها على الاقل تضمن ان التعديلات المستقبلية آمنة.
مواصفات البرنامج تشمل ايضاً:
1. globalization و عدم جعل برنامجك حكراً على اللغة الانجليزية (بالنسبة لنا العرب فهذه النقطة من البديهيات و رغم ذلك تجد القليل من البرامج الموجودة تدعمها بشكل صحيح, أما من وجهة نظر الكاتب رغم كونه امريكياً فهي نقطة مهمة جداً)
2. تصميم واجهة استخدام قوية أولاً سهلة ثانياً!! و وجهة نظر الكاتب هنا ان المستخدم حالما يعتاد على واجهة الاستخدام ستصبح سهولة الاستخدام الزائدة عن حدها عائقاً امام انتاجيته
3. تصميم برنامج آمن و المقصود ان اي شئ يقوم به المستخدم يمكن اعادته لطبيعته أو بعبارة آخرى : البرنامج يجب ان يسامح المستخدم على أخطاؤه و هذه نقطة مهمة لتشجيع المستخدم على استكشاف البرنامج و تعلمه و هذه الميزة تعوض سهولة الاستخدام التي قد تقل قليلاً بسبب المواصفة الثانية.
الOutsourcing:
و هي التعاقد مع شركة لتوريد فريق برمجيات لتطوير البرنامج لك. و هذا سئ و خطير جداً لمشروعك لأنه يضمن (تقريباً 100%) أن الفريق الذي طوّر المشروع سيتفرق بعد انهاؤه و لن يكون المسئول عن صيانته.
حلول هذه المشكلة:
1. ان تصمم على ان يقوم الفريق الذي طوّر المشروع بصيانته فيما بعد. و بهذه الطريقة انت تضمن تطبيق مبدأ قريب جداً من صنعة البرمجيات في هذه الشركة لتطوير مشروعك.
2. ان تتفق مع معلم او اسطى من خارج الشركة لتطوير البرنامج وفي نفس الوقت تصمم على ان يكون مبرمجين من شركتك متواجدين طوال الوقت معه (صبية معلم يعني). و يكون نجاح المشروع مرتبطاً بمدى قدرة هؤلاء المبرمجين على تطوير و تحسين المشروع بعد تسليمه.
في الفصل الأخير: يتكلم الكاتب عن التعلم و في مجال البرمجة فيسميه "التعلم للأبد" لأن مجال البرمجة يتغيّر بصورة دائمة و لا مكان لمن لا يقرأ و يتعلم شئ جديد على الأقل أسبوعياً. الكاتب ينصح المؤسسات بأن تخصص من وقت موظفيها 5% على الأقل للتعلم و يرى أن الالتزام تجاه التعليم هو الفارق الأكبر بين صنعة البرمجيات و هندسة البرمجيات التي تركز على المشروع دون النظر لمبرمجي المشروع. و يكون من الواجب على كل فريق تكوين مكتبة خاصة به تشمل مراجع للتقنيات المستخدم و كتب How to و غيرها و تشجيع اعضاء الفريق على قراءة هذه الكتب و اضافة المزيد من الكتب اليها.
أيضاً التعلم يأتي من الاشتراك في المجموعات المحلية (مثل هذا المنتدى) و كذلك بحضور المؤتمرات.
كذلك التزامك تجاه التعليم يفرض عليك أخذ دورات تدريبية مرة أو مرتين سنوياً بحيث تظل حاداً.
أهم شئ هو تطبيق المعلومات الجديدة التي اكتسبتها و بدونها ستنسى المعلومات في فترة قصيرة جداً, ابذل قصارى جهدك لربط ما تعلمته ببرامجك.
طريقة آخرى للحفاظ على المعلومة هي بتقديمها للاخرين من خلال محاضرات أو دروس قصيرة, لأن شرح المعلومة طريقة قوية جداً لتثبيت المعلومة.
أيضاً يمكنك تعميق مستوى فهمك و إدراكك لأي موضوع من خلال التعليق على ما يصدر من مقالات دورية تتناول هذا الموضوع بل و الخطوة الأكبر من ذلك هي تأليف كتاب أو ورقة بحث او مقال على الأقل عن الموضوع .
في خاتمة الكاتب وضّح الكاتب أن صنعة البرمجيات ليست تراجعاً عن هندسة البرمجيات بل خطوة للأمام فيها و يفسر ذلك ان مشاهداته كلها أثبتت أن الطريقة النظرية التي تنادي بها هندسة البرمجيات و التي يجب بها تطوير البرمجيات ليست هي الطريقة التي يستخدمها المبرمجين الجيدين لتقديم برامج رائعة.. و استنتج أن المشاريع الضخمة جداً هي فقط التي يجب تطبيق هندسة البرمجيات حرفياً فيها أما المشاريع التجارية فيجب أن يكون هناك دور أكبر للمبرمج و دور أقل للورق..
ختام الكتاب بجملة:
Software development is meant to be fun. If it isn't, the process is wrong.
تم بحمد الله!