13. listopadu 2012

Prezentace: profesionální programátor = nedostatkové zboží

Dnes jsem měl na Západočeské univerzitě přednášku pro studenty o realitě vývoje, o tom, proč je dobré být programátorem a jaké by takový programátor měl mít vlastnosti.
Přechody mezi slidy jsou vyplněny citáty od Roberta Dreslera


7. listopadu 2012

Jak snížit chybovost na projektu?

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.
  1. 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.
  2. 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.
  3. 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í
  4. 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.
  5. 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.
  6. 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)
  7.  klasické lidské testování
Seznam možností není určitě úplný, uvedl jsem jen ty, které jsem někdy již použil nebo chci použít. Zajímalo by mě, jaký způsob preferujete vy?