Wpis ten będzie uzupełnieniem infografiki, którą możecie zobaczyć poniżej. Ostatnio jeden z naszych czytelników napisał do nas z pytaniem, co mógłby poprawić w swoim projekcie, zanim podeśle go jako swoje programistyczne portfolio w CV. W rezultacie zebraliśmy checklistę, którą powinnaś uwzględnić zawsze, gdy chwalisz się swoim kontem na githubie przed rekruterami. Gotowa?
Poniżej znajdziesz krótkie omówienie wspomnianych punktów.
Dodaj README
README.md to nic innego jak plik tekstowy, który dodaje się do projektu i, jak sama nazwa wskazuje, zachęca się do przeczytania go. W ogólnym przypadku powinny tam się znaleźć informacje na temat wszelkich wymagań jeśli chodzi o instalacje (np. Java, npm, mongo), a także instrukcja uruchomienia programu, czy korzystania z niego. Można również w nim zawrzeć opis konfiguracji np. ustawiono logowanie do pliku, albo aplikację można odpalić bez security korzystając z proflu ‘dev’ oraz z korzystając z profilu ‘prod’. Na potrzeby aplikacji, którą linkujecie w swoim CV można jednak ten plik rozszerzyć o dodatkowe punkty, a mianowicie:
- przedstawienie celu biznesowego aplikacji
- wytłumaczenie i przedstawienie zastosowanych technologii
- wypisanie i krótki opis zmian:
- w szczególności: co byś zrobiła inaczej i dlaczego
- czego brakuje (np. testy są zaimplementowane tylko jako showcase a nie w całej aplikacji
- co warto rozważyć w rozwoju aplikacji, jakie problemy mogą się pojawić, jak na nie odpowiesz
Mam nadzieję, że dostrzegasz naszą radę: zamiast poprawiać aplikację w nieskończoność, albo dopisywać kolejne jej elementy, po prostu opisz je w tym pliku! Tą radę weź sobie do serca również przy rozwiązywaniu zadań rekrutacyjnych! Dobrze podsumowane to co stworzyłeś, oraz opisane to, co można zrobić inaczej, zawsze robi dobre wrażenie, bo pokazuje, że nie tylko stworzyłeś kod, ale też pomyślałeś podczas jego pisania.
O tym, co powinna mieć minimalna aplikacja jeszcze napiszemy.
Nazewnictwo i dokumentacja
Zasada jest prosta i będzie odnosić się nie tylko do tego punktu: Twoja aplikacja ma pokazać, że znasz standardy, które obowiązują w branży.
Stąd poprawne nazewnictwo, standardowy layout folderów/pakietów w projekcie, a także samotłumaczące się nazwy to podstawa. Spójność również. Jeśli np. nazywasz foldery/pakiety w liczbie mnogiej, stosuj tą zasadę wszędzie! Jeśli dodajesz zwykłe komentarze do swojego kodu, bo uważasz, że są one potrzebne, bo metoda jest zbyt skomplikowana … postaraj się podzielić ją na mniejsze, z odpowiednimi nazwami. Jakie nazwy są dobre? Takie, które jednoznacznie tłumaczą co robisz.
Dokumentacja i JavaDocs’y to kolejny ważny punkt. Wiemy, że możecie przeczytać o podejściu, że dokumentacja kodu nie jest wymagana, bo kod powinien się zam tłumaczyć. I jak najbardziej zgoda, co do tej 2 części. Niemniej, wiele organizacji wymaga dodawania doców, więc po prostu w ramach ćwiczenia i pokazania, że wiesz o co chodzi, również je dodaj. Więcej o tym przeczytasz w naszym wpisie.
Dbanie o jakość kodu
Testy, testy i jeszcze raz testy! Super, gdy możesz się nimi pochwalić i pokazać, że naprawdę umiesz to robić. Nie musisz pokryć całego kodu (dopisz w readme, że dodałbyś ich więcej), ale pokaż, że wiesz jak testować kolejne warstwy swojej aplikacji, a także, że umiesz to robić skutecznie!
Po drugie logowanie. To znowu coś, co jest wymagane przez biznes, w produkcyjnych aplikacjach logi to rzecz niezbędna. Dlaczego? Bo dają nam historię akcji wykonanych w ramach naszej aplikacji, a więc pozwalają śledzić zachowanie użytkowników, a także wyłapać możliwe problemy. Dobrze więc dodać do Twojego projektu logi na poziomie INFO, a może i fajnie kilka tych developerskich na poziomie DEBUG. O tym po co i jak to zrobić przeczytasz tutaj: https://www.codeproject.com/Articles/42354/The-Art-of-Logging , a zestawienie javowych bibliotek do logowania znajdziesz na naszym blogu.
Po trzecie, statyczna analiza kodu. Po co? By wyłapać nieużywane fragmenty i błędy, które łatwo można poprawić. Jest do tego wiele narzędzi, my na blogu pisaliśmy o SonarQube, czy CheckStyle. Dodatkowo warto pomyśleć o PMD/CPD — kolejnych narzędziach do statycznej analizy kodu (nie tylko w Javie). To narzędzia, które warto znać, z których korzysta się na codzień — pierwszy projekt będzie więc fajną okazją do ich przetestowania.
Na koniec, trochę oczywistości
Projekt nigdy nie będzie idealny! Dlatego: 1) warto okroić jego funkcjonalności (jeden pełny CRUD wystarczy), 2) Jeśli widzisz usprawnienia, zastanów się czy nie wystarczy ich opisać, zamiast wprowadzać wszystkie w życie, 3) Czasem zamiast jednego ogromnego projektu warto mieć kilka, ale mniejszych!
Do swojego repozytorium możesz śmiało dorzucić małe programistyczne zadania, ale wtedy pokaż dokładnie czego się wtedy uczyłeś. Nawet proste zadanie, może pokazać, że np. wiesz co to testowanie, albo, że znasz wyrażenia lambda i strumienie w Javie. Pamiętaj jednak, że wszystko, co dodajesz do swojego oficjalnego portfolio może być użyte przeciwko tobie. Niedopracowane projekty warto ukryć!
Jeśli używasz gita, pokaż, że umiesz to robić. Commituj często, z dobrymi, wartościowymi commit messages, a może nawet spróbuj skorzystać z git-flow i twórz feature branche? To super okazja, by pochwalić się znajomością tego narzędzia!
Tyle od nas mamy nadzieję, że nasze rady okażą się pomocne! A wszystkich starszych stażem prosimy o dodawanie kolejnych wskazówek, niech nasi początkujący czytelnicy skorzystają jeszcze bardziej!
