Nie kradnij

To jedyne przykazanie w całym Devkalogu pozostawione w oryginalnej formie. Nie kradnij srajtaśmy z biura? Owszem, nie kradnij, ale ja nie o tym. Nie kradnij poprzez piracenie oprogramowania/muzyki/filmów? Owszem. Ale ja nie o tym.

Dawno temu, jeszcze w 2008 roku, Jeremy Miller napisał:

If you’re writing ADO.Net code by hand, you’re stealing from your employer or client

Mamy rok 2013. Ilu z was skrobie do wszystkiego procedury składowane, by potem ich wynik ręcznie sparsować z data readera, by potem ręcznie stworzyć z nich obiekt? By potem stracić X godzin na debuggowaniu, bo spodziewaliście się short a kolumna w bazie to tinyint? A jakby tego było mało, przerzuca następnie tak skonstruowaną strukturę przez przynajmniej cztery warstwy, mapując ją po kolei ręcznie na identyczne kropka w kropkę klasy, tyle że z nazwami kończącymi się na “Model”, “DTO” czy “Info”?

Widziałem takie systemy dawno temu. Widziałem i niedawno. Ciężko jest mi sobie wyobrazić większe marnotrawstwo – tak cennego przecież – czasu programisty.

A dostęp do danych to tylko jeden z przykładów.

Ręczne zarządzanie zależnościami w systemie i czasem życia obiektów – konsumujące pewnie miliardy godzin spędzonych w debuggerze? To samo.

Ręczne przepisywanie wartości właściwości z jednego obiektu do drugiego tylko po to, żeby mieć osobny “ViewModel” różniący się od klasy źródłowej tylko tym że jego nazwa kończy się na “ViewModel” właśnie? To samo.

Czekanie 2h na skompilowanie i uruchomienie systemu na maszynie developerskiej po każdym zaimplementowanym ficzerze, aby go “przeklikać”? To samo.

Walka z TfuFSem spowalniającym lub niszczącym naszą pracę? To samo.

Ślęczenie tydzień w spaghetti-code aby dowiedzieć się “dlaczego nie działa komponent X skoro ja tylko zmieniłem jedną linijkę w teoretycznie zupełnie niezależnym komponencie Y?”? To samo.

Można podobne scenariusze mnożyć i mnożyć, jest ich pewnie milion. Jeśli tępo klepiesz w klawiaturę i wykonujesz zadania, które spokojnie dałoby się powierzyć kolesiowi z gimnazjum, “mistrzowi starcrafta”, i nie starasz się zmienić tego stanu rzeczy… zastanów się przez chwilę. “Kradzież” to prawdopodobnie za dużo powiedziane, ale przyjmowanie takiej rzeczywistości bez mrugnięcia okiem jest nie do zaakceptowania.

Obowiązkiem “światłego”, “doświadczonego”, “obeznanego” programisty jest bezlitosne wyrywanie z korzeniami takich chwastów w celu optymalnego wykorzystywania czasu spędzonego nad danym projektem. Nie ma znaczenia, że “wszyscy w zespole tak robią i jest ok”. Daj znać, że można inaczej. A nuż się spodoba. Nie można oczywiście samowolnie nagle wywrócić wszystkiego do góry nogami, ale milczenie w tym przypadku nie jest złotem. Nie jest nawet sreberkiem zwijanym przez świstaka. Jest najgorszym rozwiązaniem.

Jedną z najcenniejszych cech naszej profesji jest możliwość nieustannego kwestionowania aktualnego stanu rzeczy. Baba w kasie nie powie nagle: “Hej, dziś spróbuję pikać kodami kreskowymi trzymając towar palcami u stóp zamiast u rąk, wydaje mi się że tak obsłużę więcej klientów!”. My możemy. A jeśli okaże się, że to jednak nie działa, bez większych szkód powrócimy do tego “jak było”. Wszystko da się usprawnić. Trzeba tylko chcieć to robić, umieć zidentyfikować najbardziej palące obszary i sensownie zaplanować proces polepszania, aby jutro było bardziej produktywne niż dziś.

Oczywiście najłatwiej jest olać takie problemy i po prostu płynąć z nurtem zer i jedynek, nie wnikając w to czy da się lepiej. Jednak gdy następnym razem pozostaniesz bierny i tępo weźmiesz się za małpie, bezmyślne stukanie w guziki, zastanów się: nie szkoda na to życia? Ja osobiście wielokrotnie musiałem takie czynności wykonywać. Czasami nadal muszę. Wszyscy musimy. Warto jednak poświęcić kilka chwil na refleksję “WTF??? czy ja po to tu jestem?”. I poszukać alternatywy. A następnie tą alternatywę przemyśleć, zaprezentować i uargumentować.

Gdybym tego nie robił, byłoby mi wstyd przyjąć od pracodawcy/klienta pełną pensję. To część moich (i twoich!) obowiązków – usprawniać. Usprawniać kod, usprawniać narzędzia, usprawniać proces. Gdy napotykam na zadanie, którego implementacja zajmuje mi 3 dni a powinna zająć 3 godziny, staram się krzyczeć. “Jest źle! Marnuję swój czas i wasze pieniądze!”. Nie zawsze można zmienić takie scenariusze od ręki, nie należy oczekiwać, że nagle wszyscy rzucą swoją robotę i zabiorą się za naprawianie świata. Ale ważny jest sam fakt zapalenia czerwonej alarmowej lampki: można zrobić coś lepiej. Szybciej. I KIEDYŚ warto się nad tym pochylić.

Takie spostrzeżenia mogą być szczególnie wartościowe przy dołączaniu nowej osoby do rozwijanego przez lata projektu. Dotychczasowy zespół siłą rzeczy pewne mechanizmy i zastosowane rozwiązania po prostu przyjmuje za pewnik. Jest jak jest, robimy jak robimy, i gitara. Para świeżych gał jest w stanie prędzej zidentyfikować dziwne zakamarki i pomyśleć nad ich optymalizacją. Zdiagnozuj problem. Znajdź alternatywę. Przeanalizuj stosunek kosztów do korzyści płynących z jej wprowadzenia. Zaproponuj. Zaakceptuj odpowiedź – nawet jeśli w uzasadniony sposób będzie ona odmowna. Nie krytykuj.

Wielu z nas siedzi jednak właśnie w takim dużym, zastałym projekcie i dłubie wszystko według wypracowanych lata temu formułek. Challenge: znajdź dzisiaj w swojej codziennej pracy czynność, która najbardziej podpada pod tą, nieco na wyrost tak nazwaną, kradzież. Na pewno jest coś takiego. A następnie postępuj według kroków z poprzedniego akapitu.

Nie jestem Robin Hoodem. Tego, co ukradnę, nie ukradnę złym bogatym. I nie oddam biednym. Bo niestety za każdym razem, gdy popełniam kradzież postrzeganą przez pryzmat tych wynurzeń: przede wszystkim kradnę sam sobie. Czas pozostały mi od chwili obecnej do mogiły.