صنعة البرمجيات ضد هندسة البرمجيات

undo من شباب الفريق العربي للبرمجة كتب مقالة حلوة عن هندسة البرمجيات مقابل صنعة البرمجيات .. المقاله الأصلية موجودة على الرابط : http://www.arabteam2000-forum.com/ind ... 15&view=findpost&p=269326

-------------------

كتاب Software Craftsmanship, The New Imperative هو كتاب تم وضعه من فترة في المنتدى لكني لم أجد الرابط له

الكتاب اكثر من رائع و عندما بدأت في قراءته وجدته مسلي جداً بالرغم انه ليس موجه للمبرمجين و لكن للمدراء و صناع القرار في شركات البرمجة و يكفي اني قرأت منه 6 فصول في جلستين..
لكي احصل على اقصى افادة منه قررت البدء في تلخيصه فوراً..

الكتاب يتناول نظرة مختلفة للبرمجة هي software craftsmanship او صنعة(حرفة) البرمجيات في مقابل الsoftware engineering او هندسة البرمجيات.

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

2. هندسة البرمجيات لا تدخل في حسبانها مسألة مدى احترافية المبرمج .. بل تعتمد ان كل مبرمج له دور يؤديه بدون النظر لامكانياته بل أن آخر شئ تحتاجه هندسة البرمجيات هي مبرمج يقوم بالتعديل على تصاميم الdesigners. بينما في الحقيقة فان المبرمج المميز هو اهم مصدر لاي مشروع.
فمثلاً: في احصائية ان اكثر من ثلث المشاريع يتم انقاذها بواسطة مبرمج فذ في فريق العمل .. دور هذا المبرمج الفذ غير مذكور اطلاقا في هندسة البرمجيات رغم كونه سبب نجاح المشروع.

3. تعتمد هندسة البرمجيات على وضع التصميم كاملاً على الورق قبل العمل بينما يرى ان عملية التصميم ستكون افضل اذا صاحبها التكويد و الاختبار بصورة مستمرة بحيث تصل الى التصاميم النهائية و البرنامج في وقتين متقاربين. بالمناسبة هذا التصور جعل الكثيرون من المبرمجين يتبنون صنعة البرمجيات فور ظهورها لان التكويد من وجهة نظرهم هو افضل الطرق لتوضيح الافكار و ليس مجرد تصاميم على الورق.

4. هندسة البرمجيات تقوم بالفصل بين الادوار المختلفة في عملية التطوير يعني هناك محللي النظام analysts و المصممين logic designers و المكودين programmers و حتى المكودين هناك الاختبار testing و الصيانة maintenance و غيرها.. ستجد ان من يحلل النظام ليس هو من يكتب الكود و ان من يكتب الكود ليس هو من يقوم بعملية الصيانة. هندسة البرمجيات تفسر ذلك باهمية التخصص و ان شخصاً واحداً لا يمكنه تغطية نظام باكمله.
اما صنعة البرمجيات فتعتمد على التداخل و كلنا نعلم ان افضل من يقوم بعملية الصيانة هو من كتب الكود في البداية مهما كانت جودة التوثيق و وضوح الكود. و تعارض هندسة البرمجيات بأن صنعة البرمجيات تصر على ان مبرمج واحد يمكنه استيعاب و فهم نظام بأكمله و في ذلك توفير وقت و مجهود رهيبين كانوا يضيعون في هندسة البرمجيات لنقل المعلومة عبر الاوراق و المستندات من مهندس لاخر.
فمثلاً مشاريع المصدر المفتوح او open source تجدون ان بداية المشروع تكون دائماً مجموعة صغيرة تقوم بجميع الادوار و الناتج النهائي لهذه المجموعة الصغيرة يكون مشروعاً مميزاً يجذب الكثير من المتطوعين اليه.. لكن تظل دائماً عملية الصيانة لقلب المشروع هي مهمة هذه المجموعة الصغيرة و بالتالي فان الصيانة هنا هي شهادة بجودة المبرمج اما في هندسة البرمجيات فتجد من الشائع ان يقوم بالصيانة اجدد المنضمين..
لذلك فصنعة البرمجيات اقل تأثراً بمراحل في حالة رحيل احد المطورين مهما كانت اهميته لان النظام اولاً و اخيراً معروف من الجميع.
سيناريو آخر هو تعديل متطلب من متطلبات النظام.. هذا التعديل رغم كونه شائع جداً في السوق لكنه يعتبر كابوس في هندسة البرمجيات.. لأن عملية التعديل تتطلب التعديل في مئات المستندات و الأوراق من محللي النظام ثم تمرير هذه المستندات إلى المصممين الذين يقومون بدورهم بالبحث عن التغييرات الواجبة في تصاميمهم و إعادة صياغة مستنداتهم و تمريرها إلى المكودين.. و حتى في هذا المرحلة ففرق الاختبار ستبذل مجهود مضاعف لمعرفة ما هي المناطق في البرنامج الذي لم يشاركوا في كتابته التي ستسبب أخطاء بسبب الكود الجديد الذي لم يشاركوا في كتابته أيضاً. و بالتالي تميل هندسة البرمجيات الى تجميد المتطلبات بمجرد الموافقة عليها.
أما في صنعة البرمجيات فعملية تغيير المتطلبات أسهل بكثير لأن جميع اعضاء الفريق يلمون بالنظام تماماً و ليس هناك الحاجة لاعادة كتابة و تعديل مئات المستندات الورقية قبل البدء في العمل.. بل على العكس فإن صنعة البرمجيات تعتمد تماماً على إعادة تحديد المتطلبات بصورة دائمة حسب ما يراه المستخدمون .. ثم عند الحاجة لتعديل شئ ما فالمستخدم يشير الى البرنامج الذي لديه و يحدد التغييرات التي يريدها.

5. تعتمد هندسة البرمجيات على خرافة : "مقاس واحد يناسب الجميع" و تصل للمثالية اذا استطعت ان تطور كل برامجك فقط بالتوصيل بين مكونات تم تطويرها لديك من قبل. لكن عملية إعادة الاستخدام نفسها صعبة للغاية الا اذا كنت تحصل على بعض هذه المكونات من شركات اخرى كنظام قواعد بيانات من اوراكل و نظام لتنصيب برامجك من Setup factory و هكذا..
أحد المشاكل التي تواجه اعادة الاستخدام هي ان الهاردوير نفسه يتطوّر سريعاً جداً و بمعدل الضعف كل 18 شهر و بالتالي المكون الذي استخدمته من 5 سنوات على جهاز 300 ميجاهرتز و ويندوز 98 لن يكون مناسباً على الاطلاق لجهاز 2 جيجا هرتز و ويندوز xp .
مثال: سبب فشل رحلة الفضاء آريان 5 كان اعادة استخدام نظام آريان 4 الناجح جداً.. هل تعرفون ماذا كانت المشكلة؟ المشكلة هي ان متغير جديد تمت اضافته للنظام من نوع Number 64 bits سبب خطأ overflow عند تحويله الى متغير من نوع Number 16 bits و الذي كان مناسباً للهاردوير الخاص بآريان 4 .

ملاحظه : الكتاب متوفر في مكتبة الكتب

يتابع undo :

يقوم الكاتب بتوضيح متى يكون استخدم هندسة البرمجيات هو الحل الأفضل.

بدايةً.. يرى الكاتب ان هندسة البرمجيات تعمل على تقديم برنامج قريب من الكمال تمت مراجعة كل جزء فيه عدة مرات حتى قبل ان يتم تشغيل البرنامج..
1. الكاتب يرى ان أضخم مشروع على الاطلاق في صنعة البرمجيات لن يتعدى ابداً 20 سنة-مبرمج أما المشاريع التي تتطلب مجهوداً ضخماً (اكبر من 100 سنة-مبرمج و حتى 10000 سنة-مبرمج (ياللهوول)) ستجد صعوبة بالغة لكي يقوم بها فريق من الصنايعية لان الفريق غالباً لن يتجاوز ال15 فرد. في هذه الحالة يمكنك استخدام فريق من 50 مهندس ليقوم بمهمة من قياس 100سنة-مبرمج في سنتين.
2. كذلك المشاريع التي يكون فيها تسليم نسخة اولى سليمة للغاية و لا تقبل الفشل مثل تلك المستخدمة في الطائرات و غيرها من وسائل الأمان. لأن صنعة البرمجيات تعتمد على تسليم نسخة اولية تفي بأقل المتطلبات ثم الاستمرار في التعديل و التجريب حسب ما يراه المستخدمون حتى نصل للمنتج النهائي و هو مناسب جداً للكثير من المشاريع التجارية.
3. اما المشاريع التي يكون فيها جزء هاردوير فإن فصل عمليات التحليل و وضع التصاميم سيكون منطقي تماماً كما هو الحال في هندسة البرمجيات لأنه دائماً لن يتوافر الهاردوير حتى مرحلة متأخرة من عملية التطوير و سيكون لديك الكثير من الوقت قبل البدء في االتكويد لأن الهاردوير لم يجهز بعد..


صنعة البرمجيات تشبه البرمجة بالحرف المهنية مثل الحدادين او النجارين .
الصنعة عايزة الفن و بالتالي يكفيك 3 اسطوات craftsmenعن جيش كامل من المبرمجين المتوسطين..

اهم شئ في الكتاب هو ان المؤلف يقنعك تماماً بان طريقك للاحتراف هو التلمذة على يد معلم master craftsman(المقصود بمعلم هنا الاسطى القدير و ليس المدرس) اما المعرفة باللغات البرمجية و التكنولوجيات الحالية فليست هي الفارق ..
صفات المعلم هي:
1. دائم الاطلاع و التعلم
2. يستخدم التقنيات المستقرة (الكوبول موجودة من 40 سنة و مازالت) و ليست التي تتغير كل سنة (يقصد طبعاً تقنيات مايكروسوفت و الجافا)
3. القدرة على الانتقال السريع للتقنيات الجديدة لإن مبادئ البرمجة هي نفسها.

كيف نتعرف على المعلم اذا؟
المعلم هو المبرمج القادر على عمل برنامج و تطويره على مدار السنين لان عملية تحديث برنامج موجود اصعب من تطوير برنامج جديد لان التحديث يدل على ان قلب البرنامج مستقر و تمت مراعاة الاحتياجات المستقبلية اثناء تطوير النسخة الاولى .. المعلم قادر على عمل سلسلة كاملة من هذه النوعية من البرامج التي تكتسب ثقة الزبائن و زملاؤه. خبرة المعلم على الاقل 15 سنة (ياللهووول)..

نموذج العمل: يتكون فريق العمل من عدد من المعلمين master و الاسطوات journeyman و صبية المعلمين Apprentices
1. المعلم.
المسئول الأول و الأخير عن المشروع و يضع سمعته على المحك في كل مشروع و من اهم الاشياء هنا ان يعرف الزبون ان المعلم الفلاني هو اللي عمل المشروع بحيث يكون الالتزام شخصياً لاقصى حد من المعلم.
فريق العمل يضم عدد قليل من المعلمين
2. صبية المعلمين
شباب المبرمجين الذين تخرجوا حديثاً و يكون دورهم الرئيسي هو التعلم من المعلمين و الاسطوات و كذلك انجاز الوظائف السهلة التي تعوق انتاجية المعلمين و عندما ينجزونها بنجاح ينتقلون لوظائف اصعب.. و كما قلنا فصنعة البرمجيات لا تعترف بالفصل بين الادوار المختلفة يعني هذه الوظائف قد تكون تحليل جزء من النظام و الذي يقتصر في هندسة البرمجيات على الخبراء فحسب.
هذا الطور يستغرق 5 سنوات و يفضل ان يبدأ المبرمج قبل التحاقه بالجامعة.
3. الاسطى
بعد مرحلة صبي المعلم ينتقل المبرمج الى مرحلة الاسطى و فيها يتفوق على مهندس البرمجيات للأسباب التالية:
1. المطلوب الاهم من صبي المعلم هو التعلم بينما من المهندس فالمطلوب الاهم هو العمل.
2.صبي المعلم تعلم على يد معلم و ليس كورس في بداية تعيينه فقط.
3. صبي المعلم يتعلم النظرة الشمولية للنظام الذي يطوره و لا يتعلم التخصص في جزء معين لا يجيد سواه مثل المهندس.