Nie można rozliczać programisty z ilości kodu
W obliczu sytuacji w pracy jaka ma u mnie w pracy aktualnie miejsce przyszła mi do głowy myśl, którą umieściłem w tytule. Jest ona dosyć oczywista dla większości programistów. Ale z jednej strony znajduję w internecie informacje o pracodawcach, którzy patrzą na ilość kodu. Z drugiej strony regularnie czytam pytania młodych programistów, którzy zastanawiają się ile linii kodu powinien mieć projekt żeby był „profesjonalny”. A nie o to w tym wszystkim chodzi. Bo bardzo dobrym programistą może być ten, który powie, że jakiegoś kodu w ogóle nie trzeba pisać.
Kiedy chcesz się dopasować
Co takiego się w takim razie dzieje w pracy? Sytuacja jest taka, że moim zadaniem było przygotowanie mobilnej wersji tabeli na stronie głównej. Wymyśliłem koncepcję. Napisałem wstępnie style i strukturę HTMLa. Wszystko wygląda ok i działa. Jednak uważam, że nawet jeśli jest to trochę proof of concept to powinien być dopasowany do tego co już w projekcie jest. A w projekcie jest biblioteka Knockout. Szablony, view modele i binding handlery zbudowane są w konkretny sposób. Wszystkie tak samo. Wszystkie w jednym miejscu. Dlatego też uznałem, że nie mogę się wybijać i zrobić czegoś na boku. Jakiejś protezy. Dlatego zacząłem analizować strukturę i próbować zmapować ją na to co sam zrobiłem. I tak mijał dzień za dniem. Bo dla osoby, która dopiero weszła w projekt i nie jest mocna w używaniu Knockouta wszystko jest nowe.
Siedzę więc od zeszłego tygodnia i przeglądam kod, próbując uruchamiać kolejne elementy z moim kodem. Idzie bardzo powoli bo w trakcie się muszę uczyć jak to działa. Dzisiaj w końcu udało mi się zrozumieć gdzie leżał problem i dlaczego dostawałem kolejne błędy.
Czy w takim razie jestem słabym programistą bo napisałem w tym czasie mało kodu?
Cel, nie ilość
Mogłem się nie dopasowywać do tego co jest. Nawet nie użyć Knockouta, którego średnio znam. Wszystko bym napisał ręcznie. Pewnie kod by powstał szybko i byłoby go dużo. Dla niektórych byłaby to dobra robota.
Jednak robiąc to pokazałbym, że nie zależy mi np. na spójności w projekcie. Albo, że nie potrafię się dostosować i przyjąć ustalonych reguł. Pewnie też wymyślałbym koło na nowo, bo przecież mechanizm istnieje. Wystarczy go wziąć i zastosować.
Moim zdaniem błędem byłoby pójście w ilość kodu i szybkość jego pisania. Dobrym programistom płaci się za to żeby projekty były zrobione dobrze. Nie za to żeby było w nich dużo kodu. Tak naprawdę minimalizowanie ilości kodu jest zaletą. Mniej kodu to mniej potencjalnych źródeł problemu. Nie bez powodu niektórzy mówią, że idealnie jak na koniec dnia bilans linii napisanego kodu jest ujemny.
Dlatego dopóki czas mi na to pozwala to będę zawsze starał się znaleźć rozwiązanie jak najlepiej pasujące do reszty projektu (jeżeli nie mogę zmienić tej reszty projektu). Sądzę, że dzięki temu dostarczam coś, co potem nie będzie utrapieniem dla zespołu czy firmy. Jeśli ktoś uważa, że najważniejsze jest aby kod pisać szybko i w dużych ilościach to być może nie musiał potem takiego projektu utrzymywać. Wiąże się to chociażby z jakością kodu, o której pisałem. Szybko tworzony kod to prawdopodobnie kod pełny „kopiuj-wklej” albo wynajdujący koło na nowo w każdej metodzie.
Doświadczony programista to taki, który potrafi powiedzieć, że w pewnych sytuacjach lepiej użyć gotowego rozwiązania bez pisania nawet linii kodu. Albo potrafiący zachować spójność i korzystać z tego co w projekcie już istnieje lub modyfikować to co jest tak aby minimalizować ilość kodu potrzebnego do rozwiązania zadania.
Każdy programista ma przecież swój styl pisania programu, jeden lubi ściśle pisać, drugi komentuje swoją pracę, trzeci wszystko robi od nowej linii, a jeszcze inny ma w kodzie chaos. Przecież najważniejszy jest efekt. Projekt ma działać.
Ma działać, ale nie można dopuścić, żeby każdy plik w projekcie wyglądał inaczej. Dlatego każdy programista powinien stosować się do zasad jakie zespół ustalił, chociażby w kontekście formatowania kodu. Bo inaczej zapanuje chaos, a kod stanie się trudny w utrzymaniu. Jeżeli jakieś konwencje uważamy za kiepskie to po prostu sygnalizujemy to w zespole i wspólnie podejmujemy decyzje czy zmieniamy podejście.
Zgadzam się z Markiem, kod powinien być jasny i przejrzysty. Oczywiście nie zawsze da się tak zrobić, ale należy się starać. Projekt ma działać, ale w razie konieczności wprowadzenia poprawki powinno być to względnie łatwe do wprowadzenia.
Dokładnie tak, nie można rozliczać programisty czy webdevelopera, kodera czy innych im podobnych z ilości kodu. To jest chyba niestety aspekt korporacyjny związany z wymogiem raportowania. Skoro programista / koder pisze kod to rozliczajmy go z ilości kodu. Niestety nikt nie bierze pod uwagę, że to mija się z celem bo zazwyczaj ważniejsza jest jakość a nie ilość kodu (co więcej często im mniej kodu wykonującego to samo, tym lepiej). Problem się jednak rodzi w tym jak rozliczać, czy zaraportować takie działania? W branży SEO często spotyka się stwierdzenie by rozliczać agencje za ilość znaków we wpisach blogowych, za ilość linków czy inne tego typu działania addytywne (pomijając mierzalne czynniki takie jak widoczność czy ruch). Śmieszne jest to, że nawet jak te wartościowe czynniki jak widoczność wyszukiwarkach (ilość fraz w TOP X dla danej domeny) czy ruch (ilość sesji /użytkowników miesięcznie z wyszukiwarek) rosną to często osoby za to odpowiedzialne muszą się rozliczyć z tego 'co kupiły’ by to osiągnąć. Powstają wtedy śmieszne wymogi by było ileś linków, ileś artykułów / znaków. Najgorsze jest to, że nikt nie bierze pod uwagę, że nadmiar w niektórych momentach może zaszkodzić i dobry specjalista musi zamawiać lub robić … coś bezwartościowego. Tak. Tylko po to by nie zaszkodzić innym (mniej widzialnym działaniom), ale żeby było co zaraportować. Reasumując nie rozliczajmy się z ilości a z efektów, które można w zdroworozsądkowy (!) sposób monitorować. Pozdrawiam.