Pierwsze portfolio na GitHubie – Przewodnik

Na co to komu?

Wysyłając do firm CV na początku kariery raczej nie masz możliwości wpisania w nim doświadczenia zawodowego. A jednocześnie w jakiś sposób chciałbyś pokazać potencjalnemu pracodawcy, że umiesz coś więcej niż ktoś kto po prostu przeczytał jakąś książkę o programowaniu. W końcu liczba kandydatów do pracy jest spora więc tym bardziej warto zadbać o to żeby wyróżnić się jeszcze przez przyjściem na rozmowę, na którą w ogóle musisz być zaproszony.

Wyróżnij się

Sposobem na takie wyróżnienie się jest posiadanie własnych projektów. I to nie tylko w przypadku osób początkujących, bo również doświadczeni programiści zyskują mają swoje portfolio. Ale wracając do Ciebie jako osoby początkującej – skoro nie masz doświadczenia komercyjnego to miej chociaż doświadczenie z pisaniem kodu. Kodu który działa i który możesz opisać. A jeszcze lepiej pokaż jak Twój kod wygląda. Bo zatrudniając osobę początkującą podejmuje się duże ryzyko czy będzie ona rozumiała podstawowe zasady trzymania jakości i będzie potrafiła się odnaleźć w projekcie. I kiedy zaprezentujesz próbkę tego co sam wykonałeś to masz szansę udowodnić, że mimo bycia świeżym w branży masz podstawowe umiejętności.

I właśnie w celu zaprezentowania tej próbki kodu przydaje się posiadanie tego kodu dostępnego. Być może spotkasz się nieraz z określeniem „portfolio na GitHubie”. Chodzi o to, że serwis GitHub pozwala przechowywać Twój kod, obsługiwany za pomocą Gita i dzielić się nim z innymi.

Więc tak naprawdę Twoim „portfolio na GitHubie” jest założone tam konto i dodane repozytoria z kodem. I do takiego profilu możesz zamieszczać link w swoim CV. Jeżeli tylko przejdzie ono do osób technicznych to jest duża szansa, że odwiedzą one taki profil. A wtedy w zależności od tego jak go prowadzisz możesz wywrzeć dobre pierwsze wrażenie albo wywołać mieszane uczucia czy warto Cię zapraszać.

Dlatego warto znać kilka podstawowych zasad dotyczących profilu na GitHubie, którym dzielisz się w CV. Chociaż słowo zasady jest tutaj mocnym określeniem i lepiej by pasowało np. „zalecenia” to jednak zostawię je dla podkreślenia, że warto na ten fragment zwrócić szczególną uwagę.

Zasady

Niezależnie od tego jaki projekt chcesz umieścić w swoim portfolio to warto żebyś trzymał się kilku podstawowych zaleceń. Wynikają one z mojego doświadczenia w oglądaniu takich profili jak również z opinii innych osób, z którymi ten temat omawiałem.

Pamiętaj, że taki profil to Twoja wizytówka. Tak więc jeśli chcesz żeby wyglądała profesjonalnie to pamiętaj o tych kilku punktach.

Upubliczniaj wybrane projekty

GitHub od czasu przejęcia przez Microsoft dodał możliwość tworzenia prywatnych projektów także na darmowych kontach. Skorzystaj z tej opcji. Jeżeli wykorzystujesz ten portal także jako przechowalnię swojego kodu to postaraj się żeby kod, którego nie chcesz pokazywać nie był publiczny.

Ten punkt jest o tyle istotny, że nawet jak w CV umieścisz link do jednego projektu to rekruter prawdopodobnie zajrzy na cały profil. I jeżeli znajdzie tam masę projektów, które są tylko przepisanymi przykładami z książki albo są tak naprawdę jakimiś losowymi plikami bez konkretnej struktury to już wyrobi sobie jakąś opinię. Pierwsze wrażenie będzie nadszarpnięte. O doborze projektów piszę niżej. Tutaj zapamiętaj, że jak ktoś otwiera Twój profil to powinien tam zobaczyć tylko to czym chcesz się pochwalić. To co uważasz za najlepsze albo godne uwagi.

Więc spróbuj się postawić w roli osoby oceniającej i zobacz wszystkie publiczne projekty. Jaki obraz Twojej osoby się z nich wyłania?

Opisz cokolwiek

W porządku, masz wybrany projekt. Kod jest fajnej jakości. Chcesz się nim pochwalić bo uważasz, że sprzeda Twoją wiedzę. Tylko teraz jakiś developer wchodzi na ten link w CV, klika w projekt i co widzi? Zawartość pliku README.md z tytułem?

W jaki sposób może w tym momencie dowiedzieć się za co ta aplikacja odpowiada? Jaki problem rozwiązuje? Co motywowało Cię do jej napisania?

Z samego przeglądania kodu, jeżeli w ogóle poświęciłby na to więcej czasu, nie dostanie tych wszystkich informacji. Bo kod to kod, tu klasa, tam metoda. Nawet jeżeli nazwy są sensowne to nadal nie ma informacji o kontekście.

Przykład treści pliku README.md w jednym z moich repozytoriów

Może napisałeś ten projekt bo chciałeś się nauczyć konfigurować buildy? I samego kodu nie ma dużo ale istotna jest konfiguracja i na nią warto od razu spojrzeć? A może chciałeś jakieś wzorce projektowe przetestować w praktyce? Jakie? Dlaczego?

Nawet kilka zdań dających odpowiedź na takie pytania będzie bardzo cenne. Od razu pokaże osobie oceniającej, że wiesz dlaczego coś robisz. A ponieważ teraz można edytować na GitHubie plik README nawet nie znając składni Markdown to co Cię powstrzymuje przed zrobieniem tego i ułatwieniem oceny osobie po drugiej stronie?

Nie wszystko naraz

Rozwijanie projektu wymaga czasu. Nawet jeżeli jest to mały projekt to nadal jego powstanie zajmie przynajmniej kilka lub kilkanaście dni. W tym czasie podejmujesz jakieś decyzje. Skoro się uczysz programowania to też na pewno pewne pomysły, które wydawały Ci się początkowo słuszne okazują się nietrafione. Albo zaczynasz dodawać kolejne elementy, które poznajesz.

I skoro wraz z poszerzaniem wiedzy ewoluuje też projekt to warto mieć to udokumentowane. A dobrą dokumentacją takiego procesu są po prostu commity.

Dodatkowo robienie regularnych commitów pokazuje dwie rzeczy – że regularnie coś dłubiesz w projekcie i że faktycznie pracujesz z Gitem. A bardzo łatwo jest tą regularność zweryfikować bo GitHub wyświetla w profilu taki fajny diagram aktywności:

I patrząc na niego od razu widać czy dana osoba po prostu utworzyła repozytorium, wrzucała tam wszystkie pliki i zostawiła kod na wieczne zapomnienie. Nie trzeba nawet przeglądać historii samego projektu.

Więc zamiast dodawać w ostatniej chwili jeden wielki commit „bo trzeba mieć repozytorium na GitHubie” to lepiej jest od razu zacząć przygodę z Gitem i tą swoją historię rozwoju archiwizować w postaci małych, regularnych commitów. Bo w pracy i tak będziesz to musiał robić.

Oczywiście są sytuacje kiedy mieliśmy projekt, który robiliśmy zanim poznaliśmy Gita. Jednak w takim wypadku po pierwsze warto o tym napisać w README, a po drugie jeśli jesteś na początku kariery to pewnie cały czas masz co w tym projekcie zmieniać. Bo jeśli jest już „martwy” albo „stabilny” to czy na pewno jest to projekt, którym chcesz się chwalić?

Nie zostawiaj śmieci

Po to korzystamy z systemu kontroli wersji, żeby w razie potrzeby móc wrócić do poprzedniego rozwiązania. Więc jeżeli w danym momencie uznajesz, że jakiś fragment jest niepotrzebny to go usuwaj. Nie zostawiaj w kodzie, który masz w publicznym repozytorium zakomentowanych połaci kodu. Bo to wygląda źle i sugeruje, że nie wiesz jak działa system kontroli wersji.

Inna sprawa to wszelkiego rodzaju niestosowne komentarze czy nazwy zmiennych. Może i w trakcie testowania czegoś dodasz w ferworze walki wypisywanie „dupa” na ekranie, ale niech to pozostanie tylko na Twoim komputerze, a najlepiej zniknie od razu. Każdemu z nas zdarza się skorzystać z takich „wstawek” tak samo jak każdemu może się zdarzyć, nawet w pracy, wrzucić je do kodu aplikacji. Jednak tak jak już powtarzałem – Twój profil na GitHubie to Twoja wizytówka. I tak samo jak nie wysyłasz maila z CV z adresu dupa_blada@emails.com tak samo nie powinieneś takich zwrotów zostawiać w kodzie, który udostępniasz.

A na koniec tego punktu dodam o pozbywaniu się również nieużywanych fragmentów kodu albo plików, które już nie są potrzebne. Po co mają wprowadzać zamieszanie w projekcie. Po to masz system kontroli wersji, żeby w razie potrzeby wrócić do czegoś co jednak Ci się przyda.

Dbaj o jakość

Sądzę, że ten punkt powinien być oczywisty. Ale na wszelki wypadek go tutaj umieszczam i opisuję.

Skoro repozytorium ma być naszą wizytówką to i projekt w nim zawarty takim powinien być. A nie ma lepszej wizytówki dla programisty, zwłaszcza początkującego, niż kod dobrej jakości. I nie chodzi tutaj nawet o stosowanie wymyślnych wzorców czy skomplikowanej struktury. Wystarczy, że zadbasz o tak podstawowe rzeczy jak formatowanie kodu i przemyślane nazwy.

Pozbądź się nadmiaru pustych linii, zachował spójne formatowanie i wybierz jeden język do nazywania klas, zmiennych i funkcji. Tyle na początek wystarczy. Bo struktury kodu dopiero się uczysz. Wzorce poznajesz i one będą. Ale robienie wcięć w kodzie i wymyślenie słów lepiej opisujących co trzymasz w zmiennej to nie są kompetencje, które powinny Cię przerastać. A to one bardzo mocno ujawniają Twój stosunek do pisania kodu i dbałości o to co robisz.

Jak chcesz poznać tajniki pisania lepszej jakości kodu to polecam Ci chociażby książkę „Czysty kod” od R. Martina.

Pisz sensowne wiadomości

Na koniec coś co może wydawać się nieistotne ale dla osób, które chcą Cię zatrudnić może dać jakiś obraz Ciebie. Chodzi mianowicie o treść wiadomości w commitach. O ile wybór tego czy piszesz je po polsku czy angielsku nie jest na tym etapie istotny (chociaż lepiej po angielsku, chociażby dla poćwiczenia) tak zachowanie spójności (czyli zdecydowanie się na jeden język i schemat opisywania) jest istotne. Tak samo, albo i bardziej istotne jest unikanie wiadomości typu „fix”, „coś”, „kod”.

Jeśli zmieniłeś coś w kodzie to zrobiłeś to z jakiegoś powodu. A skoro tak to napisz z jakiego i po co.

Dobór projektu

Jeżeli chodzi o dobór projektu to mamy przede wszystkim dwa podziały – ze względu na wielkość i ze względu na poziom techniczny.

Duży to nie zawsze lepszy

Jeżeli chodzi o wielkość to tutaj moim zdaniem dobrze sprawdzi się na początek zasada, że lepszy projekt ukończony niż duży. Jako pojedynczemu programiście, w dodatku bez większego doświadczenie ciężko będzie rozwinąć i doprowadzić do sensownego stanu duży projekt. Napisanie własnej gry MMO być może brzmi super, ale może jednak warto zacząć od czegoś „odrobinę” mniejszego. Tym bardziej, że im większy projekt tym większa szansa, że zrobisz coś źle albo wybierzesz rozwiązania, które nie będą mile widziane. Duży projekt wymaga dużo planowania i nawet doświadczone osoby zwykle mają problem utrzymać go na w miarę wysokim poziomie.

Tak więc na projekty do portfolio warto wziąć takie, które mają szansę być ukończone. Bo nie dość, że łatwiej będzie coś o nich napisać to jeszcze sam więcej z nich wyniesiesz. Robiąc zbyt duży projekt prawdopodobnie utkniesz na jakimś jego mikroskopijnym fragmencie. I przez to nie nabierzesz doświadczenia w składaniu całości tak żeby działała. Poza tym mniejszy projekt to większa kontrola nad nim. I łatwiejsze zadbanie o jakość każdego kawałka.

Jednak nie przesadź też w drugą stronę. Projekt powinien być jednak wyzwaniem. Jeżeli cały kod możesz napisać przepisując fragmenty z książki albo od razu wiedząc jak wszystko napisać to znak, że projekt jest za mały. Postaw przed sobą wyzwanie, które wymaga poszukania jakiejś informacji (np. nie wiesz jak zapisuje się pliki więc zrób projekt gdzie po wykonaniu obliczeń są one zapisywane do pliku) albo wymaga zastosowania wiedzy, którą poznawałeś w kawałkach (np. uczyłeś się osobno o pętlach, warunkach, obsłudze wyjątków itd.) całościowo. Więc wymyśl projekt, który będzie potrzebował wielu elementów, które przerobiłeś.

No i na koniec istotna rzecz: satysfakcja z ukończenia czegoś na pewno doda Ci pewności w dalszej nauce ;)

Technologiczny postęp

Pod względem technicznym nie dodam tutaj zbyt wiele. Tak samo jak w przypadku wielkości projektu – znaj umiar. Jeśli dopiero co poznałeś język programowania to nie zaczynaj od projektu, który będzie stosował 2 frameworki i 15 bibliotek. Bo w ten sposób nie pokażesz, że umiesz je wszystkie. Efekt raczej będzie odwrotny. Przez to, że będziesz miał tyle rzeczy naokoło to zaginie w kodzie Twój faktyczny wkład i skończy się na tym, że jedyne co pokażesz to to, że umiesz wywoływać funkcje z zewnętrznych bibliotek.

Lepiej wybrać jedną dodatkową zależność, np. bibliotekę do zapisywania obrazków i zbudować aplikację, która tylko ją będzie wykorzystywać obudowując logiką napisaną „Twoimi słowami” (za pomocą Twojego kodu). Potem, wraz z poszerzaniem wiedzy możesz dokładać kolejne klocki. I np. do tej biblioteki dołożyć opcję pobierania obrazków w internetu. W ten sposób dodatkowo załatwisz sobie regularne zmiany w projekcie, o których pisałem wyżej.

Podsumowanie

Zbierając to wszystko w całość można powiedzieć, że Twoje repozytorium na GitHubie, które będziesz nazywał „portfolio” powinno zawierać tylko to co uważasz za najlepszy obraz Ciebie. Skup się na jakości, a nie ilości. Bo jeden porządnie prowadzony projekt będzie lepszą wizytówką niż dziesiątki niechlujnie napisanych i niedokończonych projekcików.

Na duże i skomplikowane technicznie wyzwania przyjdzie jeszcze pora. Na początek udowodnij przed osobami po drugiej stronie i przed samym sobą, że potrafisz poruszać się wśród podstaw i fundamentów pisania kodu. I tym dowodem niech będzie kod, który udostępniasz.

Nawet jeżeli nie wszyscy rekrutujący mają zwyczaj przeglądania profilów na GitHubie, do których linki są w opisie to zbudowanie takiego da Ci same korzyści. Nauczysz się umiejętności przydatnych w pracy, a jeżeli będziesz chciał z kimś porozmawiać o tym co robisz to po prostu wyślesz mu link do Twojego projektu na GitHubie.

Dodatkowo repozytorium tam umieszczone to całkiem niezły backup naszej pracy. W razie awarii nie stracisz tego co pisałeś przez ostatnie miesiące ;)

Powodzenia!