[3] ani stabilni verze STL nepomuze, pokud clovek pravidelne updatuje kompilator samotny.
Podle mne osobne nejlevnejsi cesta k bezpecnemu programovani je Test Driven Development. Unit testy zabezpeci ze jednotlive funkce na nizke urovni (mysleno hlavne abstrakce) funguji presne dle specifikace testu, metodika TDD zase nuti k relativne dobre modularnosti a efektivite (v kontextu abstrakce) API, takze vetsina veci v aplikaci se pak deje prave na te nizke urovni ktera je kryta unit testy.
Porad je tam trochu mista pro velmi komplexni chyby ktere se projevi az po poskladani aplikace do celku a nejdou jednoduse odchytit unit testem, ale jednak jsou tyto pripady mene caste a jednak muze clovek natolik verit jednotlivym funkcim, nakolik ma kvalitni unit testy, co ho bud prinuti pridat dalsi unit testy aby vice veril podezrelym funkcim, nebo se muze soustredit na hledani chyby na vyssi urovni v celkovem propojeni aplikace a nemyslet na jednotlive male funkce.
Taky je tento pristup vhodny pro agilni vyvoj.
Jako malou nevyhodu ze sve zkusenosti zatim vnimam souboj TDD s QA, t.j. v ramci TDD jsou potreba unit testy k veci, ale pokud mozno neredundantni, aby v ramci agilniho vyvoje kdyz se radikalne refaktoruje API funkci, tak byla potreba zmenit jenom minimalni mnozina testu, naopak kvalitni QA vyzaduje od testu nejenom 100% code coverage, ale i redundantni testy ktere dukladne otestuji funkce jestli opravdu pocitaji to co maji. Ale neni to tak spatne, kdyz treba funkce ma byt dostatecne robustni, tak treba testovani extremnich vstupu je soucasti jiz zakladni unit testu, takze tech kvuli QA navic uz neni tak moc a pri refaktoringu uprava testu na nove API nakonec vetsinou zabere jen malou cast prace.
ČLÁNKY DO MAILU