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

(١) أزمات البرمجيات

كانت السنوات الأولى للكمبيوتر ذي البرنامج المُخزَّن انتصارًا لهندسة الكمبيوتر. وتَصدَّر تطوير الأجهزة العناوين الرئيسية، من «العقل الخارق الحاسوبي» إلى «آلة التفكير المُذهلة». عرضت الصحافة أجهزة العقل الخارق الحاسوبية التي تزن عشرات الأطنان والتي تعمل أسرعَ ألف مرةٍ من آلات الحوسبة السابقة، والأهم من ذلك، يُمكنها إجراء العمليات الحسابية أسرع آلاف المرَّات من أفضل علماء الرياضيات في العالم. في الماضي كان يُحتفَى بالرياضيات والمنطق باعتبارهما الميزة التي ميَّزت البشَر عن الحيوانات، والآن يمكن للآلات أن تفعل كليهما.

سرعان ما انتقل الحماس المُبكر لأجهزة الكمبيوتر من «تكوين الأعداد» — كما أطلق أحد روَّاد الحوسبة على الحوسبة العلمية — إلى معالجة البيانات في الرموز التي يُمكنها تمثيل أي معلومات على الإطلاق. وضربت المَجلات والصحف أمثلةً على أجهزة الكمبيوتر التي تؤدي مهامَّ كانت تُعَد في الماضي من اختصاص البشر وحدَهم: فبرمجَت مجموعةٌ منها الكمبيوترَ ليلعب الداما، وأخرى برمجَتْه ليلعب الشِّطْرَنج، وأخرى برمجته لإثبات المُبرهنات الموجودة في كتاب «مبادئ الرياضيات»، وأخرى لإنشاء فأرٍ آلي يجد طريقه عبر متاهة. وتضاعفت استخدامات أجهزة الكمبيوتر في مجالات التجارة والعلوم والتطبيقات الهندسية كل عام. وجاءت كل هذه التطوُّرات من البرمجيات. لقد بدأت ثورة الكمبيوتر بالأجهزة، لكنها سرعان ما أصبحت ثورة برمجيات.

ازداد حجم برامج الكمبيوتر وتعقيدها سريعًا. وبدأت السحب الداكنة تلُوح في الأفق في سماء تطوير البرامج. وأصبح المطوِّرون يُدركون بوضوح الصعوبات الكبيرة التي تُواجههم في إنشاء برامج عالية الجودة؛ أو بالأحرى برامج موثوق بها يمكن الاعتماد عليها وقابلة للاستخدام وآمنة. ولم تكن الأدوات الفكرية والإدارية المُطوَّرة حتى ذلك الوقت قويةً بما يكفي لإنشاء مثل هذه البرامج. ومن ثَمَّ بدأ المُطوِّرون يتحدثون عن «أزمة البرمجيات».

في اجتماعَين شهيرَين تحت رعاية منظمة حلف شمال الأطلسي (الناتو) في عامَي ١٩٦٨ و١٩٦٩، لجأ مطوِّرو البرمجيات إلى الهندسة بحثًا عن حلٍّ للمشكلات المُتكررة وأحيانًا الكارثية للبرمجيات. وأطلق على هذه الحركة اسم «هندسة البرمجيات». كان لدى الهندسة تاريخ طويل من إنتاج نظمٍ موثوق بها طوال الوقت. فقد كان من النادر سقوط الجسور أو تحطُّم الطائرات أو انهيار البنية التحتية على نطاقٍ واسع. ومن ثَمَّ، سرعان ما بدأ مهندسو البرامج في جلب أساليب الهندسة وتطويرها في تطوير البرمجيات وإدارتها.

ذكر رائد البرمجيات فريد بروكس في كتابه الكلاسيكي «خرافة شهر العمل» (١٩٧٥)، بُعدَين لتحويل البرامج إلى نظم إنتاج. الأول: هو تعميم برنامج حاسوبي واحد على نظامٍ من البرامج المتفاعلة. والثاني: هو إضافة الهياكل والمكوِّنات التي تضمن موثوقية البرامج. وكانت قاعدته العامة هي أن الحركة في أي بُعد من هذَين البُعدَين تُضاعِف الجهد المبذول ثلاثَ مرات. ويجب أن نتحرك في كِلا البُعدَين معًا لتحقيق نظُم إنتاج موثوق بها؛ وهو ما يفوق جهود إنشاء برنامجٍ واحدٍ بمقدار تسع مرات.

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

يمكن وصف التحول الذي تحدَّث عنه بروكس بأنه تحول من التفكير الحوسبي على نطاق الأفراد (تصميم وكتابة برامج فردية) إلى التفكير الحوسبي على نطاق المجموعات (تصميم نظم البرمجيات وإدارة مشروعات البرمجيات التي تنشئها بداية من التصميم ووصولًا إلى الإنتاج والصيانة).

(٢) العلم والهندسة في الحوسبة

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

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

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

العبارة المألوفة «الشيطان يكمن في التفاصيل» هي شعار المهندس. إذ يجب على المهندس الاهتمام بكل التفاصيل لكي يعمل النظام الذي يُنشئه. أما العالِم، فهو يريد التخلُّص من التفاصيل حتى تبرُز الأنماط المتكررة.

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

(٣) التفكير الحوسبي على نطاق الأفراد

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

مع تزايُد معرفة مصمِّمي اللغات البرمجية بممارسات البرمجة، طوَّروا لغات برمجة عالية المستوى، مثل «فورتران» و«كوبول» حوالي عام ١٩٥٨. سمحت هذه اللُّغات للمُبرمِجين بصياغة عبارات الخوارزمية التي يتمُّ ترجمتُها تلقائيًّا بواسطة برنامج التحويل البرمجي إلى تعليمة آلة؛ مما خفَّف عن المُبرمِجين عبء البرمجة المباشرة لتعليمة الآلة. وعندما رأى مُصمِّمو اللغات أن المُبرمِجين غالبًا ما يبدءون بتصميم هياكل البيانات ثم مجموعة صغيرة من الروتينات الفرعية التي تقوم بعمليات على الهياكل، أعلنوا ممارسة «تجريد البيانات». ومع الوقت، تطوَّر تجريد البيانات إلى لُغات البرمجة الموجهة للكائنات. وأصبح تجريد البيانات سمةً رئيسية أخرى من سِمات التفكير الحوسبي؛ فهو يخفي الآليات الداخلية لمكوِّنات البرنامج، بينما يسمح باستخدام هذه المكوِّنات من خلال واجهات مُعرَّفة جيدًا. ويمكن للمبرمجين، بالاستعانة بتجريد البيانات، أن يركِّزوا بسهولة أكبر على ما تفعله المُكوِّنات بدلًا من التركيز على آلية عمل هذه المكونات.

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

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

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

(٤) أزمة تطوير البرمجيات

لماذا ظهرت أزمة البرمجيات مع كلِّ هذه التطوُّرات في التفكير الحوسبي؟ في حوسبة الخمسينيات من القرن العشرين، كانت الآلة هي المُنتَج. ولم تكن البرمجيات — مثل برامج التحكُّم في الآلات — شيئًا يُعبَّأ ويُباع. وركز معظم المُبرمِجين على برامج لاستخدامهم الشخصي أو لاستخدام مجموعات العمل القريبة جدًّا منهم، ولكنهم لم يهتمُّوا بإنشاء برامج للاستخدام خارج مؤسَّساتهم. ومن ثَمَّ، أدَّت أدوات التفكير الحوسبي الخاصة ﺑ «البرمجة على نطاق الأفراد» إلى دعم الاستخدام الشخصي جيدًا، ولكنها لم تدعم التطوير على نِطاق واسع للمُنتجات البرمجية المعقدة.

بدأت صناعة البرمجيات في التطوُّر من عددٍ قليل من مقاولي البرمجيات في الخمسينيات إلى مُطوِّري البرمجيات المؤسسية في الستينيات، ثم إلى البرمجيات الجاهزة للبيع في السبعينيات وما بعدها. وفي كل عَقدٍ من هذه العقود، نمت إيرادات صناعة البرمجيات عشرة أضعاف.

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

غالبًا ما تسبَّب مطورو البرامج الذين لدَيهم معرفة قليلة بمجال العمل المُستهدَف في فجواتٍ كبيرة بين احتياجات العملاء ووظائف نظم الكمبيوتر. ومن ثَمَّ، اكتشف مطورو البرامج أن مبادئ التصميم المعروفة لم تكن كافيةً لتوفير برامج موثوق بها وآمنة ويمكن الاعتماد عليها وسهلة الاستخدام. وأدرك المبرمجون المحترفون أن مهاراتهم في التفكير الحوسبي لم تصِل إلى المستوى المطلوب؛ إذ إن هناك اختلافًا نوعيًّا بين برنامج كَتبه مبرمج واحد ونظام يتطلَّب فريقًا من ٣٠٠ مبرمج.

حاولت شركات البرمجيات تقليل هذه المشكلات بطريقتَين. الأولى: هي توظيف مُبرمجين ذوي مهارات كبيرة، يُمكنهم إنتاج كَمياتٍ أكبر بكثير من التعليمات البرمجية يوميًّا، بأقل عدد من الأخطاء مقارنة بالمُبرمِجين المبتدئين. وارتفعت رواتب المبرمِجين المهَرة، وأصبح تطوير البرامج من أعلى المِهن أجرًا في الولايات المتحدة.

أما الطريقة الثانية: فهي التخلِّي عن مسئولية الأخطاء. تبنَّت شركات البرمجيات سياسة «عدم الضمان»؛ حيث يُرخَّص البرنامج للمُستخدِم فقط بعد موافقته على أن الشركة لن تتحمَّل المسئولية عن الأضرار الناجمة عن الأخطاء في التعليمات البرمجية. ساهمت هذه السياسة بشكلٍ كبير في إصابة الجمهور بخيبة أمَل في ثورة الكمبيوتر.

اعترف مُطوِّرو البرامج الرائدون أن أدوات البرمجة على نِطاق الأفراد لم تكن ببساطةٍ كافيةً للبرمجة على نطاق المجموعات. فقد وصلوا إلى مرحلةٍ أصبح فيها من الصعب إنشاء برامج موثوق بها بالأدوات المُتوفرة. وأعلن عددٌ من الشخصيات الرائدة في صناعة البرمجيات والأكاديميين ومُطوري البرامج عن أزمةٍ في مجال البرمجيات، ونظَّموا مؤتمرَين تحت رعاية منظمة حلف شمال الأطلسي (الناتو) في عامَي ١٩٦٨ و١٩٦٩ لحلِّ هذه الأزمة.

(٥) التفكير الحوسبي على نطاق المجموعات

ماذا يحدث عندما ننتقل من برامج فردية ذات مُستخدِمين فرديِّين إلى نُظم مكوَّنة من العديد من البرامج التي يستخدمها العديد من المُستخدمين؟ المهارات والقدرات المطلوبة لكتابة برنامج مكوَّن من ألف سطر من التعليمات البرمجية تختلف عن تلك اللازمة لإنشاء برنامج يتكوَّن من مليون سطر. والسبب الرئيسي وراء هذا الاختلاف هو أن نُظم البرمجيات الكبيرة يجِب إنشاؤها من قِبَل فرق عمل. وكان على مطوِّري البرامج تعلم كيفية تنظيم الفِرق وإدارتها للنجاح في تطوير البرامج.

كان فريد بروكس مدير فريق مؤلَّف من ٣٠٠ مبرمج أنشَئوا نظام التشغيل «آي بي إم ٣٦٠» في الستينيَّات من القرن العشرين. وأصبح نظامهم في النهاية مكوَّنًا من ١٠ ملايين سطر من التعليمات البرمجية. وقد وثَّق بروكس تجرِبته بالتفصيل في كتابه «خرافة شهر العمل» (١٩٧٥) وأعطى روتينًا قائمًا على التجرِبة العملية للتفكير الحوسبي لتصميم النظم الكبيرة وتنظيمها. إحدى ملاحظاته الشهيرة هي أن زيادة عدد الأشخاص لا يعني بالضرورة تقليل الوقت بالنسبة نفسها؛ فالفريق المكوَّن من ١٢ مبرمجًا لا يستطيع في شهرٍ واحد إكمال وظيفة استغرقت من مبرمج واحد ١٢ شهرًا لتنفيذها. ملاحظة أخرى هي أن هيكل البرنامج يتماثل في النهاية مع الهيكل التنظيمي للمؤسسة التي أنشأته. وخلص بروكس إلى أن إدارة الفريق كانت تحديًا أكبر من مشكلات التقنية التي يتعيَّن على الفريق حلُّها.

على الرغم من اتفاق الحضور في مؤتمرَي الناتو على وجود «مشكلة برمجيات» كبيرة وأن مبادئ الهندسة قد تساعد في حلِّ هذه المشكلة، فإنهم لم يتَّفقوا على نوع الهندسة الذي سيؤدي المهمة. اعتقد المهندسون التقليديون أن الحل هو التصميم القائم على تحمُّل الأخطاء، وفكر المنظومة، وإدارة المشروعات. أما علماء الكمبيوتر المُهتمون بالنظريات، فتطلَّعوا إلى البرهان الرياضي (التحقُّق الشكلي) لتحديد ما إذا كانت البرامج تفي بمواصفاتها دون أخطاء، وقدَّموا أساليب مثل البرمجة المُهيكلة وتحليل الخوارزميات لتسهيل فَهم البرامج والتحقُّق منها.

لم يؤثر أيٌّ من هذَين النهجَين بشكلٍ كبير على مشكلة البرمجيات. لم تنجح هندسة النظم التقليدية بسبب وجود فرقٍ كبير بين البرمجيات والنظم الكبيرة الملموسة، مثل الكباري والمباني والطائرات والسفن؛ فقد يؤدي خطأ في بت واحدٍ من التعليمات البرمجية إلى كارثة مُحقَّقة مثل تحطُّم صاروخ، في حين أن فقدان جزء صغير من المادة قد يؤدي إلى الحطِّ من قيمة نظام كبير ولكن لن يتسبَّب في تحطُّمه. لم ينجح البرهان الرياضي لأنه كان صعبًا للغاية بالنسبة إلى النظُم الكبيرة، ولم يقل شيئًا عن الجوانب البشرية مثل سهولة الاستخدام، كما لم يتعامل مع أعطال الأجهزة مثل تعطُّل مُكوِّن من مُكوِّنات الكمبيوتر أو الضوضاء التي تفسد الإشارات. كان رائدا البرمجيات برايان رانديل وفريد بروكس من بين الأكثر بصيرةً وبُعدًا للنظر في شرح سبب صعوبة نظم البرمجيات. قال رانديل إن المشكلة لم تكن البرمجة في حدِّ ذاتها، بل «التطوير المُتعدِّد الأشخاص لبرامج مُتعددة الإصدارات». وقال بروكس في كتابه الذي صدر عام ١٩٧٥ إن مسألة تحويل البرنامج إلى مُنتَج من خلال تحويله إلى نظامٍ يمكن لغير المُبرمِجين استخدامه بأمانٍ وبشكل موثوق به كانت أكثر تحديًا بكثيرٍ من كتابة البرنامج في المقام الأول.

(٦) مبادئ التصميم والأنماط والتلميحات

لُخِّصَت أهداف البرمجة على نِطاق المجموعات في خمسة أهداف: إمكانية الاعتماد عليها، والموثوقية، وقابلية الاستخدام، والسلامة، والأمن. ولتحقيق هذه الأهداف، يستخدِم مطوِّرو البرامج ثلاثة أنواع من مُمارسات التفكير الحوسبي: مبادئ التصميم، والأنماط، والتلميحات.

مبادئ التصميم هي وصفٌ للمهارات والاستراتيجيات التي يتبعها المُطوِّرون عند اتخاذ قرارات التصميم. تُوجههم المبادئ نحو تصميماتٍ تُلبي الأهداف الخمسة.

أنماط التصميم هي وصف للمواقف الشائعة التي مِن المُحتمَل أن يُواجهها المبرمج. وتقدِّم توجيهاتٍ حول كيفية هيكلة البرنامج أو عملية كتابته للحصول على أفضل النتائج.

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

(٧) مبادئ التصميم الخاصة بالبرمجيات

تُسجِّل أدبيات هندسة البرمجيات عددًا كبيرًا من مبادئ التصميم التي دُرِسَت على نطاقٍ واسع ووُجِد أنها تدعم التصميم الجيد بقوة. وقد شُفِّرت أفضل هذه المبادئ على هيئة هياكل تظهر في لُغات البرمجة وبرامج التطبيقات ونُظم التشغيل. وكثيرًا ما تُذْكَر هذه المبادئ في مناقشات التفكير الحوسبي وتكمُن جذورها في العديد من التقاليد الفكرية المُختلفة الموضحة في الفصول السابقة من هذا الكتاب. وتنقسِم إلى ثلاث فئاتٍ رئيسية:

تهدف هذه الهياكل إلى المساعدة في الأنماط المُتكررة التي يُواجهها المُصمِّمون.

(٨) لا تُوجَد حلول سهلة

في عام ١٩٨٧، كتب فريدريك بروكس مقاله المُعنوَن «لا توجد حلول سهلة» وذكر فيه تقييمه الشهير لمدى التقدُّم المُحرَز في هندسة البرمجيات منذ عام ١٩٦٨. وحملت النتائج التي توصَّل إليها دروسًا مهمةً تخصُّ التفكير الحوسبي. قال بروكس إن هناك عاملَين رئيسيَّين للتعقيد يؤثران في قُدرتنا على إنتاج برامج موثوق بها.

لمواجهة ذلك، نحتاج إلى تطوير النُّظم الكبيرة على مراحل سهلة نسبيًّا، وإعادة استخدام البرامج الحاليَّة قدْر الإمكان، واستخدام المزيد من النماذج الأولية السريعة للحصول على تقارير مُبكرة قبل اتخاذ القرارات التقنية. وقال بروكس إن الأهم من ذلك هو أننا بحاجةٍ إلى «إعداد مُصمِّمين عظماء». وكان يرى أن التعامُل مع التعقيد مهارة أساسية تتطلَّب إتقانًا كبيرًا. ولهذا كتب بروكس مقاله الشهير الذي قال فيه «لا تُوجَد حلول سهلة» لمشكلة التعقيد في تطوير البرمجيات.

كانت «مشكلة البرمجيات» التي أُثِيرت في مؤتمرَي الناتو تخصُّ في الغالب إنتاجية المُبرمِجين ووجود أخطاء في البرامج تتسبَّب في عدم موثوقيتها. ومنذ تلك الأيام، أضافت التطوُّرات الجديدة إلى تعقيدات تصميم البرمجيات. ومن هذه التعقيدات:

يواجه التفكير الحوسبي باستمرار تحديات فيما يخصُّ تطوُّرَه وتعامُلَه مع هذه المشاكل المعاصرة.