Nie kradnij

11

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.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

11 Comments

  1. Pingback: dotnetomaniak.pl

  2. Pracuję w firmie w której metodologia pracy nie uwzględnia testów jednostkowych na etapie programowania. Utrzymujemy stabilne systemy w starych technologiach, a nowe technologie to już tylko kawałki integrujące z systemami zewnętrznymi. To dlatego niedawno pisałem, że mój programistyczny kamień przestał się toczyć … ale m.in. dzięki temu blogowi ruszył na dobre.
    Otóż przez jakiś czas poznawałem całą zawiłość zastanych systemów i nie krytykowałem.
    Mijał czas i widziałem jak powoli staję się “devszmatą”, dobrym kolegą Copiego-Pejsta.
    Kiedy jednak zanurzyłem się w świat TDD, DDD, ORM i w ogóle nowych trendów, zacząłem odważniej myśleć o zmianach które wprowadzam. Pierwsze (zresztą wygrane) starcie polegało na wyjaśnieniu dlaczego definitywnie przebudowałem strukturę kodu w którym miałem tylko wykonać przeklejki z analogicznych części systemu. Kiedy pojawiły się błędy podczas testów, początkowo stałem na przegranej pozycji w środowisku, które nie przywykło do zmian metodologii. Kiedy jednak metodycznie przygotowywałem obronę swojej strategii, szybko okazało się, że to “nowe” sprawdza się świetnie nie tylko jako wykonana praca, ale także jako element poddający się testowaniu. To nowe pozwoliło w ogóle na odnalezienie problemu, którym był nigdy nie wyłapany, stary błąd.
    Dzisiaj mam wrażenie że “devsłońce” promieniście świeci każdego ranka, mimo że za oknem czasem buro i plucha ;)

    PS.
    Wielu z Nas zapewne pracuje tylko z najnowszymi technologiami.
    Jednak część (np. ja) utrzymuje także stare systemy w starych technologiach. W mojej firmie jest to powodem odejść młodych ludzi, którzy nie chcą pracować z “brzydkim, starym, kodem”.
    Dla mnie jednak nowe nie oznacza tylko nowej wersji języka. Sama nowa metodologia pracy pozwala na wdrażanie analogii najnowszych rozwiązań do wielu języków, nawet tych starych i topornych.

  3. tchrikch on

    To chyba bardzo podobne do “nie krytykuj” – jak nie widzisz po zrobieniu projektu jak zrobic go lepiej to znaczy ze jest zle…

  4. @tekkno Nie jesteś sam, mam podobnie :))). Co gorsza, to są moje własne “grzechy młodości”, czyli system w C++/ADO/MFC napisany z zastosowaniem wzorca “smart UI”. Co za kretyn to pisał :))). Wszystko da się stopniowo odgruzować lub chociaż okiełznać. Ja i tak mam szczęście bo utrzymanki zżerają mi nie więcej niż 10-15% czasu. Jak ktoś zajmuje się tym na 100% to trudniej mu przeszczepić nowe idee np.: TDD (podrzucę, choć pewnie znasz: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052). Z doświadczenie wiem, że najłatwiej jest sprzedać Continuous Integration – jak już masz automatyczne buildy, to potem cichaczem podpinasz testy… Trzeba lobbować, robić prezentacje, chwalić się ile to Ci pracy zaoszczędziło… A’propos taki filmik kiedyś popełniłem:

    http://orientman.wordpress.com/2011/02/01/etiuda-filmowa-p-t-czy-stosowac-testy-automatyczne/

  5. Przemysslaw on

    Dobrze pamiętam ten cytat, bo swego czasu pojawił się na Twoim blogu ;) Pamiętam, że było to w trakcie mojej pierwszej pracy jako “developer” i dało mi do myślenia i zmotywowało do zapoznania się chociaż pobieżnego z NHibernatem. Ba! Nawet chciałem przeforsować jego użycie w projekcie, nad którym pracowałem – niestety bezskutecznie :/ Skończyło się na klepaniu zapytań i karkołomnych konstrukcjach z udziałem StringBuilder’a :/ Obecnie wdarł się troche marazm w moje poczynania, ale chyba między innymi powrót do lektury książek i Tojego bloga motywuje mnie pomału do walki ;) Szkoda, że wiele rzeczy trzeba eksplorować w “wolnym” czasie ale to chyba taka karma ;) Pozdrawiam

  6. Mógłbym się w temacie rozwinąć ale innym razem. Ale napiszę tylko że nazywanie marnotrawstwa złodziejstwem jest irracjonalne. Od programisty takie głupoty … No szkoda. Często się rzeczy dziś nie nazywa po imieniu dla wygody (dla firmy)która nas okrada. Np. Play mnie okradał z pieniędzy bo płaciłem za internet którego nie miałem a oni zwyczajnie czerpali z tego korzyści i robili to celowo iświadomie. Mniejsza… Jest różnica.

  7. A to był taki spokojny blog… :). Oto przykład czystej wody kradzieży: http://demotywatory.pl/3916127

    Maciej nie stawia znaku równości. Świadome czy nieświadome marnotrawstwo ogromna różnica. Czy to co marnotrawię należy do mnie czy nie? Też różnica. A jeśli nawet jest to tylko “mój” czas – to może jest tak, że ten gorszy ja kradnie go dla swojej wygody i z lenistwa od tego lepszego ja, którym mógłbym być. Ciekawe, że nawet w KKK w rozdziale o kradzieży jest mowa o marnotrawstwie.

    Świetny post BTW – szczególnie podoba mi się aluzja na końcu do http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx

  8. Arek Bal on

    To bądź boshe nie było skierowane do Macieja który skutecznie się od “kradzieży” odżegnuje w powyższym artykule.

Newsletter devstyle!
Dołącz do 2000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania wkrótce!
Niech DEV będzie z Tobą!