كيفية إدارة الحالات الخاصة والتدنيين

Question

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

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

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

ما هي أفضل الممارسات المؤدية للتعامل مع المواقف مثل هذا؟

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

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

في حالات مثل هذا، هل يضيف الأشخاص ملفات البيانات إلى شجرة المصدر للرجوع إليها؟

Answer 1

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

//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
   //modify param to solve for edge case
   return param;
}

Commit Message: Solution for X and Y edge case, see description at KB#2312

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

تذكر أن المشكلات الغامضة تؤدي إلى حلول غامضة.

Answer 2

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

لذلك كملخص يمكنك إنشاء طريقة اسمه.

private bool ConditionXAndYHaveOccurred(object param)
{
   // code to check for conditions x and y
   return result;
}

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param)
{
   //modify param to solve for edge case
   return param;
}

ثم يمكنك كتابة رمز مثل

if(ConditionXAndYHaveOccurred(myObject))
{
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject);
}

ليس مثالا ملموسا بجد وسريع، لكنه سيساعد في قابلية القراءة في عام أو عامين.

Answer 3

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

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

Answer 4

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

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

Answer 5

حول ال

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

جزء:

إذا كان "الرسم" الذي تريد تضمينه هو رسم بياني، وإذا كنت تستخدم doxygen., ، يمكنك تضمينها نقطة الأوامر في تعليقك لتوليد رسم بياني في الوثائق:

/**
If we have a subgraph looking like this:
\dot
digraph g{
A->B;
A->C;
B->C;
}
\enddot
the usual method does not work well and we use this heuristic instead.
*/

Answer 6

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

Answer 7

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

Answer 8

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