Od Juniora do Seniora: Odpowiedzi na pytania społeczności #10

To już dziesiąta edycja naszej akcji Od Juniora do Seniora. Przypominamy, że jej celem jest dzielenie się wiedzą z początkującymi developerami. Nasza redakcja przeszukała kilkanaście grup na facebooku, by znaleźć ciekawe pytania od juniorów. Pokazaliśmy je seniorom i poprosiliśmy o odpowiedzi. Zobaczcie, jakimi spostrzeżeniami podzielili się na temat ścieżki kariery.

Pytanie #1

Kamil Pyrkosz. Podsuniecie mi pomysł jak w aplikacji typu node/express nie przyjmować żadnych requestów w określonych godzinach? Zrobić to przy pomocy middleware czy może jest jakiś lepszy sposób?

Odpowiada Maksymilian Wojewoda, Developer w RST Software Masters:

Skorzystanie z middleware rzeczywiście wydaje się być tutaj najrozsądniejszym rozwiązaniem. To właśnie middleware jest miejscem, w którym chcemy sterować flow (na podstawie) naszego requestu. Będzie także miejscem, w którym możemy dokonać przekierowania lub wysłać odpowiedni kod błędu w przypadku braku spełnienia przez nasze żądanie jakiegoś warunku (w tym wypadku godziny jego obsłużenia poza zadanym przedziałem).

Na zadane wyżej potrzeby założyłbym, że konkretny czas (obecny, początek przedziału oraz jego koniec) będziemy reprezentować przez ciąg znaków postaci gg:mm. Do pobrania aktualnej daty i ujednolicenia formatu przyda się biblioteka moment.js.

Samo sprawdzenie natomiast sprowadzać się będzie do prostego porównywania stringów: blokujemy dostęp, gdy aktualny czas jest większy niż czas „od” i mniejszy niż czas „do”. Jeśli nasz przedział niedostępności zawiera w sobie północ, wtedy iloraz logiczny w powyższym warunku zamienimy w logiczną sumę.

W przypadku kiedy wynik powyższego sprawdzenia da nam wartość true, zamiast wywołania w naszym middleware funkcji next powinniśmy wysłać użytkownikowi odpowiedni kod błędu (tutaj np. 403) oraz informację o tym, dlaczego jego żądanie nie miało szansy powodzenia.

Osobną kwestią pozostaje sposób pobierania informacji o przedziale, w którym zasoby aplikacji mają zostać zablokowane. Jeżeli określimy, że ograniczenie ma dotyczyć wszystkich endpointów bez wyjątku, włączając w to nasz root route, to możemy taką informację przechowywać jako dwie stałe w kodzie aplikacji. W przeciwnym wypadku należałoby skorzystać z określonego źródła reguł dla naszych endpointów — express umożliwia nam zdefiniowanie wzorca, który dopasuje nasz middleware do odpowiednich routów.

Zobacz też

Juniors 6 rad dla juniora od senior frontend developera

Pytanie #2

Jakub Sobczyński: Na co zdecydować się: Angular czy React? Opinie są różne, chciałbym poznać opinie bardziej doświadczonych osób.

Odpowiada Sebastian Rosik, Senior Front-end Developer w RST Software Masters:

Na co zdecydować się: Angular czy React? Opinie są różne i nie ma na to pytanie jednoznacznej odpowiedzi. Zarówno w Angularze, jak i React można stworzyć każdy rodzaj aplikacji, nie mniej jednak na coś jednak trzeba się zdecydować, nim rozpoczniemy pracę nad nową aplikacją.

Podczas wyboru, oczywistym może wydawać się porównanie samych frameworków/bibliotek pod względem ich funkcjonalności, języków programistycznych, wielkości społeczności czy ekosystemu utworzonego wokół nich (kompatybilne biblioteki, komponenty etc.). Porównanie ich pod tym względem od tej strony jest ważne, ale gdybyśmy tylko na tym poprzestali, moglibyśmy znacznie utrudnić sobie pracę nad projektem. Warto więc przed wyborem utworzyć listę z kryteriami, które pozwolą nam się zdecydować na jedną z technologii.

• Dostępność rozwiązań, jakie nas interesują. Załóżmy, że zależy nam na konkretnym komponencie, który dostępny jest tylko dla Reacta, ale dla Angulara odpowiednik nie istnieje bądź jest niskiej jakości. Jak bardzo kosztowne byłoby dla nas utworzenie go samemu?
• Rozwój. Czy jest przewidziany czas na naukę nowej dla nas technologii? Czy mamy możliwość uczestnictwa w szkoleniu, czy wykonania POC (Proof of Concept) w danej technologii?
• Wielkością projektu. Jest to mały projekt, czy może projekt na lata? Jeżeli mały czy średni, wtedy może lepiej wybrać Reacta. Jeżeli duży, może lepiej Angulara. Jeżeli zdecydujemy się na Reacta dla bardzo dużego projektu, to nie jest to błędem, ale na pewno Angular lepiej by się sprawdził, gdyż jest pełnoprawnym frameworkiem, który pasuje do projektów typu enterprise.
• Doświadczenie zespołu. Nawet jeżeli jest to bardzo mały projekt, to lepiej iść w stronę Angulara, jeżeli tylko zespół jest w nim biegły.

Powyższa lista jest posortowana od najmniej do najbardziej istotnych. Jest to lista, którą sam bym się kierował podczas wyboru. Lista ta nie jest też skończona i na pewno przyjdą nam do głowy inny kryteria, którymi moglibyśmy się kierować.

Podczas wyboru biblioteki/frameworka większe znaczenie ma charakterystyka samego projektu, warunków współpracy z klientem (czas na rozwój) czy także sam zespół developerski, aniżeli funkcjonalności oferowane przez daną technologię.

Na koniec warto pamiętać o tym, by nie skupiać się tylko na jednym frameworku czy bibliotece. Dobrym pomysłem jest zapoznanie się po trochu z najpopularniejszymi rozwiązaniami. Jeszcze lepszym pomysłem jest jednak pogłębianie swojej wiedzy ze znajomości wzorców projektowych oraz umiejętności pisania testów. Framoworki, jak i biblioteki mają to do siebie, że z czasem odchodzą w niepamięć. Natomiast wartość, jaką daje nam dobra znajomość wzorców i umiejętność testowania własnego kodu, z czasem staje się bezcenna.

Oferty pracy z

Pytanie #3

Jędrzej Danko: Refaktoryzacja kodu. Muszę użyć i dodać nowe funkcje do istniejącego (cudzego) kodu. Jak otworzę taki plik, to niestety nie jestem w stanie czytać tego kodu i muszę zrefaktoryzować, np. wydzielić część logiki do podklasy, dodać interfejs, poprawić wstrzykiwanie zależności. Jak zrobić to najlepiej?

Odpowiada Mateusz Budzar, Android Developer z Droids On Roids:

Chcesz zrefaktoryzować kod i chwała Ci za to! Refaktoryzację powinno się robić – w moim przekonaniu – codziennie, lecz trzeba być bardzo ostrożnym. Te małe rzeczy, jak np. zmiana nazwy metody czy pola, ekstrakcja niektórych funkcjonalności do osobnej klasy, warto robić od razu, gdy widzimy, że coś może być niejasne. Na przykład przeczytaliśmy kod, który nie jest dla nas zrozumiały i musieliśmy poświęcić czas, żeby go dobrze zrozumieć. Kiedy już to nam się uda, warto dokonać kilku zmian, żeby kolejni programiści nie musieli tak jak my poświęcać czasu na zrozumienie kodu.

Dopóki te zmiany są małe i raczej estetyczne, to wszystko powinno być w porządku. Zdarza się jednak też taki kod, który może być kluczowy z punktu widzenia działania jednej z funkcjonalności, ale jest zbyt skomplikowany i chcielibyśmy go uprościć. Tylko skąd wiedzieć, czy po naszej refaktoryzacji, wszystko nadal zadziała tak samo? Skąd możemy mieć pewność, czy czegoś nie popsuliśmy? Dzięki testom! Jeżeli są, to świetnie, jesteśmy uratowani, natomiast jeżeli ich nie ma, to dobrą praktyką będzie pokrycie testami tego kawałka kodu jeszcze przed refaktoryzacją. Dzięki temu, po zmianach możemy sprawdzić, czy zachowanie kodu jest nadal prawidłowe.

Bardzo ciekawe podejście do refaktoryzacji przedstawił na konferencji BoilingFrogs Mariusz Sieraczkiewicz. Nazwał to Naturalnym Porządkiem Refaktoryzacji. Zachęcam do obejrzenia prezentacji. Rady tam zawarte (jak np. dodawanie tymczasowych komentarzy do kodu, aby lepiej go zrozumieć, implementowanie wzorców projektowych, co refaktoryzować i kiedy) są w moim przekonaniu bardzo wartościowe i sam stosuję to podejście do dzisiaj.

W tym miejscu nie sposób też nie polecić książki Michaela Feathersa „Working effectively with legacy code”. Jest tam opisane mnóstwo sytuacji oraz rozwiązań związanych z pracą z zastanym (odziedziczonym) kodem. Mam nadzieję, że pomogłem. Powodzenia!

Odpowiada Rafał Kern, Development Lead w RST Software Masters:

Jakąkolwiek przygodę z poważniejszą refaktoryzacją warto zacząć od zapoznania się z (moim zdaniem obowiązkową pozycją każdego developera) “Working effectively with legacy code” Michaela Feathersa. Lektura pozwoli Ci uniknąć wymyślania koła na nowo. Warto przeczytać ją, rzekłbym od “deski do deski” i wracać do niej od czasu do czasu, kiedy tylko czujemy potrzebę przeanalizowania różnych proponowanych rozwiązań w trakcie radzenia sobie z zastanym kodem.

Jeśli już podjąłeś decyzję, że musisz z tym kodem zrobić porządek upewnij się, że:

• rozumiesz jak kod powinien działać, przynajmniej na wysokim poziomie (szczegóły odkryjesz w trakcie refaktoru),
• testy (jeśli są) są napisane poprawnie (tzn. nie zapewniają tylko pokrycia, ale faktycznie sprawdzają, czy wszystko działa jak należy),
• wiesz, ile czasu możesz na niego poświęcić (PM/PO raczej nie będzie zainteresowany, że teraz kod jest ładniejszy, jeśli nie realizuje zadań, które powinien).

Im więcej odpowiedzi na powyższe pytania brzmi “nie”, tym ostrożniej powinieneś działać np.:

• zweryfikuj, czy wszystkie metody publiczne faktycznie takie muszą być,
• określ jaki jest prawdziwy interface takiej klasy,
• zastanów się nad tym, czy nazwy metod są intuicyjne oraz adekwatne do tego, co faktycznie robią i konsultuj nazwy z kolegami z zespołu,
• nie schodź zbyt głęboko i zbyt szybko do kolejnych zagnieżdżonych ifów — lepiej dobrze rozplanować sobie kod na wyższych poziomach, przykryć jakąś fasadą i pójść dalej (na niższe poziomy) gdy będą bardziej sprzyjające okoliczności,
• uzupełnij brakujące testy,
• itp.

Podepnij jakieś narzędzie do analizy statycznej kodu, które powie Ci czy po Twoich zmianach kod faktycznie jest wyższej jakości. Nie traktuj go jak wyroczni, ale jako punkt odniesienia. Możesz sprawdzać np. liczbę zależności wychodzących, złożoność cyklomatyczną, n-path, c.r.a.p. index itp.

Zobacz też

Wywiady Czy studia są warunkiem koniecznym dla Junior Developera?

Pytanie #4

Lech Andrzej: W jaki sposób szukacie zleceń? Pracuję na pełen etat, ale mam okres, że muszę zabić wolny czas i pomyślałem, że podjęcie się zleceń pomoże mi nauczyć się więcej rzeczy.

Odpowiada Michał Fiuk, Technical Lead w CSHARK:

Pomysł rozwoju po pracy jest szlachetny i należy się za niego uznanie. Zlecenia często nie są tak interesujące, jakby się chciało. Zazwyczaj trzeba zebrać portfolio aplikacji, żeby można było uderzyć po fajniejsze, większe projekty i od osób całkowicie obcych. Warto mieć może nawet zaufanego współwykonawcę projektu, co znacznie pozwala skrócić czas pracy po godzinach i pozwoli na skupienie się na pojedynczych problemach i rozwiązaniach. Osobiście uważam, że powinno zaczynać się od szukania zleceń wśród znajomych. Po kilku mniejszych projektach będzie zdecydowanie łatwiej. Stack technologiczny będzie już wtedy bogatszy i pozwoli na zdobycie ambitniejszego projektu. Ciekawym pomysłem jest też wykorzystanie jakiegoś sklepu z aplikacjami jak App Store lub Microsoft Store i umieszczenie tam swojej autorskiej aplikacji.

W ten sposób odcina się problem dystrybucji i aktualizacji, co jest najmniej ciekawą technologicznie częścią. Zapewnia też trochę łatwiejszy zbyt aplikacji, bo aplikacja jest łatwa do ściągnięcia przez potencjalnego odbiorcę. Taka forma cieszy się też większym zaufaniem niż jakiś przypadkowy instalator w sieci. Gdy praca freelancera przy drobnych zleceniach przestaje wystarczać można pomyśleć o poważnym marketingu i śledzeniu leadów.

Pytanie #5

Maciej Janyska: Czy ktoś ma lub miał problem z wypaleniem zawodowym? Jak sobie z tym radzić? Zmiana pracy? A może krok dalej, coś co pewnie dla wielu jest nie do pomyślenia — zmiana branży? Byłbym wdzięczny za podzielenie się swoją historią przez osoby, które zetknęły się z tym problemem.

Odpowiada Michał Fiuk, Technical Lead w CSHARK:

Wypalenie zawodowe może istnieć w każdej branży. Występowanie tego zjawiska w branży informatycznej wydaje mi się mniej prawdopodobne niż w innych. Uważam tak, bo ta część rynku dynamicznie się zmienia. Jedyny scenariusz, jaki mogę sobie wyobrazić to firma typu międzynarodowa korporacja, która ma swoją odgórną drogę na większość problemów. Tutaj odcina się moim zdaniem możliwość rozwoju w pracy. Sytuacja tutaj jest zdecydowanie utrudniona, ale nie niemożliwa. Wymagana tutaj jest praca własna, a nie odgórne podanie technologii i tak zwanego „know how” w pracy. Pracownik branży informatycznej nie jest w stanie sobie pozwolić na rok lenistwa i nie śledzenie trendów. Choćby powierzchownie. W tej branży typowe jest przeciwdziałanie stagnacji. Często są to kursy online lub konferencje.

Idąc o krok dalej praca własna nad aplikacją po godzinach pracy. Sam proces rozpoczęcia pracy nad nowym projektem jest przyciągający. Większość tych projektów nie wykracza poza komputer programisty. Gdy głód wiedzy wykracza poza obowiązki w pracy wtedy następuje przykra konieczność zmiany pracy. Firmy starają się temu przeciwdziałać finansując różne szkolenia i konferencje oraz poprzez aktywne zachęcanie do inicjatyw po godzinach pracy. Jednak chęć do uczenia się trzeba posiadać i jest to wysiłek własny. Jedyne przypadki zmiany branży, jakie spotkałem były spowodowane brakiem własnego rozwoju czy dużą ilością nadgodzin. Jednak takie osoby w zdecydowanej większości wracają do branży w ciągu roku lub dwóch, bo okazuje się, że po drugiej stronie trawa nie była taka zielona.