ما مدى نضج إطار عمل Microsoft Code Contracts؟

Question

قامت Microsoft مؤخرًا بوضع إصدار خاص بها عقود الكود إطار عمل على DevLabs برخصة تجارية.نحن مهتمون باستخدامها في مشروعنا (غالبًا C#، وبعضها C++/CLI) لاستبدال جميع رموز التحقق المخصصة تدريجيًا، ولكنني حريص على معرفة تجربة الأشخاص الآخرين معها قبل أن نلتزم بها، خاصة:

• هل تعتقد أن الإطار ناضج بما فيه الكفاية للمشاريع التجارية الكبيرة والمعقدة؟

• ما هي المشاكل التي واجهتك أثناء استخدامه؟

• ما هي الفوائد التي حصلت عليها من ذلك؟

• هل الألم حاليا أكثر مما يستحق؟

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

هل يجب أن نبدأ في استخدامه الشهر المقبل؟

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

Answer 1

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

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

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

لذا فإن شعوري هو أنه في الوقت الحالي، لأننا في الإصدار 3.5 نحاول البناء على إطار عمل لا يفهمه المدقق بشكل كافٍ، فمن المحتمل أن الأمر يستحق الانتظار حتى الإصدار 4.0.

Answer 2

آخر استجابة ناضجة لهذا كان في عام 2009، وتم إصدار .NET 4.أعتقد أننا مستحقون للتحديث:

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

أدرك أن هذا يعد إلى حد ما ترقية من "غير ضار" إلى "غير ضار في الغالب".

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

نحن نستخدم وضع "عدم إعادة كتابة الإصدار IL الخاص بي".

حتى الآن، أنا أستمتع كثيرًا بهذه الميزة غير المتوقعة:هناك رمز أقل، وبالتالي رمز أقل للاختبار.كل شروط الحماية الخاصة بك تذوب.

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

يصبح:

Contract.Requires(arg != null);

وظائفك أقصر. نيتك أكثر وضوحا. ولم يعد يتعين عليك كتابة اختبار باسم ArgumentShouldNotBeNull فقط للوصول إلى تغطية 100%.

حتى الآن واجهت مشكلتين:

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

• نحن نستخدم أداتين لإعادة كتابة IL: عقود الكود و بوستشارب.لم ينسجموا جيدًا.قام PostSharp's 2.0.8.1283 بإصلاح المشكلة.سأقيم بحذر كيف أي ومع ذلك، هناك أداتان لإعادة كتابة IL.

حتى الآن، الفوائد تفوق المخاطر.

معالجة المخاوف القديمة التي أثيرت في الإجابات الأخرى:

• تعد وثائق Code Contracts شاملة تمامًا، على الرغم من أنها للأسف بتنسيق PDF.
• هناك واحد على الأقل منتدى عقد الكود تستضيفها مايكروسوفت.
• الإصدار القياسي من Code Contracts مجاني إذا كان لديك أي ترخيص VS2010.
• .NET 4 خارج.لقد واجهت عقود Microsoft عند تنفيذ واجهات التجميع العامة.

Answer 3

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

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

Answer 4

انها ليست ناضجة بما فيه الكفاية.

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

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

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

فشل ملحمي.