ما أدوات تحليل التعليمات البرمجية التي تستخدمها لمشاريع Java الخاصة بك؟[مغلق]

StackOverflow https://stackoverflow.com/questions/4080

سؤال

ما أدوات تحليل التعليمات البرمجية التي تستخدمها في مشاريع Java الخاصة بك؟

أنا مهتم بجميع أنواعها

  • أدوات تحليل التعليمات البرمجية الثابتة (FindBugs وPMD وأي أدوات أخرى)
  • أدوات تغطية التعليمات البرمجية (Cobertura وEmma وأي أدوات أخرى)
  • أي أدوات أخرى تعتمد على الأجهزة
  • أي شيء آخر، إذا فاتني شيء ما

إذا كان ذلك ممكنًا، اذكر أيضًا أدوات البناء التي تستخدمها ومدى جودة تكامل هذه الأدوات مع كل من بيئة التطوير المتكاملة (IDE) وأدوات البناء الخاصة بك.

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

هل كانت مفيدة؟

المحلول

بالنسبة لأدوات التحليل الثابتة، غالبًا ما أستخدم CPD، بي إم دي, FindBugs, ، و Checkstyle.

CPD هي أداة PMD "كاشف النسخ/اللصق".كنت أستخدم PMD لفترة قصيرة قبل أن ألاحظ ذلك رابط "العثور على رمز مكرر". على ال صفحة ويب PMD.

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

أقوم بدمج هذه الأدوات مع بناء على أساس النمل.يمكنك اتباع الرابط لرؤية التكوين الذي تم التعليق عليه.

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

أولاً، بالنسبة لتقارير التحذير، أقوم بتحويل الإخراج بحيث يكون لكل تحذير التنسيق البسيط:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

يُطلق على هذا غالبًا اسم "تنسيق Emacs"، ولكن حتى إذا كنت لا تستخدم Emacs، فهو تنسيق معقول لتجانس التقارير.على سبيل المثال:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

يتم إجراء تحويلات تنسيق التحذير الخاصة بي بواسطة البرنامج النصي Ant الخاص بي مع Ant com.filterchains.

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

على سبيل المثال، يمنع التكوين الافتراضي لـ PMD إنشاء التحذيرات على أسطر التعليمات البرمجية التي تحتوي على السلسلة "NOPMD"في تعليق.كما يدعم PMD لغة Java @SuppressWarnings حاشية. ملاحظة.أقوم بتكوين PMD لاستخدام التعليقات التي تحتوي على "SuppressWarning(PMD." بدلاً من NOPMD بحيث تبدو عمليات قمع PMD متشابهة.أقوم بملء القاعدة المحددة التي يتم انتهاكها عند استخدام قمع نمط التعليق:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

فقط "SuppressWarnings(PMD."الجزء مهم للتعليق، لكنه يتوافق مع دعم PMD لـ @SuppressWarning تعليق توضيحي يتعرف على انتهاكات القواعد الفردية بالاسم:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

وبالمثل، يمنع Checkstyle إنشاء التحذير بين أزواج التعليقات (لا يتوفر دعم للتعليقات التوضيحية).بشكل افتراضي، تحتوي التعليقات الخاصة بإيقاف تشغيل Checkstyle وتشغيله على السلاسل CHECKSTYLE:OFF و CHECKSTYLE:ON, ، على التوالى.تغيير هذا التكوين (باستخدام "SuppressionCommentFilter" الخاص بـ Checkstyle) لاستخدام السلاسل "BEGIN SuppressWarnings(CheckStyle." و "END SuppressWarnings(CheckStyle."يجعل عناصر التحكم تبدو أشبه بـ PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

مع تعليقات Checkstyle، يتم انتهاك الشيك المحدد (HiddenField) يكون مهم لأن كل شيك له خاصته "BEGIN/END"زوج التعليق.

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

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

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

نصائح أخرى

أستخدم مزيجًا من Cobertura وCheckstyle و(Ecl)Emma وFindbugs.

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

تعد المكونات الإضافية Checkstyle وFindbugs Eclipse مفيدة أيضًا، حيث تقوم بإنشاء تحذيرات في المحرر أثناء الكتابة.

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

كل ما يلي نستخدمه وندمجه بسهولة في كل من إصدارات Maven 2.x وEclipse/RAD 7:

  • الاختبار - JUnit/TestNG
  • تحليل الكود - FindBugs، PMD
  • تغطية الكود - البرسيم

بالإضافة إلى ذلك، في تصميمات Maven لدينا:

  • JDepend
  • مدقق العلامات (TODO، FIXME، إلخ)

علاوة على ذلك، إذا كنت تستخدم Maven 2.x، فإن CodeHaus لديها مجموعة من مكونات Maven الإضافية المفيدة في نظامها. مشروع موجو.

ملحوظة:يتمتع Clover بتكامل خارج الصندوق مع خادم Bamboo CI (نظرًا لأن كلاهما منتجان من منتجات Atlassian).هناك أيضًا مكونات إضافية من Bamboo لـ FindBugs، وPMD، وCheckStyle، ولكن كما ذكرنا، فإن خادم Hudson CI المجاني يحتوي على تلك المكونات أيضًا.

أستخدم التحليل الثابت المدمج في IntelliJ IDEA.التكامل المثالي.

أستخدم تغطية الكود المضمنة في Intellij IDEA (استنادًا إلى EMMA).مرة أخرى، التكامل التام.

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

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

نحن نستخدم FindBugs وCheckstyle بالإضافة إلى Clover لتغطية التعليمات البرمجية.

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

نحن نستخدم FindBugs وJDepend المتكاملين مع Ant.نحن نستخدم JUnit لكننا لا نستخدم أي أداة تغطية.

أنا لا أستخدمه مدمجًا في Rational Application Developer (بيئة التطوير المتكاملة التي أستخدمها لتطوير تطبيقات J2EE) لأنني أحب مدى روعة المظهر عند تشغيل javac في وحدة تحكم Windows.:ص

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

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

في مشروعنا نستخدم السونار أمام checkstyle،pmd....جنبًا إلى جنب مع CI (Bamboo، Hudson) نحصل أيضًا على تاريخ جميل لجودة مصدرنا والتوجيه الذي نتبعه.أنا أحب Sonar، لأنك أداة مركزية واحدة في CI Stack تقوم بذلك نيابةً عنك، ويمكنك بسهولة تخصيص القواعد لكل مشروع.

الهيكل 101 جيد في تحليل التعليمات البرمجية وإيجاد تبعيات الحزمة الدورية.

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

إجابتي على سؤالي هي أننا نستخدم:

  • ابحث عن الأخطاء للبحث عن الأخطاء الشائعة السيئة/الترميز - يتم تشغيلها من maven، كما يتم دمجها بسهولة في Eclipse
  • Cobertura لتقارير التغطية الخاصة بنا - يتم تشغيلها من مخضرم

يحتوي Hudson أيضًا على مكون إضافي لفحص المهام والذي سيعرض عددًا من المهام TODO وFIXMEs، بالإضافة إلى إظهار مكان وجودها في الملفات المصدر.

تم دمجها جميعًا مع Maven 1.x في حالتنا ومرتبطة بـ Hudson، الذي يدير تصميماتنا عند تسجيل الوصول بالإضافة إلى الأشياء الإضافية ليلاً وأسبوعيًا.ترسم Hudson رسومًا بيانية لاختبارات JUnit، والتغطية، والعثور على الأخطاء، بالإضافة إلى المهام المفتوحة.يوجد أيضًا ملحق Hudson الإضافي الذي يقدم تقارير ورسوم بيانية لتحذيرات التجميع الخاصة بنا.لدينا أيضًا العديد من اختبارات الأداء مع الرسوم البيانية الخاصة بها للأداء واستخدام الذاكرة بمرور الوقت باستخدام البرنامج الإضافي Hudson Plots أيضًا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top