blog.testowka.pl

Problemem są ludzie a nie software

opublikowany przez 28, Paź, 2013, w kategoriach Inne

195244498_01fbb73234_zJak często zdarzało wam się słyszeć, albo co gorsza mówić na przykład że:

W naszym projekcie nie da się automatyzować testów, nie robimy tego ze względu na zbyt dużą ilość legacy code.

albo:

TDD może i działa w projektach zaczynanych od zera, w naszym kodzie pisanie testów jednostkowych jest NIEMOŻLIWE

a może:

Tak, tak próbowaliśmy Continuous Integration, ale napotkaliśmy zbyt wiele problemów. Buildy były prawie cały czas zepsute, a jak ktoś dorzucił jeszcze swoje zmiany do zepsutego builda to naprawianie tego zajmowało wieki. Teraz wystarczy że nasz kod się kompiluje – testerzy odwalają kawał niezłej roboty.

To tylko kilka przykładów „wymówek” często używanych przez developerów po to by usprawiedliwić swoją niedbałość, niestaranność, brak profesjonalizmu czy nawet niekompetencje.

Mamy 2013 rok (już prawie 2014) jeśli nie stosujesz Continuous Integration to wyjdź ze swojego schronu atomowego i zobacz co dzieje się na około. O CI głośno było już 1999 roku – w IT to naprawdę dużo czasu.

Nie automatyzujesz testów – naprawdę uważasz, że jesteś w stanie efektywnie programować. Testy automatyczne to nie testowanie – to dostarczanie feedbacku. Naprawdę jesteś tak bystry żeby w złożonym środowisku rozwijanych przez siebie systemów mieć pewność, że nie wprowadzasz bugów? A może wcale nie jesteś bystry tylko klepiesz banalne aplikacje?

Nie no oczywiście, że w Twoim projekcie nie da się pisać testów jednostkowych. Pytanie tylko kto ten projekt doprowadził do takiego stanu? A może jednak się da – tylko jest to bardzo trudne? Może warto sięgnąć po jedną czy drugą książkę o pracy z legacy code i coś wreszcie z tym zrobić? Nie, nie musisz pytać o pozwolenie swojego managera – kod to Twoja działka. To Ty bierzesz za to odpowiedzialność. To Ciebie będą koledzy pokazywać palcem jeśli zacommitujesz zmiany niskiej jakości. Nie będą? Dla własnego dobra zmień kolegów – przez takich jak oni stoisz w miejscu.

Continuous Integration, Continuous Delivery, Test-Driven Development, Automatyzacja testów i wiele innych to nie są narzędzia – to są praktyki. Problemem w ich stosowaniu nie jest software z którym mamy do czynienia. Problemem są ludzie, którym brakuje dyscypliny, wiedzy i motywacji do jej zdobywania.

Problemy z softwarem można łatwiej lub trudniej rozwiązać. Gdy natomiast problemem są ludzie to jest już trochę trudniej.


6 Comments for this entry

Skomentuj