تشخيص إرث .NET

Question

افترض أنك تتولى تطبيق .NET Legacy. مكتوب في C#

ما هي أفضل 5 تدابير تشخيصية ، التنميط أو غير ذلك الذي ستستخدمه لتقييم صحة التطبيق؟

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

_{(مصدر: GMU.edu)}

ونعم ، لا بد أن يكون هناك بعض رائع الأدوات التي تستخدمها لهذا الغرض ... سيكون رائعًا إذا أدرجتها أيضًا.

Answer 1

1. تصور المستخدم

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

أريد أن أطرح أسئلة مثل:

• هل تعمل بسلاسة؟
• هل هي سهلة الاستخدام؟
• عندما تستخدمه ، هل تشعر واثق أنها تفعل ما تتوقعه؟
• هل هي سيارة بي إم دبليو ، أو مدنية ، أم pinto؟

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

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

2. الوثائق

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

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

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

3. الاختبارات

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

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

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

4. تحليل ثابت

ربما اعتقد البعض منكم على الفور "FXCOP". ليس بعد. أول شيء سأفعله هو الخروج NDERPEND.

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

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

بعد، بعدما أنا راضٍ عن أن التصميم/الهندسة المعمارية الإجمالية ليست كاملة ، ومن بعد سوف أنظر إلى FXCOP. أنا لا آخذ إخراجها كإنجيل ، لكنني مهتم على وجه التحديد تحذيرات التصميم و تحذيرات الاستخدام (التحذيرات الأمنية هي أيضًا علامة حمراء ولكنها نادرة جدًا).

5. تحليل وقت التشغيل

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

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

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

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

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

---

وهذا كل ما يمكنني التفكير فيه الآن. سأقوم بالتحديث إذا لم يعد هناك أي شيء يتبادر إلى الذهن.

Answer 2

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

1. هل المستخدم النهائي سعيد به؟
2. هل هو مستقر؟
3. هل هو قوي؟
4. هل هي سريعة؟
5. هل بصمة الذاكرة مستقرة على مدار فترات طويلة وماذا أتوقع؟

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

Answer 3

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

شيء لطيف آخر يجب القيام به هو تشغيل المهام القياسية النمل البارد من Redgate أو dottrace من Jetbrains. سوف يخبرك ما الذي يستغرق الوقت وعدد المرات التي تم تشغيلها ، مما يعني أنه يمكنك رؤية أين يمكن تحسينه/تخزينه مؤقتًا.

إذا كنت تستخدم nhibernate ثم NHPROF رائع (أو أعتقد أن Ayende أصدرت الآن Uberprof الذي يغطي المزيد من استراتيجيات الوصول إلى DB.) هذا سيحذرك من أي وصول غبي DB. فشل هذا فقط باستخدام SQL Server Profiler قد يوضح لك طلب نفس البيانات مرارًا وتكرارًا ، ولكنه سيتطلب المزيد من الجهد في تصفية القمامة. إذا انتهى بك الأمر باستخدام ذلك ، فيمكنك حفظه على جدول DB والذي يمكنك بعد ذلك الاستعلام بطريقة أكثر ذكاءً.

إذا كنت تبحث عن متانة ، فإن الشيء الجيد الذي يجب استخدامه هو استراتيجية تسجيل - التقاط جميع الاستثناءات وتسجيلها. هذا سهل بما يكفي لإعداد استخدامه log4net. قم أيضًا بتسجيل الدخول إذا وصلت إلى بعض النقاط التي تشك فيها قليلاً. ثم اطلب من هذا الخادم (أستخدمه Kiwi Syslog Server وهو أمر سهل الإعداد وقوي للغاية) والذي يمكنه الكتابة إلى DB ويمكنك تشغيل التحليل على النتائج. أود أن أوصي ضد ado.net appender لـ log4net لأنه ليس غير متزامن وبالتالي سوف يبطئ تطبيقك.

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

أتمنى أن يساعدك هذا.

Answer 4

أول عنصران كبيران سأبحث عنهما سيكون:

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

Answer 5

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

أنت حقًا لا تحتاج إلى أدوات لهذا ، فقط العمل الشديد لمراجعة العدادات والتحدث مع DBA.