كتاب "شهر الرجل الأسطوري ، أو كيف يتم إنشاء أنظمة البرمجيات"

مرحبا سكان! قلة من الكتب حول إدارة المشاريع لا تقل أهمية عن كتاب شهر الرجل الأسطوري. مزيج من أمثلة تطوير البرامج الحقيقية والآراء والأفكار يخلق صورة حية لإدارة المشاريع المعقدة. تستند هذه المقالات إلى خبرة بروكس الخمسين كمدير مشروع لنظام IBM System / 360 ثم OS / 360. صدرت الطبعة الأولى من الكتاب قبل 45 عامًا والثانية قبل 25 عامًا. منهجيات جديدة آخذة في الظهور ، ولغات برمجة جديدة آخذة في الظهور ، وعدد المعالجات آخذ في الازدياد ، لكن هذا الكتاب لا يزال ذا صلة. لماذا ا؟ بعد نصف قرن ، واصلنا تكرار الأخطاء التي وصفها بروكس. تبدو بعض الموضوعات التي نوقشت في الكتاب قديمة ، لكن هذا مجرد مظهر. لا تزال المشاكل الأساسية الكامنة وراءها قائمة حتى اليوم. من المهم أن تعرف ماضيك لكي تفهمحيث تتطور صناعة تطوير البرمجيات. لذلك ، بعد 45 عامًا نقرأ بروكس ، لقد تغير الكثير في العالم ، لكن تسع نساء ما زلن غير قادرات على الإنجاب في شهر واحد.

مقتطف. الأرستقراطية والديمقراطية وتصميم النظم

هذه الكنيسة الرائعة هي عمل فني بارز. لا يوجد جفاف أو ارتباك في العقائد التي تظهرها ...



هذا هو ذروة الأسلوب ، عمل الفنانين الذين فهموا واستوعبوا كل نجاحات أسلافهم ، الذين أتقنوا أسلوب عصرهم تمامًا ، لكنهم استخدموه دون إظهار غير محتشم أو عرض سخيف للمهارات.



ومما لا شك فيه أن فكرة المخطط العام للمبنى تعود إلى جان دوربيت الذي حظي بالاحترام ، على الأقل في عناصره الأساسية ، من قبل خلفائه. هذا هو أحد أسباب التناسق والوحدة غير العادية للمبنى.



دليل كاتدرائية ريمس

النزاهة المفاهيمية

تم بناء معظم الكاتدرائيات الأوروبية تدريجيًا ، وتختلف الأجزاء التي بناها بناة من أجيال مختلفة من حيث الطراز المعماري. تم إغراء البناة اللاحقين بـ "تحسين" تصميمات التصميمات السابقة ، مسترشدين بالتغيرات في "الموضة" المعمارية والذوق الشخصي. لذلك ، يتاخم الجناح النورماندي السلمي ويتناقض مع صحن الكنيسة القوطي المرتفع ، والنتيجة هي مدح مجد الله بقدر ما هو مدح لكبرياء البناة.



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



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



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



- كيف نحقق التكامل المفاهيمي؟



- أليست هذه الحجة ذريعة للنخبوية أو الأرستقراطية للمهندسين المعماريين أمام حشد من المنفذين العامين ، الذين يتم قمع مواهبهم وأفكارهم الإبداعية؟



- كيف تحمي المهندسين المعماريين من الانجراف إلى اللون الأزرق بمواصفات غير مطبقة أو باهظة الثمن؟



- كيف يمكن التأكد من أن كل التفاصيل الصغيرة للمواصفات المعمارية يتم عرضها على المنفذ ، وفهمها بشكل صحيح ودقيق في المنتج؟

تحقيق التكامل المفاهيمي

الغرض من نظام البرمجة هو تسهيل استخدام الكمبيوتر. للقيام بذلك ، فإنه يوفر اللغات وأدوات الدعم المختلفة ، والتي هي في الواقع برامج تسمى وتديرها القدرات اللغوية. لكن هذه الأدوات لها ثمن: الوصف الخارجي لنظام البرمجة أكبر من 10 إلى 20 مرة من الوصف الخارجي لنظام الكمبيوتر نفسه. من الأسهل على المستخدم تعيين أي وظيفة فردية ، ولكن اختياره واسع النطاق ، وهناك العديد من الخيارات والتنسيقات التي يجب وضعها في الاعتبار.



يتم تبسيط الاستخدام فقط إذا كان الوقت المكتسب في المواصفات الوظيفية أكبر من الوقت الضائع في استيعاب الدليل المرجعي وحفظه والبحث فيه. في أنظمة البرمجة الحديثة ، لا يتجاوز هذا الكسب التكلفة ، ولكن في السنوات الأخيرة ، يبدو أن نسبة الربح إلى التكلفة قد انخفضت مع إضافة المزيد والمزيد من الميزات المعقدة. تطاردني ذاكرة سهولة استخدام IBM 650 ، حتى بدون لغة التجميع أو أي برنامج آخر على الإطلاق.



نظرًا لأن الهدف هو سهولة الاستخدام ، فإن علاقة الوظيفة هذه بالتكامل المفاهيمي هي الاختبار النهائي لتصميم النظام. لا تحدد الوظائف والبساطة وحدهما التصميم الجيد.

هذه الأطروحة يساء فهمها على نطاق واسع. تم الترحيب بـ OS / 360 من قبل المبدعين باعتباره أجمل نظام تشغيل تم تصميمه على الإطلاق لأنه بلا شك الأكثر وظيفية. إنها الوظيفة ، وليس البساطة ، التي كانت دائمًا مقياس التميز لمصمميها. من ناحية أخرى ، تم الترحيب بنظام مشاركة الوقت الخاص بـ PDP-10 من قبل المبدعين باعتباره الأفضل بسبب بساطة المفاهيم وضبطها. ومع ذلك ، وبأي مقياس ، فإن وظائفه لا تنتمي حتى إلى نفس فئة OS / 360. بمجرد أخذ سهولة الاستخدام كمعيار ، يصبح كل من هذه الأساليب غير متوازن ، فقط في منتصف الطريق نحو الهدف.



ومع ذلك ، بالنسبة لمستوى معين من الوظائف ، فإن أفضل نظام هو ذلك الذي يمكن فيه تحديد الأشياء بأكبر قدر من البساطة والوضوح. البساطة وحدها لا تكفي. تحقق اللغتان TRAC Mooers و Algol 68 البساطة ، مقاسة بعدد المفاهيم الأولية المتميزة. الوساطة ، ومع ذلك ، ليست من سماتهم. غالبًا ما يتطلب التعبير عن نواياك الجمع بين الأدوات الأساسية بطرق معقدة وغير متوقعة. لا يكفي دراسة العناصر والقواعد لتجميعها ؛ من الضروري أيضًا دراسة الاستخدام الاصطلاحي ، لاستيعاب مجموعة كاملة من المعرفة حول كيفية دمج العناصر في الواقع. تأتي البساطة والاستقامة من تكامل المفاهيم. يجب أن تعكس كل قطعة نفس الفلسفة ونفس عملية التوازن.يجب أن يستخدم كل جزء نفس الأسلوب في بناء الجملة والمفاهيم المماثلة في علم الدلالة. وبالتالي ، فإن سهولة الاستخدام تملي وحدة التصميم ، والنزاهة المفاهيمية.

الأرستقراطية والديمقراطية

تتطلب النزاهة المفاهيمية بدورها أن يأتي المشروع من مطور واحد أو عدد صغير منهم ، يعملون في تناغم وانسجام.

يتطلب ضغط الجدول ، بدوره ، إشراك المزيد من العمال. هناك طريقتان لحل هذه المشكلة. الأول هو التقسيم الدقيق للعمل بين الهندسة المعمارية والتنفيذ. الطريقة الثانية هي طريقة جديدة لهيكلة تعليمات تنفيذ البرمجة ، تمت مناقشتها في الفصل السابق.



يعتبر فصل الجهد المعماري عن التنفيذ طريقة قوية لتحقيق التكامل المفاهيمي في المشاريع الكبيرة. لقد رأيت بنفسي أنها تستخدم بنجاح كبير على خط إنتاج IBM Stretch و System / 360 لأجهزة الكمبيوتر. وشهدت كيف أنه لم ينجح في تطوير نظام التشغيل / 360 لأنه لم يتم استخدامه بشكل كافٍ.



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



مهندس النظام ، مثل مهندس المبنى ، هو وكيل المستخدم. وتشمل مسؤولياته استخدام المعرفة المهنية والتقنية لصالح المستهلك ، وليس في مصلحة البائع ، أو الشركة المصنعة ، وما إلى ذلك.



يجب تمييز الهندسة المعمارية بوضوح عن التنفيذ. كما أشار Blaauw ، "حيث تتحدث الهندسة المعمارية عن ما يحدث ، يتحدث التنفيذ عن كيفية القيام بذلك لتحقيق ذلك." وكمثال بسيط ، يستشهد بساعة تتكون هندستها المعمارية من قرص وعقارب وتاج. عندما يتعلم الطفل هذه الهندسة المعمارية ، سيكون قادرًا على معرفة الوقت بنفس السهولة من خلال ساعة يده والساعة على برج الكنيسة. يصف التنفيذ وتطبيقه ما يحدث داخليًا: نقل الجهد والتحكم في الدقة بواسطة كل من الآليات العديدة.



على سبيل المثال ، في System / 360 ، يتم تنفيذ بنية كمبيوتر منفصلة بشكل مختلف تمامًا في كل من النماذج التسعة. في المقابل ، يخدم التنفيذ المنفصل وتدفق البيانات والذاكرة والرمز الصغير لنظام Model 30 في أوقات مختلفة أربع بنيات مختلفة: الكمبيوتر System / 360 ، والقناة متعددة الإرسال مع 224 قناة فرعية مستقلة منطقيًا ، والقناة المحددة ، والكمبيوتر 1401.



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



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



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



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



هناك العديد من الأمثلة من الفنون والحرف اليدوية التي تؤدي إلى الاعتقاد بأن الانضباط يحسن الحرفية. في الواقع ، يقول قول الفنان: "الشكل يتحرر". أسوأ الهياكل هي تلك التي كانت ميزانيتها كبيرة جدًا بحيث لا يمكن تقديم الخدمة لها. لم يتم قمع النشاط الإبداعي لباخ بسبب الحاجة إلى نشر أقاليم أسبوعية محدودة الشكل. أنا متأكد من أن الكمبيوتر Stretch سيكون له بنية أفضل إذا كان أكثر تقييدًا ؛ في رأيي ، كانت قيود الميزانية في نظام System / 360 Model 30 مفيدة لمعمارية الطراز 75 من جميع النواحي.



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



هذا التأثير ، الذي رأيته عدة مرات ، أكده RW Conway ، الذي قامت مجموعته في Cornell ببناء مترجم PL / C لـ PL / 1. ويشير إلى ما يلي: "في النهاية قررنا تطبيق اللغة دون تغييرات وتحسينات ، لأن مناقشة اللغة ستستهلك كل طاقتنا".

ماذا يجب أن يفعل المنفذ أثناء الانتظار؟

إنه لأمر مهين أن ترتكب خطأ بمليون دولار ، لكنه لا يُنسى. أتذكر بوضوح الليلة التي قررنا فيها كيفية تنظيم الكتابة الفعلية للمواصفات الخارجية لنظام التشغيل OS / 360. لقد قمت أنا ومدير الهندسة المعمارية ومدير برنامج التحكم بوضع الخطة والجدول الزمني وتعيين المسؤوليات.



كان لدى مدير الهندسة المعمارية 10 أشخاص موهوبين. وجادل بأنهم يستطيعون كتابة المواصفات والقيام بذلك بشكل صحيح. سيستغرق الأمر 10 أشهر ، أي ثلاثة أشهر أكثر مما يسمح به الجدول الزمني.



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



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



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



بالنسبة للاقتراح بأن يقوم فريق معماري صغير بالفعل بكتابة جميع المواصفات الخارجية لجهاز كمبيوتر أو نظام برمجة ، يطرح المنفذون ثلاثة اعتراضات:

• ستكون المواصفات غنية جدًا بالميزات ولن تعكس التكلفة العملية.
• سوف يتمتع المهندسون المعماريون بكل المتعة الإبداعية وسيتخلون عن براعة المنفذين.
• سيتعين على العديد من الفنانين الجلوس مكتوفي الأيدي بينما تمر المواصفات عبر عنق الزجاجة للفريق المعماري.

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



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



ومع ذلك ، في مجال أنظمة الكمبيوتر ، تكون الوتيرة أسرع ويريد الجميع الضغط على الجدول قدر الإمكان. إلى أي مدى يمكن أن تتداخل المواصفات والتطوير؟



كما يشير بلاوف ، فإن الجهد الإبداعي الشامل يتضمن ثلاث مراحل متميزة: الهندسة المعمارية والتنفيذ والتنفيذ. اتضح أنه يمكنهم بالفعل البدء بالتوازي والاستمرار في نفس الوقت.



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



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



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



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



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





»يمكن العثور على مزيد من التفاصيل حول الكتاب على موقع الناشر

» جدول المحتويات

» مقتطفات



للساكنين خصم 25٪ على القسيمة - بروكس



عند الدفع مقابل النسخة الورقية من الكتاب ، يتم إرسال كتاب إلكتروني إلى البريد الإلكتروني.