حلقات صنعة البرمجيات

الحلقه الأولى : صنعة البرمجيات ضد هندسة البرمجيات

كتاب Software Craftsmanship, The New Imperative

Software Craftsmanship, The New Imperative.chm ( 331.34k )

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

الكتاب يتناول نظرة مختلفة للبرمجة هي 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

فريق العمل في صنعة البرمجيات, حلقة 2 .. و تابع لمناقشة هندسة البرمجيات

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

بدايةً.. يرى الكاتب ان هندسة البرمجيات تعمل على تقديم برنامج قريب من الكمال تمت مراجعة كل جزء فيه عدة مرات حتى قبل ان يتم تشغيل البرنامج..
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. صبي المعلم يتعلم النظرة الشمولية للنظام الذي يطوره و لا يتعلم التخصص في جزء معين لا يجيد سواه مثل المهندس.

كلام لاصحاب الشركات عن صنعة البرمجيات, الحلقة الثالثة من صنعة البرمجيات

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

مسألة آخرى هي ادماج المستخدم في فريق العمل.. أفضل طريقة هي ان يقوم مستخدم خبير بالنظر لكل جزء في المشروع بعد إنجازه و استخدام تعليقاته و اقتراحاته لتطوير هذا الجزء مباشرةً بدون الحاجة للبحث عن هذا الجزء في المشروع كاملاً بعد انهاؤه. كذلك فوجود المستخدم في الفريق لن يوقف الفريق عند المحطات التي تحتاج فهماً عالياً للمشكلة.

المرتبات.. مشكلة البرمجة دائماً هي ان المبرمجين المتميزين يتركون هذا الحقل بعد فترة ما لأن المرتبات تصل إلى حد ما, بعده يجب على المبرمج الانتقال لحقل آخر مثل الادارة او البحث العلمي و الاكاديمي للحصول على مرتبات أعلى. و الدليل على ذلك ان المبرمجين المميزين الذين يبدأون برنامج ناجح, سريعاً ما يتركوا البرمجة لتولي مناصب ادارية في شركاتهم الجديدة و يتركوا برامجهم المميزة في ايدي المبتدئين لكي يفسدوها.
في صنعة البرمجيات بدلاً من ان توظف 10 مبرمجين متوسطين ذوي خبرة اقل من سنتين يكفيك فريق من معلم واحد و اتنين من الاسطوات و اتنين من صبية المعلمين لانتاج سوفتوير افضل و اقوى.. في هذه الحالة بدلاً ان تعطي 40000-60000$ سنوياً لمهندس البرمجيات العادي .. اعطي المعلم مرتب يصل الى 150000-250000$ سنوياً و ستكون انت الكسبان ايضاً سوى من ناحية توفير سوفتوير اقوى او حتى على صعيد الاستغناء عن مرتبات عدة مبرمجين متوسطين.
هناك مقولة تقول: اذا كان لديك 200 مبرمج متوسط تحت ادارة 25 مدير مبرمج خبير... فافصل ال200 مبرمج و أعد ال25 خبير للبرمجة..

قصة:
ثمانية من المعلمين قاموا بتطوير برنامج Quattro Pro خلال 31 شهر.. الفريق انجز مليون سطر كود و اختبار البرنامج خلال هذه الفترة.
متوسط عدد الاسطر التي كان يكتبها المعلم منهم كان: 1000 سطر/اسبوع مقارنةً ب10-100 سطر على اقصى تقدير في هندسة البرمجيات. هل عرفت الان ماذا ينتظرك في صنعة البرمجيات؟

]الحلقة الأخيرة: الصيانة و التقنيات و المواصفات في صنعة البرمجيات

الاختبار و الصيانة:
عملية الصيانة هي من أمتع العمليات في صنعة البرمجيات لأنها عبارة عن اتصال بين المبرمجين و المستخدمين. أي مبرمج يحب أن يرى مشروعه يعمل و يحب أن يرى الاستحسان على وجه مستخدميه و خصوصاً عند اصلاح خطأ ما بسرعة و هذا هو السبب الذي يجعلى اسطوات البرمجة مهتمين جداً بعمل برامج قابلة للصيانة. اما في هندسة البرمجيات ففكرة ان آخرين سيقومون بالصيانة تمثل حافز خفي للمبرمج لاستخدام عادات برمجية سئية لأنها قد توّفر عليه بعض الوقت.
بدلاً من تطوير النسخة الأولى من المشروع ملبيةً لجميع متطلبات النظام, تعتمد صنعة البرمجيات على تقديم نسخة أولى تحقق المتطلبات الأساسية ثم اضافة التحسينات و المميزات و اصلاح الاخطاء تباعاً في النسخ التالية. ذلك لأن عمر استخدام البرنامج يجب ان يكون اقصى ما يمكن لتقليل نفقات الانتقال الى برامج جديدة. النسخ التالية للنسخة الأولى يكون تصميمها بالاعتماد على ال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

سلمت اناملك
ودمتي مبدعه