Przerwa kawowa #43. 6 błędów programistycznych, które uniemożliwiają Ci zdobycie wymarzonej pracy. Jak po raz pierwszy przyczynić się do powstania oprogramowania Open Source

6 błędów programistycznych, które uniemożliwiają Ci zdobycie wymarzonej pracy

Źródło: Medium Aby znaleźć pracę jako programista, musisz posiadać repozytorium Git. Jest to jedna z pierwszych rzeczy, na którą zwracają uwagę rekruterzy. Aby Twoje repozytorium zrobiło pozytywne wrażenie, powinno zawierać projekty z ostatnimi zmianami. Pokazuj tylko projekty, z których jesteś dumny, a nie każdą linijkę kodu, którą kiedykolwiek napisałeś. To są podstawy pracy z repozytorium. Pamiętaj, że prędzej czy później ktoś spojrzy na Twój kod i sprawdzi, czy pasujesz do firmy. To będzie dla Ciebie decydujący moment. Po kilku minutach rekruter podejmie decyzję, czy zaprosić Cię na rozmowę kwalifikacyjną. I tutaj jest zarówno dobra, jak i zła wiadomość. Zła wiadomość jest taka, że ​​prosty błąd może zmniejszyć Twoje szanse na zdobycie pracy. Dobra wiadomość jest taka, że ​​ludzie zazwyczaj nie chcą zagłębiać się w kod. Potrzebują ogólnego zrozumienia kodu i architektury. Więc nie musisz być geniuszem - wystarczy, że jesteś dobrym programistą. Oto kilka typowych błędów popełnianych przez początkujących. Unikaj ich, a Twoje szanse na rozmowę kwalifikacyjną dramatycznie wzrosną.

Nieaktualne komentarze

Programiści mają różne zdanie na temat komentarzy. Niektórzy je kochają, inni nienawidzą. Nie możemy dojść do wspólnego wniosku, czy warto komentować kod i w jakich przypadkach to robić. Ale wszyscy są zgodni co do jednego: jeśli masz komentarze, powinny one pasować do Twojego kodu. Istnieją komentarze wyjaśniające kod. Kiedy Twój kod jest złożony lub niejasny, potrzebujesz pomocy, aby czytelnicy go zrozumieli. Zmieniając kod, musisz także zmienić swój komentarz. Jeśli tego nie zrobisz, Twój komentarz nie będzie już przydatny. Zły komentarz jest znacznie gorszy niż brak komentarza. Co gorsza, komentarze są wyróżnione w kodzie. Nowoczesne IDE wyróżniają komentarze innym kolorem, aby ułatwić ich czytanie. Dodając komentarz, umieszczasz w kodzie znak „czytaj mnie”. W ten sposób można łatwo wykryć wszelkie rozbieżności pomiędzy komentarzem a kodem. Wybieraj mądrze swoje komentarze i pamiętaj o ich aktualizacji wraz z kodem. W ten sposób będą Ci dobrze służyć.

Połączenie bibliotek i języków z tymi samymi przypadkami użycia

Przed pierwszą rozmową kwalifikacyjną musiałem rozwiązać problem rekrutacyjny. Była to prosta aplikacja internetowa, więc napisałem trochę kodu, wyszukałem w Google kilka skomplikowanych pytań i aplikacja była gotowa. Podczas rozmowy rekruter zapytał mnie, dlaczego w całym kodzie zmieszałem kod jQuery ze zwykłym JavaScriptem. Moja odpowiedź? „Umm…” Szczerze mówiąc, wkleiłem kilka fragmentów kodu ze Stack Overflow. Nie myślałem o tym zbyt wiele. Kod zadziałał, więc ruszyłem dalej. Ten błąd jest bardzo powszechny wśród nowych programistów. Jesteśmy tak skupieni na rozwiązywaniu problemów w pracy, że nie zwracamy uwagi na to, jak to robimy. Nie bądź jednym z nowicjuszy, którzy wpadną w tę pułapkę. Sprawdź każdą linię kodu i upewnij się, że wiesz, dlaczego ją tam umieściłeś.

Powtórzenie kodu

Nie powtarzaj się (DRY) to dogmat programowania. Tworzenie abstrakcji dla powtarzalnego kodu jest esencją programowania. Tak, na początku może to być trudne. Jeśli chcesz rozwiązać problem, robisz to w każdy możliwy sposób. Następnie przechodzisz do innych zadań, a powtarzalny kod zostaje z Tobą. Możesz pozbyć się tego nawyku, tworząc dla siebie zestaw zasad. Za każdym razem, gdy udoskonalasz funkcję, przeczytaj kod ponownie i sprawdź, czy możesz coś zrobić, aby to zmienić. Pamiętaj, że pierwsza wersja kodu jest zazwyczaj błędna i możesz ją poprawić. Kiedy zauważysz zduplikowany kod, poświęć trochę czasu na jego przestudiowanie. W ten sposób możesz znaleźć najlepszy sposób przepisania go (na przykład używając pętli lub tworząc nową funkcję). Jeśli będziesz robić to czyszczenie za każdym razem, otrzymasz bardziej niezawodny i elegancki kod.

Nieobsługiwane błędy

Stworzenie sensownej aplikacji, która zawsze będzie działać bezbłędnie, jest prawie niemożliwe. Niezależnie od tego, czy wypełniasz bazę danych, czy wykonujesz wywołania API, pojawiają się błędy. Nieobsługiwane błędy mogą nie tylko zatrzymać działanie poszczególnych funkcji, ale mogą nawet spowodować awarię całej aplikacji. Przewidywanie możliwych błędów jest oznaką kompetentnego programisty. Za każdym razem, gdy uzyskujesz dostęp do jakichkolwiek danych zewnętrznych lub je aktualizujesz, musisz być przygotowany na najgorszy scenariusz. Oznacz potencjalne problemy w sposób, który nie sprawi, że aplikacja będzie nieporęczna. Umożliwi to czytelnikom Twojego kodu (i być może Tobie) szybkie znalezienie błędów. Pokaże także rekruterowi, że potrafisz napisać spójny kod.

Brak spójności

Spójność jest cechą charakterystyczną oprogramowania wysokiej jakości. Dzięki temu kod jest łatwiejszy do odczytania i utrzymania. Kod stworzony w jednolitym stylu jest bardziej przewidywalny i łatwiej ocenić wydajność programu. Na wyższym poziomie abstrakcji spójność jest trudna do osiągnięcia. Opanowanie tej techniki zajmie lata, dlatego musisz zacząć uczyć się tej techniki tak wcześnie, jak to możliwe. Pamiętaj, aby tworzyć tytuły używając tylko jednego języka. Prawdopodobnie powinien to być język angielski, ale w projektach osobistych możesz nazywać zmienne i funkcje w dowolnym języku, pod warunkiem, że jest to zawsze ten sam język. Jeśli zachowasz spójność, nie ma znaczenia, czy użyjesz tabulatorów, czy spacji. Stwórz lub wybierz przewodnik po stylu i zawsze się go trzymaj. Powinieneś także użyć narzędzia takiego jak Prettier . To naprawdę pomaga w utrzymaniu spójnego formatu kodu. Niezależnie od tego, jakich narzędzi i stylów używasz, używaj ich konsekwentnie. Nawet jeśli napiszesz zły kod w spójnym stylu, zwykle jest to lepsze niż niespójnie dobry kod, ponieważ znacznie łatwiej go naprawić.

Nieporozumienie dotyczące narzędzi

W typowym projekcie prawdopodobnie będziesz musiał skorzystać z jakiejś zewnętrznej biblioteki. Wielu programistów instaluje biblioteki niemal automatycznie, ponieważ są one wykorzystywane w każdym projekcie. Biblioteki zewnętrzne są świetne, bo są sprawdzonym sposobem na rozwiązanie powtarzających się problemów. Jednak nowi programiści często nie rozumieją, jakich bibliotek używają i w rezultacie dodają jedną bibliotekę do drugiej lub ponownie implementują niektóre istniejące funkcje. Za każdym razem, gdy instalujesz bibliotekę w swoim projekcie, przeczytaj lub przynajmniej przejrzyj dokumentację. Sprawdź metody i właściwości, których możesz użyć i upewnij się, że rozumiesz, które problemy biblioteka powinna rozwiązać, a które wymagają użycia innego narzędzia. W ten sposób możesz wybrać odpowiednie narzędzia do danego zadania i wyjaśnić swój wybór.

Jak po raz pierwszy przyczynić się do powstania oprogramowania Open Source

Źródło: Jamestucker.dev Któregoś dnia zobaczyłem tweeta Evana Yu (twórcy Vue.js ) na temat nowego repozytorium, nad którym pracuje, i bardzo mnie to zainteresowało. Zdecydowałem, że chcę się do tego przyczynić! Problem w tym, że nigdy wcześniej nie brałem udziału w projektach open source i nie wiedziałem od czego zacząć. Ale to nie może być takie trudne, prawda? Gdy tylko weszłam do repozytorium, od razu zamarłam. „Co do cholery mam zrobić?” – pomyślałem. Jeśli złożę PR (żądanie ściągnięcia, żądanie połączenia), specjaliści prawdopodobnie rozerwą mój kod na kawałki. Zawsze będę znany w świecie deweloperów jako facet, który nie wie, jak właściwie pracować z oprogramowaniem open source. I moja kariera się skończy. Na szczęście przeczytałem artykuł (nie pamiętam gdzie), którego autor radził, aby pierwszy wkład w cudze repozytorium powinien być jak najbardziej dyskretny. Może to być coś tak prostego, jak poprawienie literówki. I tak zrobiłem. Przeczytałem dokumentację repozytorium, znalazłem kilka literówek, otworzyłem PR i oto Evan zatwierdził moje zmiany. Oficjalnie jestem współpracownikiem Vue! Może powinienem umieścić to w mojej biografii na Twitterze?

„To świetnie, ale jak zacząć?”

OK, zaczynajmy: pokażę Ci kroki, które możesz podjąć, aby coś zmienić.

1. Znajdź projekt

Aby uzyskać inspirację, pomyśl o swojej ulubionej technologii lub narzędziu. Załóżmy, że pracujesz z JavaScriptem i często używasz Gatsby'ego ? Sprawdź ich repozytorium ! Możesz także przyczynić się do jednego z moich repozytoriów. Oto lista moich projektów frontendowych. Jeśli masz coś, co Ci się podoba lub uważasz za przydatne, będzie mi miło, jeśli to dodasz! Wreszcie Awesome First PR Opportunities to gigantyczne repozytorium projektów open source dla początkujących. Istnieją projekty w 22 różnych językach!

2. Zdecyduj, w jaki sposób możesz wnieść swój wkład

Sprawdź projekt. Przeczytaj plik Readme. Skanuj różne foldery i pliki. Zrozumienie struktury bazy kodu. W ten sposób możesz łatwo znaleźć i poprawić literówkę! Gdy już to zrobisz, spójrz na sekcję Problemy w projekcie. Znajdziesz tam listę wcześniej znalezionych błędów lub sugerowanych funkcji. Na szczęście wiele projektów wiąże się z problemami przeznaczonymi dla początkujących. Uważam, że Twój pierwszy wkład powinien być jak najbardziej subtelny, ale jeśli chcesz szybko zyskać uznanie, to zależy od Ciebie. Gdy znajdziesz coś, co możesz dodać do projektu, będziesz musiał to rozwidlić.

3. Stworzenie forka projektu

Fork (fork projektu) tworzy jego dokładną kopię w twoim własnym repozytorium Github.

4. Sklonuj projekt lokalnie

Następnie sklonuj projekt do folderu lokalnego, używając adresu URL projektu.

git clone <project-url>

Tutaj znajdziesz adres URL. Teraz, gdy projekt znajduje się na Twoim komputerze, otwórz go w edytorze. Jeśli uważasz, że zmiany będą wymagały czasu, pamiętaj o zsynchronizowaniu kopii projektu z oryginałem, aby zawsze mieć świadomość zmian. Dokładne polecenia Git do tego celu znajdziesz tutaj .

5. Utwórz nową gałąź dla swoich zmian

Czas na zmiany/poprawki! Utwórz nowy oddział, w którym zmiany zaczną obowiązywać.

git branch <branch-name>

Możesz to nazwać jak chcesz, ale z mojego doświadczenia wynika, że ​​w oryginalnym projekcie będziesz mógł zobaczyć wzór nazewnictwa gałęzi. W tym przypadku polecam zastosować się do istniejącego szablonu. Dobra nazwa oddziału do naprawienia literówki to patch/typo-fix . Możesz przełączyć się do tej gałęzi za pomocą git checkout <branch-name> . Teraz dokonaj zmian!

6. Otwórz PR (żądanie połączenia)

Poprawiłeś więc rażącą literówkę lub zaktualizowałeś uszkodzony link. Jesteś dumny ze swojej pracy. Chcesz, aby cały świat wiedział, że jesteś jednym z tych mitycznych programistów, którzy potrafią jednocześnie kodować, kasować i oglądać Netflix. Wypchnij swoje zmiany do rozgałęzionego repozytorium Github za pomocą git Push -u Origin <branch-name> . Przejdź do rozwidlonego repozytorium Github i otwórz żądanie ściągnięcia. Uwaga: jeśli nigdy wcześniej nie wykonywałeś żądania ściągnięcia, obejrzyj ten film autorstwa Kenta Doddsa, aby dowiedzieć się, jak to zrobić. Upewnij się, że Twoja gałąź wskazuje na gałąź główną repozytorium źródłowego. Teraz możesz dodać szczegóły do ​​swojego PR. Upewnij się, że nagłówek wyraźnie przekazuje treść PR. Dodaj opis: Jeśli rozwiązujesz istniejący problem, pamiętaj o dołączeniu łącza do niego. Po zakończeniu opisu prześlij swój PR do sprawdzenia. Osoba posiadająca uprawnienia do zatwierdzania PR prawdopodobnie sprawdzi Twój wniosek w ciągu kilku dni i wykona jedną z następujących czynności:

1. Natychmiast scalę zmiany.
2. Poprosi Cię o wprowadzenie zmian.
3. Zamknę Twój PR.

Prosimy o cierpliwość, gdyż twórca repozytorium może być zajęty pracą na pełny etat lub innymi projektami.

Zrobiłeś to!

Jesteś teraz współautorem projektu open source! Jak to jest? Gotowy do zbudowania własnego konkurenta Node.js? Mam nadzieję, że wnosząc prosty wkład, perspektywy przyszłych prac nad oprogramowaniem open source staną się mniej zniechęcające. Aby uzyskać więcej informacji na temat wkładu open source, zapoznaj się z przewodnikami open source .