Ellustultam.

Ezt abból vettem észre. hogy egyre ritkábban alkalmazom a TDD-t. Csak spike kódot írok, aztán utána írok teszteket, és addig lökdösöm a branch-emet, amíg zöld nem lesz a jenkins.

Ha jobban megnézzük, a spike is csak azért spike, mert nem bírom megjegyezni, hogy is kell használni a 15 különböző library-t. Meg a design miatt se aggódok, mert az archUnit szól, ha bármi nincs a helyén. A sonar meg szól, ha túl bonyolult cuccot írok.

Szóval másfél éve elvagyok ebben a langyos vízben, különösebben nem is bánom, hogy marad még ép agysejtem estére. Ebbe az idillbe csapott bele egy nehezebb feladat.

A nehezebb feladat az volt, hogy a UI-on lapozgatni kellett egy in-memory listát. Meg a szerkesztgetéseket vissza kellett vezetni az in-memory listába. Tényleg nem túl bonyolult, főleg, hogy a céges custom UI frameworkben volt egy saját lapozó, csak használni kellett. Mondjuk az arra volt kitalálva, hogy az adatbázisból jövő adatokban lapozhassunk offsetek alapján.

A lényeg az, hogy a spike-om nem működött elsőre. Meg másodikra se. Aztán kitaláltam a tutit, megírtam TDD-vel, minden zöld volt, és az se működött. Akkor konzultáltam a UI szakértővel, a csapatvezetővel, és végül találtam egy egyszerűbb megoldást. Az a spike már elsőre működött, utána írtam teszteket, zöld lett a jenkins, stb.

Még rosszul is éreztem magam, hogy egy ilyen pimf feladattal ennyit tököltem.

Aztán a vezető fejlesztő, aki általában csak merge-öli a cuccaimat, feltett egy csomó kérdést, hogy itt miért ezt a szokatlan megoldást választottam, és ott miért azt. Mindegyikre megvolt a válasz, hogy ezt a framework ilyen limitációja miatt, azt meg amiatt. Rögtön nem szorongtam annyira.

És hogy mi a tanulság? Nekem az, hogy a TDD nagyon jó, de ugyanazt az eredményt el lehet érni más eszközökkel is. Meg hogy a TDD-t, mint bármelyik másik módszert, csak akkor kell használni, ha segít a munkában: ha időt takarítunk meg vele, ha jobb kódot írunk és ha jobb architektúrára vezet.