Java >> Java tutoriál >  >> Java

Nikdo neočekává inkvizici SpotBugs

Nedávno jsme upgradovali na nejnovější verzi SpotBugs, která je nástupcem FindBugs. Jeho úlohou je identifikovat rizikové oblasti kódu a označit je.

Používáme také Sonar, který nedávno zastavil sestavení kvůli chybě, která unikla testům jednotek, ale ve výrobě by ublížila. Podobně jsem nechal běhové oblasti úspěšně předpovídat SpotBugs, takže je opravdu užitečné mít nad kódem nástroje, jako je tento, který zajišťuje, aby neprocházely neviditelné chyby.

Ale co když tento nástroj produkuje spoustu falešně pozitivních výsledků nebo domnělých výsledků?

Do kódu můžeme přidat potlačení, ale pak:

Když je váš kód plný příkazů potlačení nástrojů, začne ztrácet význam jako kód a spojí se s nástroji, které by měly zůstat mimo něj.

I když je možné vytvořit externí potlačovací prohlášení, alespoň někdy, o to tady tak úplně nejde. V ideálním případě vytvoříme několik obecných pravidel a raději bychom, než aby se nástroj nedělal tak strašně hlučně.

Vina SpotBugs podle asociace

Nedávné změny SpotBugs se zdají být chytré, ale něco stojí. Zdá se, že SpotBugs se dozvěděli o tranzitivních měnitelných objektech. Jinými slovy, určuje, zda je objekt, který ukládáte v jedné třídě, účinně neměnný nebo ne. Pokud se domnívá, že není neměnný, zobrazí varování, pokud tento objekt přímo uložíte nebo vrátíte od jiného.

To je chytré.

I když to začíná být trochu jako hon na čarodějnice.

Horší než to, když máte jarní projekt, často máte řadu fazolí vzájemně propojených, z nichž některé mohou být buď proměnlivé, nebo se tak mohou zdát, protože pocházejí z knihovny, která je neoznačila jako @Immutable .

Například ve svém projektu mám specializovanou mutable cache, kterou používá několik mých fazolí. Je to mezipaměť místních kopií souborů a důležité bity jsou neměnné. SpotBugs ví pouze to, že cokoli, co používá tento bean, vystavuje jeho vnitřní implementaci vnějším změnám.

Přikláním se k tomu, že:

  • SpotBugs má pravdu
  • Je to však nepohodlné
  • Anotace pomocí @SuppressFBWarnings není dobré řešení
  • Můj současný přístup k souboru filtru, který ignoruje všechny objekty modelu POJO A všechny .*Service a .*Controller Objects také není skvělé řešení, ale je omezeno na EI a EI2 pouze varování, což je pravděpodobně v pořádku
  • Celkově má ​​SpotBugs dokumentaci, která zanechává mnoho přání

Skutečná cena nástrojů

Nepoužívání nástrojů, jako je tento, vás bude stát runtime chyby, kterým bylo možné předejít.

Použití těchto slabě zdokumentovaných, nepředvídatelných nástrojů, i když jsou nesmírně výkonné, vás občas ztratí:

  • Čas na práci s nejnovějšími libovolnými prohlášeními
  • Šum ve vašem kódu pomocí příkazů potlačení
  • Ztracený čas hledáním způsobu, jak vyjádřit dobré pravidlo, aby se zabránilo velkému šumu kódu

Doufejme, že se věci zlepší.

Java Tag