Ndepend i inne rewelacje automatycznego analizatora kodu?

Question

Od wczoraj analizuję jeden z naszych projektów z Ndepend (darmowy dla większości jego funkcji) i więcej go używam, a jeszcze bardziej wątpię w prawdziwą wartość tego typu oprogramowania (oprogramowanie do analizy kodu).

Pozwól mi wyjaśnić, system buduje raport o kondycji systemu i klasy według rangi każdej metryki. Pomyślałem, że to dobry punkt wyjścia do modyfikacji, ale większość z najlepszych wyników jest tutaj, ponieważ mają ponad 100 linii wewnątrz klasy (mamy duże nagłówki i używamy stylów komentarzy VS), więc to nie jest wielka sprawa. niż liczba Afferent Coupling Level (CA) jest zawsze zbyt wysoka i jest to prawie prawdziwe w przypadku interfejsu, którego użyliśmy dużo ... więc w tej chwili nie widzę czegoś złego, ale wydaje mi się, że NDepend go nie lubi (jeśli masz sugestię poprawy, powiedz mi, bo nie widzę potrzeby). To samething dla metryki nazwie „NOC” do Liczba dzieci, które większość mojego Interface są zbyt wysokie ...

Na razie tylko bardzo przydatna metryka jest Złożoność cykliczna ...

Moje pytanie brzmi:: Czy uważasz, że warto analizować kod za pomocą Automatic Code Analyzer, takiego jak NDepend? Jeśli tak, to jak filtrować wszystkie informacje, które wymieniłem, które tak naprawdę nie pokazują prawdziwego stanu systemu?

Answer 1

W rzeczywistości metryki to tylko jedna cecha NDepend, czy próbowałeś użyć VisualNDepend, który pozwala ci analizować projekt znacznie głębiej niż raport? Czytając twój komentarz jestem prawie pewien, że nie grałeś z NDepend UI (samodzielnym lub zintegrowanym w Visual Studio), który jest najlepszym sposobem filtrowania danych o twojej bazie kodu.

Jestem jednym z twórców NDepend i używamy go do analizy własnego kodu. Zasadniczo piszemy nasze własne zasady dotyczące jakości z Code Rules over LINQ Queries (CQLinq). Te zasady automatycznie gwarantują, że nie mamy regresji w naszym projekcie. Tutaj znajdziesz listę około 200 default code rules.

Oto kilka unikalnych cech NDepend i nie związane z metryk kodu:

• zasad Zapis CQLinq aby upewnić się, że nie mają wad architektonicznych, takich jak dependency cycles between our components, UI using directly the DB lub DB splątane z biznesem obiekty.

• Upewnij się, że nie mamy problemu z pokrycia kodu testami (jak dbamy z reguły CQLinq że jeśli klasa ma być 100% pokryte, it will remain 100% covered in the future)

• Wymuszanie skutki uboczne -free code (immutable class/pure methods)

• Skorzystaj z możliwości porównania 2 analiz do przeglądu zmian kodu od ostatniego wydania, przed wykonaniem nowej wersji. Bardziej szczegółowo, lubię używać NDepend do znajomości which method has been added and refactored since the last release, and is not 100% covered by tests.

• Posiadanie optymalnej enkapsulacji dla wszystkich naszych członków i typów (np. knowing which internal methods can be declared as private). Jest to również związane z dead-code detection, które obsługuje również usługa NDepend.

Aby uzyskać pełną listę funkcji, jeśli NDepend, zobacz here.

Answer 2

Niekoniecznie postrzegam wyniki NDepend jako "dobre" lub "złe" w inżynierii oprogramowania, zawsze istnieje dobry powód, dla którego aplikacja jest zaprojektowana tak, jak jest. Uważam, że jest to raport, który prawdopodobnie pomoże mi wskazać problemy z moim projektem, ale mam ostatnie słowo, jeśli chodzi o decyzję, czy dana metoda musi zostać refaktoryzowana, czy też jest dobra, tak jak ją zaprojektowałem. Ogólnie rzecz biorąc, nie daj się złapać, próbując odpowiedzieć, czy to jest tego warte, czy nie. Zdecydowanie jest, zamiast tego sugerowałbym, aby uważnie przejrzeć wyniki. Pomoże Ci to spojrzeć na swój projekt z innej perspektywy, a mogą zdarzyć się sytuacje, w których zdecydujesz, w jaki sposób zaprojektujesz najlepsze rozwiązanie, aby osiągnąć cele aplikacji.