Nem vagyok a fejlesztő csapat tagja, viszont tapasztalatból meg tudom mondani, hogy az ilyen fajta hibajelenségek miből kereked(het)nek.
Ugyebár amikor a fejlesztő egy modult leprogramoz, akkor ő legfeljebb modul szinten tudja azt letesztelni. (jUnit) . Akkor mondható hogy a programozó rendben letesztelte a kódját, ha a modul azt csinálja, amit a programozó elképzelt, és a hibalehetőségek is mind le vannak kezelve. Persze ez nem elég. A modult le kell tesztelni alkalmazás szinten is. Fel kell tölteni egy tesztrendszerbe, és ki kell próbálni csak azt a modult alkalmazás szinten. Ehhez össze kell állítani egy olyan teszteseteket, amelyek teljeskörűen letesztelik a modult. Vannak code coveration programok, amelyeket hozzá kell fordítani a tesztelendő modulhoz, ez pontosan megmondja, hogy pl. az egyes függvények melyik ága lett letesztelve, és melyik nem. Ez sosem lesz teljes körű, de sok hiba csak ekkor derül ki. Mivel a rendszer más rendszerekkel is kapcsolatban van, ezért a modult úgy is le kell tesztelni, hogy a tesztrendszert további elemekkel kell kiegészíteni. Ez megint problémás, de jópár hiba csak itt bukik ki. Aztán persze kell még egy teszt. Itt már a release kódot kell feltölteni egy éles előtti rendszerbe, amelyen le kell futtatni egy teljeskörű felhasználói szintű tesztet. Ennek az a célja, hogy ha a hibajavítás valamit elrontott a rendszerben, akkor azok kibukjanak. Ha ezt az utolsó lépést elhagyják, megtörténhet egy ilyen baj.
A másik dolog a verziókezelés. Mivel több lépcsős a tesztelés, ezért akár többször is szükséges új build-et csinálni. Ha ilyenkor simán a main branch legfrissebb változatát fordítják újra, akkor az ugyebár változhat, mert mások is fejlesztenek. A legegyszerűbb ilyenkor megmondani a fejlesztőknek, hogy kódzárás van, senki se tegyen be új verziót. Ilyenkor biztos lesz olyan, hogy valaki mégis beteszi, akkor az ilyen baj megtörténhet. A megoldás egyébként erre a felcímkézés. Ilyenkor a több lépéses teszt során végig nyilvánvaló, hogy melyik verzió van tesztelve, ha valaki hibázik, akkor az az utolsó tesztnél mindenképp kibukik.
Külföldről azért beszéltem, mert ott megfelelő hozzáállással és szakértelemmel állnak hozzá a fejlesztés menetének felépítéséhez, és nem egy emberre bízzák, hogy csinálja úgy, ahogy jónak látja. A problémákat szintén globális módon kezelik, és nem vetítik azt vissza a fejlesztőknek. Magyarországon sajnos az ad-hoc megoldások a jellemzőek. Vagyis a fejlesztő egy személyben majd megoldja úgy ahogy akarja.
Az önálló munkavégzés szintén baj szerintem. Külföldön én nem láttam olyan, hogy a programozó úgy dolgozik, hogy fenn van a fején a füllhallgató egész nap. Aki így dolgozik, az csak a saját kódrészét fogja látni. Külföldön sokkal nagyobb figyelmet fordítanak arra, hogy a közös interfészeket a fejlesztők közösen beszéljék meg, és lehetőleg a kódolás befejeztével nézzék át egymás kódrészeit. Magyarországon ilyet, hogy programozó más kódját olvassa, szintén nem hallottam.
A programozók életútja (gyakornok->junior->senior->vezetőprogramozó->projektvezető) Magyarországon túl nagy szerepet kap, ez szintén a mi kultúránkból adódik. Ez olyan dolgokat fog eredményezni, hogy a junior nem szólhat be a seniornak, az pedig szintén nem a vezetőprogramozónak, ha esetleg valamit nem lát jól a másik munkájában. Külföldön egy fejlesztési csapatban sokkal egyenrangúbbak az emberek. Amikor van egy projekt, akkor egyszer az egyik, máskor a másik lesz annak a projektnek a vezetője. Így mindenki egyformán fog tapasztalatot szerezni.
persze a képlet biztosan nem ilyen egyszerű. Kishazánkban egy cég úgy fejleszt, ahogy azt tőle megkövetelik.