لا تنتج أبدًا مسارًا غير معروف، في البرامج أيضًا؟[مبدأ تويوتا] [مغلق]

Question

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

يجب أن تخبرني جميع رسائل الخطأ بالمسار الذي سلكته بالضبط.البعض يفعل، رسائل الخطأ مع تتبع المكدس.هل هذا تفسير صحيح؟هل يمكن استخدامه في مكان آخر؟

حسنًا، هذا هو البودكاست.أعتقد أنه مثير للاهتمام

http://itc.conversationsnetwork.org/shows/detail3798.html

Answer 1

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

بعض الأمثلة:

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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