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.

Wiedziałeś, że jestem też obecny w serwisie YouTube gdzie również znajdziesz treści związane z programowaniem? Nie?

W takim razie warto to zmienić! Odkryj i zasubskrybuj mój kanał dostępny pod adresem https://www.youtube.com/user/zajacmarekcom

Szukasz książek dla programistów i jednocześnie chcesz wesprzeć tego bloga? Sprawdź ofertę wydawnictwa Helion klikając w TEN LINK.

3 thoughts on “Nie można rozliczać programisty z ilości kodu”

  1. 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ć.

    1. 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.

    2. 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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *