V dnešním článku se chci zamyslet nad tím, jak co nejlépe (= s minimem nákladů mít maximální užitek) snižovat chybovost během vývoje aplikace. Chyby dělá každý a kdo říká, že ne, tak nemluví pravdu.
Produkce chyb na softwarovém projektu je funkcí práce a velikosti projektu, takže je možné tuto produkci odhadnout. Jonesova data (Capers Jones) říkají, že typický projekt produkuje celkově asi 5 chyb (myšleno v celém vývojovém cyklu) na funkční celek, což znamená asi 50 chyb na 1000 řádků kódu. Čím větší projekt je, tím se výrazně zvyšuje i hustota chyb. (vybráno z knížky Odhadování softwarových projektů, Steve McConnell)Existuje množství způsobů resp. postupů, jak ve všech fázích vývoje hledat a odstraňovat chyby. Následuje seznam těchto možností, který je seřazený sestupně podle efektivity, kterou definuji takto: nejefektivnější způsob detekce chyb je takový, který mi dokáže nalézt co nejvíce chyb s nejmenšími náklady - rychlým, jednoduchým způsobem, co nejdříve během vývoje.
- UML modelování - nejsem velkým zastáncem velkého modelování, ale na druhou stranu si nedovedu představit, že bych začal hned programovat aniž bych si cokoliv namodeloval. UML je standard, který usnadňuje komunikace uvnitř týmu i směrem k zákazníkovi. Obecně jakákoliv vizualizace usnadňuje komunikaci a vzájemné porozumění. Když modeluji, tak mi to umožňuje se na aplikaci dívat z různých pohledů a nutí mě to přemýšlet a tím eliminovat věci, na které zapomenu.
- prototypování - myslím zejména prototypování uživatelského rozhraní pomocí vhodných nástrojů, ale může být i třeba prototypování na úrovni serveru, modulu apod. ve smyslu proof-of-concept.
- revize návrhu - před samotným vývojem provést formální/neformální revizi návrhu celého řešení a výběru technologií
- jednotkové testování - nezbytná součást vývoje aplikace. Je nutné vhodně definovat úroveň testování, tak aby to bylo opravdu efektivní - vývoj produktu vs. vývoj jednorázové aplikace. V prvním případě bych se snažil o 70-80% pokrytí, u druhého případu by mi nevadily ani poloviční hodnoty.
- inspekce kódu během vývoje samotného vývoje - zde nepočítám jen týmové inspekce, ale často není od věci si projít a zkontrolovat svůj kód sám.
- integrační testování - "ověřování, že nově přidané funkcionality spolu nekolidují a pracují stejně jako během feature testů i po zaintegrování z jednotlivých vývojových větví do hlavního projektu" (viz wiki)
- klasické lidské testování
Příspěvky
3 komentáře:
Já bych s uvedeným seznamem souhlasil - přesně podle něj se řídíme i my. Vidím jen trochu odklon od toho UML - mám zkušenost, že pokud na straně zákazníka není technik, nesetkávají se diagramy s žádným porozuměním. Pak děláme jen diagramy, které pomáhají nám = deployment diagram, component diagram, ERD. UC diagram je často jen popis bulletek ve wordu .
Co mi tam chybí, je kontinuální integrace, jež defakto slučuje body 4 a 5 a dává jim novou kvalitu.
Upozornil bych na rozdíl prototyp a proof of concept (PoC). Byť se tyto termíny běžně zaměňují, je mezi nimi podstatný rozdíl - PoC nemusí skončit úspěchem (tj. nepodařilo se daný koncept prokázat). PoC tedy neslouží (primárně) k detekci chyb, ale k ověření, že "to vůbec půjde udělat".
Může se stát, že se pak PoC překlopí do prototypu a na něm už se budou odlaďovat chyby.
S kontinuální integrací souhlasím, nějak mi to při tom přemýšlení nenapadlo.
S tím prototypováním jsem to nenapsal úplně nejlépe. Chtěl jsem říci, že řadu stěžejních technologických rozhodnutí je vhodné udělat co nejdříve než někdy během samotného vývoje zjistit, že je problém, a že něco nejde.
Okomentovat