Muzes mit automatizovane testy, ktere ti otestuji jestli mas testy a jestli ty testy testuji co maji testovat viz napr. mutation a coverage testing.
To co popisujes ty znaci, ze nemas dostatecnou duveru v pipelinu.
Pokud je to na produkci a funguje to tak je to v poradku a muze to tam byt.. .proc bych travil cas na code review kterym budu blokovat merge?
Review ale nemá primárně chytat nějaké testovatelné bugy, jak už tu zaznělo několikrát. Review potřebuješ dělat i u 100% covered codebase, protože jen neuronka (ať už biologická, nebo umělá) může posoudit, jestli jsou věci smysluplně pojmenované, rozdělené, jestli je to udržitelně napsané, jestli ty testy jsou napsané tak, aby reálně detekovaly chyby a přitom nezávislé změny nevyžadovaly hromadu oprav testů...
Jasně, mutation a fuzzy testing je v principu super, ale pokud i bez nich plný test suite běží hodiny a hodiny, tak plošná mutabilita to násobí, takže se to dá používat jen cíleně.
Pokud je to hnusno-kod kterej tam nechci i kdyz funguje tak ho proste oznacim jak technical friction ktery je potreba resit a udelam ta to ticket do pristiho sprintu... S nikym nemusim diskutovat jestli se to udela nebo ne... projektova kultura proste rika, ze tohle se bude resit... A navic muzu pridat automatizovanej test na to aby uz se to priste nestalo...
Pokud není čas na "udělat to pěkně už na prvním MR", tak stoprocentně nebude čas na přepsání později, kdy to začnou používat další věci. Tyhle tickety se přištích pár měsíců přesouvají ze sprintu do sprintu, pak se to přesune na plán na příští rok a pak se zavřou jako "not relevant after 5 years".
Casem se muze stat ze ta pipelina sama bezi moc dlouho tak se musi resit ktere veci se budou kontrolovat s kazdym MR a ktere veci pobezi prez noc...
Ano. To má být jako nějak špatně, nebo co?
#MoveFastAndBreakThings
Jo, při rozhlédnutí se je vidět, kolik lidí a firem za tuhle myšlenku schovává nekvalitní práci a věčně akumulující se technický dluh.
21 Odpovědí
1814 Zhlédnutí