Porady

Bardzo ważną umiejętnością programisty jest dobra pamięć. Przejawia się w kilku aspektach. Po pierwsze developer powinien orientować się w kodzie aplikacji. Powinien przynajmniej mniej-więcej orientować się, gdzie znaleźć kod który kiedyś napisał, lub umie go szybko znaleźć (np. przez wyszukanie nazwy klasy, czy jakiejś konstrukcji języka programowania/biblioteki). Po przepracowaniu w projekcie kilku tygodni powinien również w miarę orientować się co do pozostałych, nie napisanych przez niego częściach kodu aplikacji.

Po wtóre, programista napotykając się na jakieś zagadnienie/problem powinien zapamiętać co było przyczyną problemu, jego rozwiązanie (a także możliwe inne rozwiązania), tudzież podstawy teoretyczne tego zagadnienia. Przykładowo, miałeś kiedyś za zadanie zaimplementowanie systemu płatności na stronie www. Przeczytałeś kilka artykułów na ten temat, zrobiłeś research odnośnie tego, jaką platformę płatności wdrożyć. Idealną sytuacją jest ta, w której x miesięcy później będziesz musiał wykonać podobną rzecz nie będziesz musiał poświęcić aż tyle czasu na to jak za pierwszym razem. Pewnie będziesz musiał sobie odświeżyć kilka informacji (np. sprawdzić, czy w międzyczasie nie powstał jakiś lepszy system płatności), ale mimo to powinieneś mieć już w głowie zarys, plan działania.

Używaj spacji zamiast znaków tabulacji w kodzie. Przyjmuj 1 tabulator to 2 lub 4 spacje. W większości edytorów kodu/IDE można ustawić automatyczną konwersję tabulacji na ustaloną ilość znaków spacji.

Zwykle warto pisać kod jak najbardziej bardziej jasno. Mając do wyboru dwie konstrukcje języka programowania, które dają ten sam wynik, wybieraj tą, która jest najprostsza do przeczytania, i do zrozumienia. Wyjątkiem mogą być sytuacje, gdzie bardziej zwięzła forma działa o wiele szybciej, i ten kod jest kluczową częścią aplikacji, która musi działać jak najszybciej. Wtedy należy wybrać trudniejszą postać kodu, i opatrzyć komentarzem.

Używaj style guideów. Są to poradniki, zestawy dobrych praktyk, konwencji, dzięki którym pisany przez nas kod będzie łatwiejszy w czytaniu, modyfikacji, szybszy w działaniu itp. Style guide'y mogą być oficjalnie zamieszczone na witrynie języka programowania, a także tworzone przez przez poszczególne firmy i pojedynczych deweloperów (grupę developerów). Nie musisz stosować się do wszystkich zasad z danego style guide'a. Nie zawsze przyjmowanie bezkrytycznie wszystkich wytycznych jest dobre, ale dobry, popularny style guide jest rezultatem często wielu lat doświadczeń wielu ludzi, zatem jest duża szansa, że użycie go będzie pozytywne również w naszych projektach.

Zaczynając pracę w projekcie nie szarogęś się. Jeśli widzisz jakieś elementy, które mogłyby być zmienione, poprawione to oczywiście możesz to zakomunikować innym członkom zespołu, czy właścicielowi produktu. Jednak nie upieraj się na rozwiązania według własnego mniemania, jeśli pomysł nie spotka się z akceptacją. Przykładem takiego niestosownego, złego zachowania może być sytuacja w której 'świeży' pracownik chce za wszelką cenę wymusić zmianę biblioteki A na bibliotekę B, czy frameworka testowego na inny.

Zwykle złym pomysłem jest poprawianie/refactoring każdego fragmentu kodu jaki spotykasz w aplikacji. Nawet jeśli jest on kiepsko napisany (lub np. niewydajny) działa on poprawnie (przynajmniej można tak założyć). Każda ingerencja w kod niesie za sobą ryzyko jakiegoś niedopatrzenia, pominięcia jakiejś zależności i w rezultacie ryzyko błędnego działania aplikacji. Zatem przekształcania/naprawianie istniejącego kodu ma sens przede wszystkim wtedy, kiedy pracujemy nad funkcjonalnością/błędem związanym z owym kiepskim kodem. Pracując nad obecnym zadaniem możemy przy okazji postarać się poprawić istniejący już kod na którym np. będziemy opierać własny nowy ficzer. Oczywiście, nawet w takim przypadku istnieje ryzyko błędu. Warto rozważyć skonsultowanie takiego zamiaru z innym programistą.

Pracując na jakimś zadaniem czasem warto zostać odrobinę dłużej w pracy i je skończyć, jeśli czujemy, że niedużo brakuje do jego końca (np. 10 min.). Dzięki temu na następny dzień nie będziemy musieli przypominać sobie całego kontekstu zadania, oraz zastanawiać się czego jeszcze nie zrobiliśmy przy tym zadaniu.

Przesiadywanie w pracy 'po godzinach', spędzanie w biurze więcej czasu niż to wynika z umowy jest złym pomysłem i nie powinniśmy tego praktyktykować. Z drugiej strony jednak jeśli raz na jakiś czas zdarzy się sytuacja, gdy np. właściciej aplikacji będzie potrzebował danej funkcjonalności na dziś, a nie będzie to wymagało spędzenia olbrzymiej ilości dodatkowego czasu w pracy to prowidłowym odruchem programisty powinno być dostarczenie tej rzeczy, nawet jeśli wiązałoby się to z zostaniem np. 0.5h dłużej w biurze. Pokazujemy tym samym, że zależy nam na sukcesie produktu. Jeśli takie sytuacje powtarzałyby się często, to trzeba znaleźć ich przyczynę, a nie pracować co dzień np. godzinę dłużej niż powinniśmy. Pytania jakie możemy wtedy sobie/product ownerowi zadać to np. czy nie wykonuję zadań zbyt wolno, czy nie dostaję za mało czasu na zadanie, czy nie dostaję nowych zadań do wykonania koniecznie dziś zbyt późno w ciąg dnia.