Wystarczy chociażby wspomnieć Visual Studio 2008 Team System, który pozwala na obliczanie kilku wskaźników, między innymi złożoności cyklomatycznej. Borland także nie pozostaje w tyle za Microsoftem i pod koniec lutego tego roku światło dzienne ujrzał TeamInspector. Narzędzie to pozwoli kierownikom określać za pomocą metryk, czy produkt można dostarczyć klientowi. Nie ogranicza się ono tylko i wyłącznie do statycznej analizy, ale pozwala weryfikować stopień pokrycia testami czy trendy w rozwijanym kodzie. Rozwiązanie to jest częścią platformy Borland Management Solutions. Pozwala ono także na stosowanie ciągłej integracji. "TeamInspector odkrywa jakość kodu wytwarzanego przez organizacje za pomocą metryk, które mówią prawdę" - zachwala projekt David Wilby, wiceprezes strategii produktów w Borlandzie. Ceny tego systemu rozpoczynają się od 20 tysięcy dolarów.

Organizacje, które nie widzą korzyści biznesowych związanych z zastosowaniem tak skomplikowanego i kosztownego rozwiązania, mogą skorzystać ze znacznie tańszych lub nawet darmowych zewnętrznych narzędzi, a także samodzielnej rozbudowy środowisk przy pomocy pluginów. Najlepszym przykładem może być środowisko Eclipse cenione przez programistów właśnie za szeroką gamę rozszerzeń. Poza tym, większość inżynierów pracujących z platformą .NET zna FxCop - narzędzie pozwalające dokładnie analizować projekt pod kątem najlepszych praktyk, standardów nazewnictwa czy własnych reguł zdefiniowanych przez dany zespół. Inny przykład narzędzia pozwalającego wyznaczać metryki kodu, tym razem dla Javy, to JDepend udostępniony na zasadzie licencji BSD.

Problemy i korzyści

Metryki kodu mają swoich zagorzałych wielbicieli oraz zadeklarowanych przeciwników. Jest to jednak po prostu narzędzie, które poprawnie wykorzystane, może pomóc i usprawnić proces wytwarzania oprogramowania a źle użyte - uczynić go uciążliwym i niepotrzebnie zużywać zasoby, nie przynosząc wymiernych korzyści.

Warto mieć na uwadze, że języki programowania rozwijają się szybciej niż same metryki. Wzrasta liczba elementów deklaratywnych we współczesnych językach programowania, za czym część metryk może nie nadążać. Oprócz tego, zbyt duża ufność we wskaźniki i zbyt mocne oparcie na nich procesu programowania najprawdopodobniej doprowadzi do tworzenia kodu pod kątem metryk, a nie do poszukiwania najlepszych projektowo rozwiązań.

Wskaźniki nie zawsze też uwzględniają specyfikę danego produktu. Wobec tego rozwiązania, które mają gorsze metryki, mogą okazać się lepsze z punktu widzenia wymagań. W tej sytuacji do biznesowego stosowania metryk należy podchodzić z odpowiednią rezerwą, ale jako narzędzie inżynieryjne, pozwalające lokalizować problemy, wspierające produkcję i ułatwiające szacowanie, mogą one sprawdzać się bardzo dobrze.