Tydzień 45

Szlifowanie aplikacji Fronend Quiz i wypuszczenie jej na świat, a później zabawa z serwerem na maszynie wirtualnej. To nie był tydzień poświęcony zgłębieniu wiedzy, a raczej pogłębianiu już zdobytych umiejętności. Czyszczenie błędów wyłapanych przez Eslint i walka o uruchomienie serwera Apache2 na wirtualnym serwerze Ubuntu.

Ciekawym doświadczeniem z tego tygodnia było napisanie prostej strony www tylko w jednym pliku index.html. Jak ja doceniłem możliwość pisania CSS w osobnym pliku, ba możliwość wykorzystania SASS. Doskonale zrozumiałem i doceniłem konwencje jakie panują przy tworzeniu stron WWW. Pisanie klas CSS w pliku html ciężko porównać do czegokolwiek. Trudno o utrzymanie przejrzystości kodu i trudno o szybką edycję w przeglądarce. Czysta masakra.

Jak już wspomniałem, w tym tygodniu czystej nauki kodowania było niewiele, za to jest czas na pewne refleksje odnośnie tego co warto robić, a czego nie warto robić będąc programistą. To nie są porady wymyślone przeze mnie, bo większość z nich można znaleźć w różnych miejscach w internecie. Ja po prostu zebrałem je w jedno miejsce i dodałem do nich własny komentarz.

Najczęściej przejawiającym się problemem jest poczucie, że mój kod jest najlepszy na świecie. Na początku drogi w IT łatwo to zrozumieć. W zasadzie każdy Code Review jasno pokazuje nam, że można napisać coś lepiej. Jednak wraz ze wzrostem umiejętności można nabrać przekonania, że teraz to już piszę najlepszy kod na świecie. Może tak jest, ale nadal może znaleźć  się ktoś, kto napisze to samo lepiej. Oczywiście bycie zadowolonym z wyników swojej pracy to nic złego, ale twierdzenie, że nie da rady napisać kodu lepiej, to już problem dla Ciebie i zespołu.

Drugą odsłoną powyższego zagadnienia jest popełnianie błędów. Ważne jest zrozumienie i przyswojenie sobie, że każdy programista popełnia błędy. Jesteśmy ludźmi i każdy może mieć gorszy dzień, rozkojarzyć się na moment i zupełnie niespodziewanie i niechcący popełniamy błąd. Co gorsza może się okazać, że błąd poszedł na produkcję i narobił bałaganu. To czarny scenariusz, ale całkiem prawdopodobny. Najgorsze, co można zrobić w takim wypadku, to kłótnia o to, czyj to błąd. Prawda jest taka, że pracując z systemem kontroli wersji bardzo łatwo dojść do tego, kto popełnił błąd. Udowadnianie sobie nawzajem, kto zawinił nie rozwiąże problemu klienta, ani nie przyczyni się do utrzymania dobrej atmosfery w zespole. Lepiej od razu się przyznać, jeżeli to faktycznie nasz błąd i pójść dalej. To teoretycznie trudniejsza droga, ale na dłuższą metę warta zachodu.

Czy to znaczy, że nie będąc ideałem jesteśmy skazani na porażkę. Nie. Wielu utalentowanych developerów twierdzi, że wcale nie są wybitni, że są programiści lepsi od nich i że wcale im to nie przeszkadza w prowadzeniu ciekawej kariery zawodowej. Według mnie kluczem do sukcesu jest staranie się za każdym razem, przy każdej linijce kodu i ciągłe pogłębianie swojej wiedzy. Wielu szkoleniowców powtarza również, że talent pomaga tylko na początku drogi, bo jesteś w stanie nauczyć się pewnych rzeczy szybciej. Jednak na dłuższą metę prawdziwy sukces odnoszą Ci, którzy potrafią dzień po dniu doskonalić się i wypuszczać coraz lepszy kod.

Szukanie drogi na skróty, to normalny odruch ludzki. Nasz mózg jest tak skonstruowany, że jego nadrzędnym celem jest utrzymanie nas przy życiu jak najdłużej. Stąd większość ludzi uwielbia drogi na skróty, bo to pozwala zaoszczędzić nam energię. Więcej energii, to większa szansa na przeżycie. Jednak to co działało przez setki lat i pozwoliło ludziom przetrwać w niezbyt sprzyjających warunkach, nie sprawdza się w programowaniu. Owszem na krótką metę pójście na skróty może pomóc w rozwiązaniu konkretnego problemu, ale czy zastanawiałeś się kiedyś jak ten skrót wpłynie na całą aplikację? Czy ten skrót nie utrudni wprowadzania kolejnych funkcjonalności do aplikacji? Czy nie będzie generował błędów w specyficznych sytuacjach? Czasami skrócenie czasu pracy nad kodem na dłuższą metę nie opłaca się i zawsze warto przemyśleć to zanim pójdziemy na skróty.

Na koniec zostawiłem aspekt związany z ludzką pamięcią. Każdemu może zdarzyć się sytuacja, w której czegoś zapomni. Warto zapamiętać, że zaglądanie do dokumentacji, to nic złego. Ilość informacji, jakie musi przyswajać programista jest ogromna. Nie ma więc nic złego w tym, że czegoś nie wiesz. Może w odpowiedzi na jakieś pytanie powiedzieć: „muszę to sprawdzić”. Na początku drogi może się wydawać, że powinieneś wszystko wiedzieć i nie wolno Ci czegoś nie wiedzieć. To nieprawda. Każdy ma prawo zajrzeć do dokumentacji, żeby przypomnieć sobie jak dana funkcja działa, jaką ma składnię. Najważniejsze jest potrafić szukać odpowiedzi na pytania/problemy jakie napotykamy.

W tym tygodniu pracy z kodem było niewiele, bardziej kosmetyka jeżeli chodzi o aplikację, a potem długie godziny konfiguracji serwera www. Z tej drugiej czynności przygotuję krótki poradnik, bo ta wiedza może się przydać. Tak wiem, że jest XAMPP i AMPPS, ale serwer na wirtualnej maszynie, to jednak trochę coś innego, pozwalającego przetestować aplikację w niemal rzeczywistych warunkach.

No comments
Krzysztof NyrekTydzień 45

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *