قوانين البرمجة

القوانين والنظريات والمبادئ والأنماط المفيدة للمطورين


المقدمة


ترجمة المستودعات github.com/dwmkerr/hacker-laws

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

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

القوانين


قانون أمدل


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

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

يوضح الرسم البياني التالي أمثلة على مكاسب السرعة المحتملة:



كما ترى ، حتى إذا كان من الممكن موازاة 50٪ من البرنامج ، فإن فوائد إضافة أكثر من 10 معالجات منفصلة ستكون ضئيلة. إذا كان من الممكن موازاة البرنامج بنسبة 95٪ ، فستكون التحسينات ملحوظة حتى بعد إضافة آلاف المعالجات.

مع تباطؤ قانون مور وتسريع المعالج ، يصبح التوازي مفتاح تحسين الكفاءة. تعد برمجة الرسومات مثالًا رائعًا - تسمح لك البرمجة الحديثة القائمة على التظليل برسم أجزاء من الصورة بالتوازي ، لذلك في بطاقات الرسومات الحديثة ، يمكنك العثور على آلاف نوى المعالج (وحدات معالجة الرسومات أو وحدات التظليل).

نظرية النوافذ المكسورة


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

تم تطبيق هذه النظرية على تطوير البرمجيات ، مما يشير إلى أن ضعف جودة الشفرة (أو ما يسمى " الدين التقني ") قد يسبب الشعور بأن كل محاولات تحسين الجودة سيتم تجاهلها أو التقليل من شأنها ، مما سيؤدي إلى ظهور رمز سيئ جديد. يتطور هذا التأثير في الشلال ، ولهذا السبب تتدهور الجودة بمرور الوقت.

قانون بروكس


أدت إضافة موارد بشرية إضافية إلى مشروع متأخر إلى تأخير إنتاجه أكثر.


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

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

هذا هو الموضوع الرئيسي لكتاب Mythical Man-Month.

قانون كونواي


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

قانون كننغهام


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


يقول ستيفن ماكجيدي أنه في أوائل الثمانينيات ، قدم له وارد كانينجهام النصيحة: "إن أفضل طريقة للعثور على الإجابة الصحيحة على الإنترنت هي عدم طرح سؤال ، ولكن نشر إجابة خاطئة عمدا." أطلق عليها مكجيدي اسم "قانون كننغهام" ، على الرغم من أن كننغهام نفسه ينكره ويقول إنه "تم اقتباسه بشكل غير صحيح". على الرغم من أن العبارة تشير أصلاً إلى الاتصال على Usenet ، فقد تم استخدام القانون منذ ذلك الحين لوصف العمل والمجتمعات الأخرى (Wikipedia ، Reddit ، Twitter ، Facebook).

رقم دنبار


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

العدد الدقيق لهذه العلاقات غير معروف. اقترح دنبار نفسه أنه لا يمكن لشخص أن يدعم بشكل مريح أكثر من 150 من هذه الاتصالات. ووصف ذلك في سياق اجتماعي أكثر: "عدد الأشخاص الذين لا تتردد في الانضمام إليهم بدون دعوة للشرب معًا إذا صادفتهم عن غير قصد في الحانة". عادةً ما تختلف تقديرات هذا الرقم من 100 إلى 250.

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

قانون جول


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


يقترح قانون غول أن محاولات تطوير نظام معقد للغاية ستفشل على الأرجح. نادرًا ما يتم إنشاء أنظمة عالية التعقيد في جلسة واحدة - فهي تتطور من أنظمة أبسط.

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

قانون Goodhart


يميل أي نمط إحصائي ملاحظ إلى الانهيار بمجرد ممارسة الضغط عليه للسيطرة عليه.


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


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

أمثلة:

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

Hanlon Razor


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

قانون هوفستادر


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

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

اقتبس من كتاب " Gödel ، Escher ، Bach: This Endless Garland ."

قانون هتبر


التحسين يعادل الدمار.

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

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

دورة الضجيج وقانون عمار


نميل إلى المبالغة في تقدير تأثير التكنولوجيا على المدى القصير والتقليل من شأنها على المدى الطويل.

دورة الضجيج هي تصور للحماس وتطوير التكنولوجيا بمرور الوقت ، تم بناؤه في الأصل من قبل جارتنر. يتم توضيحه بشكل أفضل من خلال الرسم البياني:


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

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

قانون حيرام


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


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

قانون كيرنيجان


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


تمت تسمية قانون كيرنيجان على اسم بريان كيرنيجان ، وهو مأخوذ من كتاب كتبه هو وبلوغر: "عناصر أسلوب البرمجة".

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

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

قانون ميتكالف


في نظرية الشبكة ، تزداد فائدة الشبكة تقريبًا كمربع من عدد مستخدميها.

يعتمد القانون على عدد الاتصالات المحتملة الزوجية داخل النظام ، ويرتبط ارتباطًا وثيقًا بقانون ريد. جادل Odlyzhko وآخرون بأن قوانين Reed و Metcalf بالغت في قيمة النظام ، دون مراعاة قيود القدرة البشرية على فهم الشبكة ؛ انظر رقم دنبار.

قانون مور


يتضاعف عدد الترانزستورات الموضوعة على شريحة دارة متكاملة كل 24 شهرًا تقريبًا.

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

قانون مورفي


كل شيء يمكن أن يحدث خطأ سيحدث خطأ.

قانون مورفي ، من تأليف إدوارد ميرفي ، يفترض أن أي شيء يمكن أن يحدث خطأ سيحدث بالضرورة خطأ.

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

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

الحلاقة أوكام


لا يجب أن تضاعف الأشياء دون داع.

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

قانون باركنسون


العمل يملأ الوقت المخصص لها.

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

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

تأثير التحسين المبكر


التحسين المبكر هو أصل كل الشر.

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

ومع ذلك ، يمكن أيضًا وصف التحسين المبكر بأنه محاولة لتحسين شيء ما قبل أن نفهم ما يتعين علينا القيام به.

قانون بات


يهيمن على القطاع التكنولوجي نوعان من الناس: أولئك الذين يفهمون أنهم لا يسيطرون ، والذين يسيطرون على ما لا يفهمونه.


بالنسبة للقانون ، غالبًا ما يجب على باتا إبرام باتا:
في أي تسلسل هرمي تقني ، يتم تطوير عكس الكفاءة بمرور الوقت.

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

ومع ذلك ، يجدر التأكيد على أن هذه القوانين هي تعميم عام للغاية ، وقد تنطبق على بعض أنواع المنظمات ، ولا تنطبق على غيرها.

قانون ريد


تتزايد فائدة الشبكات الكبيرة ، وخاصة الشبكات الاجتماعية ، بشكل كبير مع نمو حجم الشبكة.

يعتمد هذا القانون على نظرية الرسم البياني ، حيث يتم قياس المنفعة على أنها عدد المجموعات الفرعية المحتملة ، والتي تنمو بشكل أسرع من عدد المشاركين أو الاتصالات الزوجية المحتملة. جادل Odlyzhko وآخرون بأن قوانين Reed و Metcalf بالغت في قيمة النظام ، دون مراعاة قيود القدرة البشرية على فهم الشبكة ؛ انظر رقم دنبار.

قانون الحفاظ على التعقيد (قانون تيسلر)


ينص القانون على أن النظام لديه تعقيد معين ، والذي لا يمكن تقليله.

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

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

قانون التجريد المتدفق


تخضع جميع التجريدات غير التافهة للتدفق إلى حد معين.

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

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

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

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

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

قانون التفاهات


ينص القانون على أن المجموعات تقضي وقتًا واهتمامًا أكبر بكثير في مناقشة القضايا التجميلية أو التافهة مقارنةً بالقضايا الخطيرة والشاملة.

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

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

فلسفة يونكس


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

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

نموذج Spotify


نهج هيكل الفريق والتنظيم الذي تروج له Spotify . في هذا النموذج ، يتم تنظيم الفرق حول وظائف البرنامج ، وليس حول التكنولوجيا.

يعزز النموذج أيضًا مفاهيم القبائل والنقابات والفروع - المكونات الأخرى للهيكل التنظيمي.

قانون وادلر


في تصميم أي لغة ، يتناسب إجمالي الوقت المستغرق في مناقشة ميزة من هذه القائمة مع قوة رقم موضع هذه الميزة في القائمة.
0. علم الدلالة.
1. بناء الجملة.
2. بناء الجملة المعجمية.
3. الصيغة المعجمية للتعليقات.

أي أنه مقابل كل ساعة تقضيها في علم الدلالة ، هناك 8 ساعات تم قضاؤها في سياق التعليقات.

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

قانون ويتون


لا تكن ماعز.

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

مبادئ


غالبًا ما ترتبط المبادئ بالمشورة بشأن تصميم البرامج.

مبدأ ديلبرت


في الشركات ، هناك ميل لترقية الموظفين غير الأكفاء إلى المديرين للقضاء عليهم من عملية العمل.

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

مبدأ باريتو (قاعدة 80/20)


بالنسبة للجزء الأكبر ، يتم توزيع كل شيء في الحياة بشكل غير متساو.

ينص مبدأ باريتو على أنه في بعض الحالات يكون الجزء الأصغر من الاستثمار مسؤولاً عن معظم النتائج:

  • يمكن كتابة 80 ٪ من البرنامج في 20 ٪ من الوقت (والأصعب 20 ٪ يستغرقون 80 ٪ من الوقت).
  • 20٪ من الجهد يعطي 80٪ من النتيجة.
  • 20٪ من العمل يولد 80٪ من الربح.
  • تؤدي 20٪ من الأخطاء إلى 80٪ من أعطال البرنامج.
  • يتم استخدام 20٪ من الوظائف 80٪ من الوقت.

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

كما يُعرف هذا المبدأ ، كقاعدة 80/20 ، بقانون أهم صغير ، مبدأ نقص العوامل.

أمثلة: في عام 2002 ، أفادت Microsoft أنه بعد إصلاح 20٪ من الأخطاء الأكثر شيوعًا ، سيتم إصلاح 80٪ من المشاكل والأعطال ذات الصلة في Windows و Office.

مبدأ بيتر


في النظام الهرمي ، يميل كل فرد إلى الارتفاع إلى مستوى عدم أهليته.


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

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

مبدأ الموثوقية (قانون Postel)


كن متحفظًا حيال أنشطتك ، وتحرر من مساهمات الآخرين.

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

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

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

صلب


الاختصار للمبادئ الخمسة التالية:

S: مبدأ المسؤولية الفردية
O: المبدأ المفتوح / المغلق
L: مبدأ استبدال Liskov المبدأ
الأول: مبدأ فصل الواجهة [ مبدأ فصل الواجهة]
د: مبدأ انعكاس التبعية

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

مبدأ المسؤولية الوحيدة


يجب أن يكون لكل كائن مسؤولية واحدة ، ويجب أن تكون هذه المسؤولية مغلفة بالكامل في الفصل.

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

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

مبدأ الانفتاح / التقارب


يجب أن تكون الكيانات مفتوحة للتوسيع ، ولكن مغلقة للتغيير.

الثاني من مبادئ SOLID. ينص المبدأ على أن الكيانات (الفئات والوحدات والوظائف وما إلى ذلك) يجب أن تسمح بتوسيع سلوكها ، ولكن لا يجب تغيير سلوكها الحالي.

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

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

مبدأ استبدال باربرا ليسكوف


يجب أن يكون من الممكن استبدال النوع بنوع فرعي دون كسر النظام.

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

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

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

مبدأ فصل الواجهة


يجب ألا تعتمد كيانات البرامج على الأساليب التي لا تستخدمها.

الرابع من مبادئ SOLID. ينص المبدأ على أنه لا ينبغي أن يعتمد المستهلكون للمكون على وظائف المكون الذي لا يستخدمه.

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

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

مبدأ انعكاس التبعية


لا يجب أن تعتمد وحدات المستوى الأعلى على وحدات المستوى الأدنى.

خامساً من مبادئ SOLID. ينص المبدأ على أن عناصر التحكم في المستويات الأعلى لا يجب أن تعرف تفاصيل تنفيذ تبعياتها.

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

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

لا تكرر مبدأ نفسك


يجب أن يكون لكل معلومة تمثيل فريد ومتسق وموثوق داخل النظام.

لا تكرر نفسك ، أو DRY ، تساعد المطورين على تقليل إمكانية تكرار التعليمات البرمجية والاحتفاظ بالمعلومات في مكان واحد. ذكره في عام 1999 آندي هانت وديف توماس في كتابهما المبرمج العملي.

عكس مبدأ الجفاف جاف] يجب أن يكون مبدأ WET الرطب] - "كتابة كل شيء مرتين" أو "نحن نحب الكتابة" [نحن نستمتع بالكتابة].

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

مبدأ قبلة


اجعل الأمر بسيطًا وغبيًا [لا تعقد الأمور ، أيها الأحمق]

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

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

YAGNI


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

يقترح مؤلف البرمجة المتطرفة (XP) وكتاب "البرمجة المتطرفة المثبتة" رون جيفريز أنه يجب على المطورين فقط تنفيذ الوظائف المطلوبة الآن ، وعدم محاولة التنبؤ بالمستقبل ، وتنفيذ الوظائف التي قد تكون مطلوبة لاحقًا.

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

المفاهيم الخاطئة للحوسبة الموزعة


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

  1. الشبكة موثوقة.
  2. التأخير صفر.
  3. عرض النطاق الترددي لا نهاية لها.
  4. الشبكة آمنة.
  5. الطبولوجيا لا تتغير.
  6. يوجد مسؤول واحد فقط.
  7. تكلفة الشحن صفر.
  8. الشبكة متجانسة.

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

استلهمت مجموعة من المهندسين من العمليات الجارية في ذلك الوقت في Sun Microsystems.

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

All Articles