Vůně kódu - Code smell

v programování, a kód vůně je jakákoli vlastnost v zdrojový kód a program to možná naznačuje hlubší problém.[1][2] Určení, co je a není vůně kódu, je subjektivní a liší se podle jazyka, vývojáře a metodologie vývoje.

Termín popularizoval Kent Beck na WardsWiki na konci 90. let.[3] Používání tohoto výrazu vzrostlo poté, co byl uveden v knize z roku 1999 Refaktoring: Vylepšení designu stávajícího kódu podle Martin Fowler.[4] To je také termín používaný agilní programátoři.[5]

Definice

Jedním ze způsobů, jak nahlížet na pachy, je dodržovat zásady a kvalitu: „Vůně jsou určité struktury kódu, které naznačují porušení základních principů designu a negativně ovlivňují kvalitu designu.“[6] Vůně kódu obvykle nejsou hmyz; nejsou technicky nesprávné a nebrání fungování programu. Místo toho naznačují slabiny v designu, které mohou zpomalit vývoj nebo zvýšit riziko chyb nebo selhání v budoucnu. Špatné pachy kódu mohou být indikátorem faktorů, které přispívají k technický dluh.[1] Robert C. Martin nazývá seznam pachů kódu „hodnotovým systémem“ pro softwarové zpracování.[7]

Hlubší problém naznačený vůní kódu lze často odhalit, když je kód vystaven zkratu cyklus zpětné vazby, kde to je refaktorováno v malých, kontrolovaných krocích a výsledný design se zkoumá, aby se zjistilo, zda existují nějaké další pachy kódu, které zase naznačují potřebu dalšího refaktoringu. Z pohledu programátora pověřeného prováděním refaktoringu jsou vůně kódu heuristika označit, kdy se má refaktorovat a jaké konkrétní refaktorační techniky použít. Vůně kódu je tedy hnacím motorem pro refaktorování.

Studie z roku 2015[1] s využitím automatizované analýzy pro půl milionu zdrojového kódu zavazuje a ruční zkoumání 9 164 závazků určených k projevení „pachů kódu“ zjistilo, že:

  • Existují empirické důkazy o důsledcích „technického dluhu“, existují však pouze neoficiální důkazy jak, kdyžnebo proč toto nastane.
  • „Obecná moudrost naznačuje, že příčinou těchto pachů jsou často naléhavé činnosti údržby a tlak na poskytování funkcí a upřednostnění doby uvedení na trh před kvalitou kódu.“

Nástroje jako Checkstyle, PMD, FindBugs, a SonarQube dokáže automaticky identifikovat pachy kódu.

Společný kód voní

Vůně na úrovni aplikace:[původní výzkum? ]

  • Duplikovaný kód: identický nebo velmi podobný kód existuje na více než jednom místě.
  • Vymyšlená složitost: vynucené použití překomplikovaných designové vzory kde by stačil jednodušší design.
  • Brokovnice: jednu změnu je třeba aplikovat na více tříd najednou.
  • Nekontrolované vedlejší účinky: velmi snadné způsobit výjimky za běhu a jednotkové testy to nemohou zachytit.
  • Variabilní mutace: velmi těžké refaktorovat kód, protože skutečná hodnota je nepředvídatelná a těžko se o ní uvažuje.
  • Booleova slepota: snadné uplatnění na opačné hodnotě a stále kontroly typu.

Vůně na úrovni třídy:[původní výzkum? ]

  • Velká třída: a třída který se příliš rozrostl. Vidět Bůh namítá.
  • Funkce závist: třída, která nadměrně používá metody jiné třídy.
  • Nevhodná intimita: třída, která má závislosti na podrobnostech implementace jiné třídy. Vidět Objektová orgie.
  • Odmítnuté dědictví: třída, která přepíše metoda základní třídy takovým způsobem, že smlouva z základní třída není ctěn odvozená třída. Vidět Princip substituce Liskov.
  • Líná třída / freeloader: třída, která dělá příliš málo.
  • Nadměrné používání literálů: měly by být kódovány jako pojmenované konstanty, aby se zlepšila čitelnost a zabránilo se programovým chybám. Dodatečně, literály může a měl by být externalizován do zdrojových souborů / skriptů nebo jiných datových úložišť, jako jsou databáze, kde je to možné, aby se usnadnila lokalizace softwaru, pokud má být nasazen v různých oblastech.[8]
  • Cyklomatická složitost: příliš mnoho větví nebo smyček; to může znamenat, že je třeba funkci rozdělit na menší funkce, nebo že má potenciál pro zjednodušení.
  • Downcasting: obsazení typu, které rozbíjí model abstrakce; abstrakce bude možná muset být refaktorována nebo odstraněna.[9]
  • Osamocená proměnná nebo konstantní třída: a třída který má obvykle kolekci konstant, které patří jinde, kde by tyto konstanty měly vlastnit jedna z ostatních členských tříd.
  • Shluk dat: Nastane, když je skupina proměnných předána společně v různých částech programu. Obecně to naznačuje, že by bylo vhodnější formálně seskupit různé proměnné dohromady do jednoho objektu a místo toho předat pouze tento objekt.[10][11]

Vůně na úrovni metody:[původní výzkum? ]

  • Příliš mnoho parametrů: dlouhý seznam parametrů je těžko čitelný a komplikuje volání a testování funkce. Může to znamenat, že účel funkce je nedomyslený a že kód by měl být refaktorován, aby byla odpovědnost přiřazena čistším způsobem.
  • Dlouhá metoda: a metoda, funkce nebo procedura, která se příliš zvětšila.
  • Příliš dlouhé identifikátory: zejména používání konvence pojmenování poskytnout disambiguation, která by měla být implicitní v softwarová architektura.
  • Příliš krátké identifikátory: název proměnné by měl odrážet její funkci, pokud funkce není zřejmá.
  • Nadměrný návrat dat: funkce nebo metoda, která vrací více, než co každý z jejích volajících potřebuje.
  • Nadměrné komentáře: třída, funkce nebo metoda má irelevantní nebo triviální komentáře. Dobrým příkladem je komentář k atributu getter.
  • Příliš dlouhá řada kódu (Nebo God Line): Řádek kódu, který je příliš dlouhý, což znesnadňuje čtení, porozumění, ladění, refaktorování nebo dokonce identifikaci možností opětovného použití softwaru. Příklad:
new XYZ (s) .doSomething (buildParam1 (x), buildParam2 (x), buildParam3 (x), a + Math.sin (x) * Math.tan (x * y + z)). doAnythingElse (). build ( ).poslat žádost();

Viz také

Reference

  1. ^ A b C Tufano, Michele; Palomba, Fabio; Bavota, Gabriele; Oliveto, Rocco; Di Penta, Massimiliano; De Lucia, Andrea; Poshyvanyk, Denys (2015). „Kdy a proč začíná váš kód páchnout“ (PDF). 2015 IEEE / ACM 37. mezinárodní konference IEEE o softwarovém inženýrství. 403–414. CiteSeerX  10.1.1.709.6783. doi:10.1109 / ICSE.2015.59. ISBN  978-1-4799-1934-5. S2CID  59100195.
  2. ^ Fowler, Martin. "CodeSmell". martinfowler.com/. Citováno 19. listopadu 2014.
  3. ^ Beck, Kent. "Vůně kódu". WikiWikiWeb. Ward Cunningham. Citováno 8. dubna 2020.
  4. ^ Fowler, Martin (1999). Refaktorování. Vylepšení designu stávajícího kódu. Addison-Wesley. ISBN  978-0-201-48567-7.
  5. ^ Binstock, Andrew (2011-06-27). „Chvála malého kódu“. Informační týden. Citováno 2011-06-27.
  6. ^ Suryanarayana, Girish (listopad 2014). Refaktoring pro softwarový design voní. Morgan Kaufmann. str. 258. ISBN  978-0128013977.
  7. ^ Martin, Robert C. (2009). „17: Vůně a heuristika“. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN  978-0-13-235088-4.
  8. ^ "Konstanty a magická čísla". Citováno 2020-11-03.
  9. ^ Miller, Jeremy. „Downcasting je vůně kódu“. Archivovány od originál dne 16. února 2019. Citováno 4. prosince 2014.
  10. ^ Fowler, Martin. "DataClump". Citováno 2017-02-03.
  11. ^ „Návrhové vzory a refaktoring“. sourcemaking.com. Citováno 2017-02-04.

Další čtení

externí odkazy