Jak řešit přerůstání systému přes hlavu rubrika: Návrh
9
Vašek Ch.
Mozková kapacita i výkon jsou omezené a přestože si před spaním přeříkáváme mantry na lehkotonážní témata, máme krásný samodokumentující se kód atp., vyvíjený systém nám pod rukama houstne čím dál tím více a složitější procesy jako třeba reklamace vráceného zboží (kde hodně lidí může hodně tlačítky ovlivnit, co se s vráceným balíčkem stane) už bohužel jako programátoři neudržíme v hlavě.
Jakmile chce někdo hrábnout do kódu ovlivňující např. ony reklamace, nastávají chyby už při odhadu časové náročnosti, protože si nikdo pořádně zprvu neuvědomí, jaké všechny návaznosti a případy je třeba ve výsledku při implementaci vychytat.
Pokud lze z mého vágního popisu poznat, s čím zápasíme, asi se shodneme na tom, že by bylo dobré vyhradit na starosti s vnitropodnikovými procesy a jejich návaznosti/souvislosti s IS extra člověka, jehož údělem bude mít "o všem přehled". Tohle ovšem zatím není cesta, kterou bychom se chtěli vydat.
Zjednodušeně mám pocit, že nám začal vyvíjený systém časem malinko přerůstat přes hlavu :-). Určitě se tady najdou taky takoví -- jak jste situaci pak řešili?
Co bychom rádi zkusili, je začít některé procesy dokumentovat a ověřit si, jestli nám taková dokumentace v praxi k něčemu bude, nebo jestli se ukáže, že je to ztráta času a že nám naše modely jen zastarávají. Z nástrojů, které jsme používali, jsme vždycky tíhli k těm jednodušším -- Pivotal Tracker, Trello atp. Existuje i v této oblasti nějaký jednoduchý nástroj, ideálně webová aplikace, kterou bychom mohli použít pro nějaké základní procesní modelování?
2
capajj
Tohle je nejlepší vyřešit E2E testy. Ideální je psát testy společně s implementací nove featury.
My používáme CucumberJS spolu s testovacím runnerem Protractorem.
Nicméně vy to určitě píšete v PHP a v něm tedy žádné E2E testovací nástroje neznám. I když asi pro RAW selenium by asi existovat něco mohlo.
Komentáře
-
Vašek Ch.
:
Tzn. aby se pak dalo říct, že co jeden test, to jeden zdokumentovaný use case, na který musíme při modifikaci myslet?
—
24.10.2014
-
Anonym
:
@Vašek Chromický: Testy sú polovica dokumentácie.
—
24.10.2014
-
vaclav.sir
:
Pro PHP samozřejmě podobné nástroje také existují, např. Behat (něco jako Cucumber) a Mink (něco jako Protractor).
—
3.11.2014
-
Vašek Ch.
:
Behat for the win! Vysvětlení: 1) K testům: Testujeme. Nemáme sice 100% code coverage unit testama, ale cízí nám to není a jakákoliv složitější třída unit test má. (Jinak se to snad ani dělat nedá.) Taky máme velkou část aplikace otestovanou pomocí Selenií, což sice pomáhá odhalovat problémy, ale nedá se říct, že by plnily funkci "testy jsou půlka dokumentace" a ani že bychom psali akceptační testy před samotnou fičurou. Selenia píšeme spíš pro zajištění, aby nepřestala fičura fungovat v budoucnu.
2) Odpovědnosti: Máme jen jeden projekt, takže nějaké rotace "teď budu vědět nejvíc já a příště ty" nejsou možné. Co mi na tom vadí nejvíce, je, že takový člověk odsává velkou část zodpovědnosti a srandy od ostatních prográmátorů a navíc se ho pořád vlastně ptá na drobnosti a detaily, které by podle mě měly být zjistitelné i odjinud než jen z jednoho mozku v týdnu.
3) Dokumentace: Upřímně řečeno nevěřím na externě vedenou dokumentaci, kterou by každý z chutí aktualizoval a myslel na ni při každé změně v aplikaci.
Tudíž) Behat! Už ho nějaký ten pátek zkouším. Tak nějak přirozeně se stalo, že píšu nejprve testy (.feature), a teprve potom se pouštím do implementace. Jako dokumentace fungují jednotlivé features a scénáře úplně perfektně. Je to stokrát přehlednější než naše Selenia. Přijde mi, že testy jsou možná trošku málo expresivní (scenario outlines asi nebudou vždycky stačit), ale zatím jsem nenarazil na větší problém. Takže díky za tip a doporučuju vřele ostatním :-).
—
25.11.2014
Pro zobrazení všech 8 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře