برمجة - شبكات - كمبيوتر - منتديات الفريق العربي للبرمجة: صنعة البرمجيات ضد هندسة البرمجيات - برمجة - شبكات - كمبيوتر - منتديات الفريق العربي للبرمجة

كتاب 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 .

يتبع!!

شكراً يابوحميد على الافادة،
و ها هو الكتاب للافادة حتى لا تحزن:

Quote

ينتظر!!
خذ راحتك يابو حميد، لكن لا تتأخر علينا لأن الموضوع شيق للغاية، و بصراحة أنا مكسل أقرا الكتاب B)

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

صديقك

تم تعديل هذه المشاركة بواسطةORWA: 14/03/2005 - 12:12 AM

Quote

مشكوووووووووور...... المصيبة اني لا اعرف استخدام محرك البحث حتىالان....

Quote

و لا يهمك و جاري القراءة..

وان شا ءالله سنتناقش في هذا الموضوع..

بالنسبة لي فحكاية صنعة البرمجيات ليست سهلة كما يظن البعض لأنها تركز على المبرمج و ليس عملية التطوير نفسها..
اصعب شئ فيها هو ان جميع المشاركين لازم يفهموا النظام كله ودي هي اللي اعتقد ستكون صعبة جداً..

السلام عليكم ورحمة الله وبركاتة

بارك الله فيك اخ احمد , الموضع شيق جدا , وحيث يتوفر ذلك بشدة ماديا مع تدول المشروعات التى يشراك بها المبرمج وانا متحيز لنزعة الكتاب نحو حرفة البرمجة
ونحن فى انتظار الباقية

والله المستعان

شكرا يابو حميييييد.....

بس بلاش نقطع على بعض
;)
امزح معاك

انت كده حاتقطع سوقنا

بس الكتاب صرحة جميل

وانا في انتظار الباقي

Quote

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

على كل حال, تظل هندسة البرمجيات هي الطريقة المتبناة عالمياً و حكاية الصنعة دي هتاخد وقت كي تنتشر و ربما لا ..

لم أكمل قراءة الموضوع بالتمام ، فى وقت لاحق اليوم ،، المهم

هندسة البرمجيات تعتمد - من رأئي - على الهندسه فى التفكير وإتخاذ القرار والهندسه فى كتابة الكود وتصميم التطبيقات كما أسلف الأخ وائل فى الدرس السابق ، وهذا يؤدى إلى المرونه فى التفكير أيضا مما يؤدى بدوره - وذلك التطور الطبيعى - إلى تفادى الروتنيات و "المفروض ان يتم هكذا" و "لا يمكننى القيام بذلك قبل أن كذا" وما إلى ذلك من فروض نضعها بأنفسنا .
لذا فى النهايه نصل إلى خليط بين هندسة البرمجيات وصناعة البرمجيات ، يجب ان نأخذ هندسة البرمجيات أنها "مدى القدره على المرونه والإتقان فى نفس الوقت فى إنتاج التطبيقات"

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

ايضا - وكما يقول المؤلف - لا يجب الإعتماد على هندسة البرمجيات إلا فى المشاريع الكبيره ، طيب وهل يباع وينتشر على شريحه كبيره من المستخدمين إلا المشروعات والتطبيقات الكبيره ومنها يجب ان تكون مبنيه على أسس سليمه وإتباع مشروط لخطوط هندسة البرمجيات لأنها سوف يتم إستخدامها من جانب شريحه كبيره ومتفاوته من المستخدمين . من جانب آخر هناك التطبيقات الصغيره والتى لن يكون لها نفس الشريحه المتفاوته ولهذا يجب التنازل عن بعض من قوانين هندسة البرمجيات فى مقابل بعض المرونه من جانب شخص أو إثنان والذين سوف نطلق عليهم بعد الإنتهاء من تصميم البرنامج بالكامل "مصممون البرنامج Authors" ... إذا لا يوجد تعارض أبدا وكلام المؤلف منطقى جدا (حالما أقرأ الشرح بدقه أكثر)
وشكرا لك يا أبوحميد على التلخيص المميز ،،

صحيح يا ابو حميد ، لا تنسى ان أجازة العيد إنتهت ويمكنك الرجوع إلى باقى فصول الكتاب
بالتوفيق

Alsalam alikom
really intersting topic and important at the same time
i've studied software engineering it was horrible it was not intersting at all except for the project we did

in fact now i can c the diffrence between software engineering and craftmanship

and my point the software engineering is intersting except that the instructor him self was not good or friendly enuogh

Gazakom Allah khairan for the good topic

بصراحة انا ارى ان استعمال مصطلح ممتع ليست مناسبة للموضوع العلمي الذي طرح من الأخ undo
[QUOTE]وجدته مسلي جداً بالرغم انه ...[QUOTE]
وبالمناسبة فإن هندسة البرمجيات تعتمد على المبرمج اعتماد كلي لعدة اسباب من اهمها ان كثير من المبرمجين الذين يبرمجون في المنتدى لا يعرفون كل ما هو متعلق بكل لغة برمجة على سبيل المثال ولا يستعملون جميع الأجزاء الموجودة في لغة البرمجة مثلا في السي شارب هل الجميع يستطيعون برمجة تعدد الأوجه للدالة الميثود سؤال .
[QUOTE]هندسة البرمجيات لا تدخل في حسبانها مسألة مدى احترافية المبرمج[/QUOTE]
من قال هذا الكلام ولماذا نعتمد نحن على كلام ربما ليس دقيقا 100 % .

Quote

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

Quote

المشاريع الكبيرة هي تلك الاكثر من 100 سنة-مبرمج (اقرأ الجزء الثاني من التلخيص) و سيدهشك ان معظم المشاريع التجارية تندرج تحت اقل من 20 سنة-مبرمج و هي المشاريع التي تركّر عليها صنعة البرمجيات..

مشكور يا عز على المشاركة المميزة ;)

Quote

لا اعرف اين كلمة ممتع في موضوعي .. للأسف لم افهمك؟؟

Quote

الكاتب و الله مش انا ..

الان مع الختام و افضل نقطة في الموضوع حتى الان:

Quote

هل تعرف ان هذه الجملة هي اهم شئ طلعت بيه من الكتاب؟؟؟
هندسة البرمجيات بتقول : "لا تبدأ بالتكويد قبل الانتهاء من تحديد المتطلبات و من التصميم؟"
طب ليه اصدقها؟؟
هندسة البرمجيات تقول: "كل مبرمج يقوم بجزء واحد فقط و لا يقوم بعمل اجزاء اخرى لأن المبرمج لن يكون قادر على اتقان في اكثر من جزء"
و ليه اصدقها؟؟

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

يا ريت الوصلة للكتاب لان الكتاب بحاول أنزلة و مش راضي ينزل
شكرا

تم تعديل هذه المشاركة بواسطةneo: 08/05/2005 - 12:23 PM

[B]انا من راى ان ما تقوله شيئ جدي وهى مسالة الاحتراف ولكن هناك شيء مهم وهو مسالة التطوير فان هندسة البرمج تسهل عملية التطوير اخي
مشكووووووور جدددددددا علي هذه المشاركة الرائعة

انا من راى ان ما تقوله شيئ جدي وهى مسالة الاحتراف ولكن هناك شيء مهم وهو مسالة التطوير فان هندسة البرمج تسهل عملية التطوير اخي
مشكووووووور جدددددددا علي هذه المشاركة الرائعة

salamo 3alikom
ana mesh 3ayez a3alla2 3ala el mawdoo3 ad mana 3ayez ashkorak
alf alf shokr we gazakom allah 7'ayran
we isa had7'ol a2ra el part 2
3ala fekra e7na hanedrs software engineering orayyeb isa
bas 3ala kol 7al kalam el ketab mantekey el 7ad kebeer gedan wenta ra2yak tamam en yekoon wasateyya bein el nazareyeteen
Gazakom Allah 7'ayran

أنا منذ الآن أهدد أولادي: الذي لا يفلح في الدراسة سأخذه معي يشتعل في صنعتي.
و عندما يسألوني عن صنعتي أقول: مبرمج

في عملي نبدأ بالبرمجة مع عملية التحليل، ثم يعاد كتابة البرنامج مرة أخرى بعد الانتهاء من التحليل، و أنا استعير كلمة "كروكي" من المنهدسين المعماريين كاسم للمرحلة الأولى.

عليك أن لا تثق كثيرا في الإنتقادات، فالقوم يشنون الحملات لأسباب إيديلوجية في كثير من الأحيان، فمثلا هناك من يرفض الربط بين c/c++ لتلك الأسباب، هناك من يحارب البرمجة الموجهة نحو الكائنات... غريب أمر القوم.
بدل من أن تقتنع بمن يقول لك مثلا (تعتمد هندسة البرمجيات على خرافة : "مقاس واحد يناسب الجميع")، إفهم أنك إن لم تنجح في وضع "مقاس واحد يناسب الجميع"، فمعنى ذلك أنك لم تقم بعمل هندسة برمجيات... هذا مجرد مثال.

ليلة سعيدة.

بسم الله الرحمن الرحيم

حقيقة موضوع شيق

انا لم اقرأ الكتاب و اتمنى ان تتسنى لي الفرصة لقراءته قريبا للتعرف بشكل اكبر على وجهة نظر مختلفة, و لكن مما قرأته في هذا الموضوع ارى ان الخلاف حقيقة هو حول تعريف كلمة هندسة البرمجيات Software Engineeing. اذ يبدو لي ان التعريف الذي يتبناه الكاتب (او الاستاذ الفاضل الذي قام بتلخيص الكتاب) ليس هو التعريف المقبول بشكل عام في اوساط هندسة البرمجيات. فمثلا نرى انه يقوم بفصل جذري بين مراحل الRequirements Analysis و الDesign و مرحلة كتابة الكود او الImplementation و يقوم باسثناء هذه المرحلة من مصطلح هندسة البرمجيات, بينما في الواقع هندسة البرمجيات تشمل كل هذه المراحل بداية من تحديد المتطلبات نهاية بكتابة الكود بشكل احترافي الخ.
و هذا يعني ان البرمجة هي جزء لا يتجزء من هندسة البرمجيات و ليست مرحلة لاحقة تابعة لها, و بالتالي فلا يوجد تجاهل او هضم لحقوق المبرمج او اى شيء من هذا القبيل.

Quote

ما وصفته هنا بالفصل بين الادوار ليس هو ما تنادي به هندسة البرمجيات على الاطلاق, بل هو مجرد نموذج للعملية يعرف باسم Waterfall Model و هو في الحقيقة نموذج Model قديم لم يعد هو الاكثر انتشارا حاليا بل الان اصبحت هندسة البرمجيات تنادي بنماذج اكثر مرونة مثل Evolutionary Development و Agile Methods و هذه النماذج تنادي بسرعة البرمجة و التطوير ثم الاضافة على المراحل السابقة الى ان يكتمل البرنامج, بحيث انه لا يوجد فصل حاد بين مراحل العملية البرمجية بل كل المراحل تعمل معا بشكل متوازي قدر الامكان.

Quote

و هو كلام يصلح كانتقاد لنموذج الشلال Waterfall Model و ليس لمجال هندسة البرمجيات ككل. فهندسة البرمجيات من اهم اولوياتها و اهتماماتها هي تصميم البرنامج و كتابة الكود بشكل يتيح له التغير و التطوير بشكل مرن و سهل و بالتالي فكون التغيرات كابوس فهو امر صحيح و لكنه احد الاسباب الرئيسية لنشوء مجال هندسة البرمجيات. فهندسة البرمجيات اذا تحاول التخلص من هذا الكابوس او بمعنى ادق حل جميع المشاكل التي تترتب عليه. و لعل كل من قرأ اى كتاب في هندسة البرمجيات وجد كلمة "The Only Constant is Change" اى ان الثابت الوحيد في البرمجة هو التغيير ثم يشرح لك الكتاب كيف تقوم بتصميم و برمجة البرامج بشكل يتيح لها التكيف مع هذا الثابت الوحيد الا و هو التغير.

و السلام