الخطوات السوية لإنتاج برامج قوية (مدخل إلى Software Engineering)
تعتبر هذه المقالة جزء من أجزاء عديدة سنقوم بنشرها باستمرار إن شاء الله من أجل تقريب هندسة البرمجيات Software Engineering لأذهان رواد أكاديمية المبرمجين العرب.
رمقه بنظرات ساخرة وقال له
بازدراء:
- ويحك يا مغبون ! لماذا تضيع
وقتك في مرحلة التصميم Design؟ ألا ترى أنه لا جدوى من هذه الخزعبلات مادمت تعرف ما الذي عليك
عمله؟
فقط قم بفتح بيئة التطوير
وابدأ في كتابة الأكواد التي تروج في ذهنك وسترى أنك ستنجز البرنامج دون تحليل أو
صداع رأس.
رفع المبرمج اللبيب رأسه ثم
رد بهدوء:
- لا تستعجل يا صديقي، وأمهلنا
نخبرك اليقين.
ثم تابع بنفس الهدوء:
التخطيط أو التحليل أو
التصميم لا يعني تحديدا تصميم الشاشات والواجهات الرسومية GUI
أو كتابة أكواد تدور في خلدك كما تتصور، وإنما يعني كذلك
التصميم الوظيفي والعملي، بمعنى تحديد طريقة التعامل مع البرنامج واختيار أفضل
السبل والطرق لإنجازه على أحسن وجه، إذن فالتصميم يجمع بين الشكل والوظيفة appearance
and functionality
تصور
معي بناء منزل من دون تصميم، أو تركيب أجزاء سيارة دون مخطط، أو تجميع جهاز موزع إلى قطع دون دليل تجميع، فكذلك يا صاحبي شأن
التحليل، فهو ذلك التصور السليم الذي ستسير وفقه حتى يتم إنشاء البرنامج بالشكل الذي
ترتضيه ويرضي العميل، أما أن تأتي وتبدأ إنتاج البرنامج مباشرة فذلك أشبه بتجميع
قطع لعبة puzzle
لم تشاهد صورتها الأصلية، فنسبة الفشل إذن كبيرة جدا.
عليك بالتحليل، فالبرمجة بلا تحليل، كالإعلام العربي بلا تضليل...
واعلم أن مجرد تصور الأكواد في ذهنك هو جزء من مرحلة التصميم، لكن
شروعك في التكويد مباشرة خطأ جسيم وسوء تقدير، لأنك تعمل عملين مهمين بالتوازي: التحليل والتكويد، وهذا
سيتسبب في بطء عملية الإنتاج ناهيك عن ضياع جزء غير يسير من تصورك العام للبرنامج،
وبالتالي ستقوم بإنتاج برنامج شائه سيصدم العميل، وسيجعلك
تشك في مداركك البرمجية.
أضف
إلى ذلك أن برنامجك سيفتقد إلى العديد من المزايا والتحسينات optimizations، التي قد لا تكتشفها لأنك بدأت
التكويد مباشرة، في حين لو تريثت قليلا، ستظهر لك العديد من الإضافات الرائعة التي
يمكنك زيادتها إلى برنامجك، إضافة إلى العديد من الأفكار التي قد تفيدك قبل بدء عملية التكويد وتوفر عليك الكثير من
الوقت.
غياب
التحليل قبل مرحلة التكويد، أو الاعتماد على تحليل سيء Bad
Design قد يتسبب لك في مجموعة من الخسارات أبرزها:
- ضياع الوقت: التحليل السيء سيدفعك باستمرار إلى العودة إلى نقاط تجاوزتها بغرض التعديل أو الاستغناء على أجزاء من الكود، لأن برمجة الأنظمة تكون متسلسلة وكل جزء مرتبط بغيره، وأي خطأ منهجي أو نقص في التحليل قد يستنزف الكثير من وقتك في أمور أنجزتها وستجد نفسك مضطرا إلى إعادة إنجازها لأنك أقمتها على غير وجهها.
- ضياع الجودة: بما أن برنامجك قائم على تحليل سيء أو قائم دون تحليل، فكن على يقين أنه سيكون رديئا بجميع المواصفات: شكلا ووظيفة، ولن يرتاح المستخدم النهائي إليه، بل قد لا يستطيع فهمه فضلا عن أن يتعامل معه.
- ضياع المال: لأنك إن أنشأت برنامجا بتحليل سيء فكن على يقين أنه سيكون مليئا بالأخطاء التي قد تعوق اشتغاله بشكل صحيح مما يدفع العميل إلى رفع تقارير الخطأ إليك باستمرار، والتي ستستنزف وقتك وتضيع عليك فرصة الاشتغال على برامج أخرى لجلب العائد المالي، بل وقد يؤثر التحليل السيء على عملية بيع البرنامج بحيث لن تكون طلبات له بسبب سوء اشتغاله.
- ضياع السمعة: إن كانت لديك مؤسسة أو مكتب وقمت بإنتاج برنامج يفتقد إلى التحليل السليم فكن على يقين أن سمعتك في السوق ستهوي إلى أقصى المنحدرات وقد رأيت بعيني كيف خسرت بعض الشركات بسبب كثرة شكاوي العملاء ومنهم من يشهر عيوب البرنامج بل وقد يطعن في الشركة عامة.
- ضياع الثقة في النفس: إن كان لديك فريق برمجي ووزعت العمل عليهم دون تحليل وفي كل مرة تقول لهم: لقد أخطأنا في كذا وكذا، والتحليل ينقصه كذا وكذا، وتعالوا بنا نعود إلى نقطة كذا وكذا، فكن على يقين أن ثقة الفريق ستهتز، ومزاجهم سيتم تكديره بكثرة إعادة نفس العمل جراء سوء التحليل.
أما
إن كنت تشتغل على البرنامج بمفردك، فقد تضجر وتجزع بسبب كثرة الرجوع إلى نقاط
سابقة، وصدقني قد تفكر في التوقف عن إكمال البرنامج، وكله بسبب عنادك وسخريتك من
مرحلة التخطيط.
مدون ومصمم فوتوشوب عراقي الجنسية احب ان اشاك افكاري في مدونة تقليبات
ليست هناك تعليقات:
إرسال تعليق