Przygotuj swój kod do portfolio

Wpis ten będzie uzu­pełnie­niem info­grafi­ki, którą może­cie zobaczyć poniżej. Ostat­nio jeden z naszych czytel­ników napisał do nas z pytaniem, co mógł­by popraw­ić w swoim pro­jek­cie, zan­im podeśle go jako swo­je  pro­gramisty­czne port­fo­lio w CV. W rezulta­cie zebral­iśmy check­listę, którą powin­naś uwzględ­nić zawsze, gdy chwal­isz się swoim kon­tem na githu­bie przed rekrutera­mi. Gotowa?

Poniżej zna­jdziesz krótkie omówie­nie wspom­ni­anych punk­tów.

Dodaj README

README.md to nic innego jak plik tek­stowy, który doda­je się do pro­jek­tu i, jak sama nazwa wskazu­je, zachę­ca się do przeczy­ta­nia go. W ogól­nym przy­pad­ku powin­ny tam się znaleźć infor­ma­c­je na tem­at wszel­kich wyma­gań jeśli chodzi o insta­lac­je (np. Java, npm, mon­go), a także instrukc­ja uru­chomienia pro­gra­mu, czy korzys­ta­nia z niego. Moż­na również w nim zawrzeć opis kon­fig­u­racji np. ustaw­iono logowanie do pliku, albo aplikację moż­na odpal­ić bez secu­ri­ty korzys­ta­jąc z proflu ‘dev’ oraz z korzys­ta­jąc z pro­filu ‘prod’. Na potrze­by aplikacji, którą linku­je­cie w swoim CV moż­na jed­nak ten plik rozsz­erzyć o dodatkowe punk­ty, a mianowicie:

  • przed­staw­ie­nie celu biz­ne­sowego aplikacji
  • wytłu­macze­nie i przed­staw­ie­nie zas­tosowanych tech­nologii
  • wyp­isanie i krót­ki opis zmi­an:
    • w szczegól­noś­ci: co byś zro­biła inaczej i dlaczego
    • czego braku­je (np. testy są zaim­ple­men­towane tylko jako show­case a nie w całej aplikacji
    • co warto rozważyć w roz­wo­ju aplikacji, jakie prob­le­my mogą się pojaw­ić, jak na nie odpowiesz

Mam nadzieję, że dostrze­gasz naszą radę: zami­ast popraw­iać aplikację w nieskońc­zoność, albo dopisy­wać kole­jne jej ele­men­ty, po pros­tu opisz je w tym pliku! Tą radę weź sobie do ser­ca również przy rozwiązy­wa­niu zadań rekru­ta­cyjnych! Dobrze pod­sumowane to co stworzyłeś, oraz opisane to, co moż­na zro­bić inaczej, zawsze robi dobre wraże­nie, bo pokazu­je, że nie tylko stworzyłeś kod, ale też pomyślałeś pod­czas jego pisa­nia.

O tym, co powin­na mieć min­i­mal­na aplikac­ja jeszcze napisze­my.

Nazewnictwo i dokumentacja

Zasa­da jest pros­ta i będzie odnosić się nie tylko do tego punk­tu: Two­ja aplikac­ja ma pokazać, że znasz stan­dardy, które obow­iązu­ją w branży.

Stąd poprawne nazewnict­wo, stan­dar­d­owy lay­out folderów/pakietów w pro­jek­cie, a także samotłu­maczące się nazwy to pod­stawa. Spójność również. Jeśli np. nazy­wasz foldery/pakiety w licz­bie mno­giej, sto­suj tą zasadę wszędzie! Jeśli doda­jesz zwykłe komen­tarze do swo­jego kodu, bo uważasz, że są one potrzeb­ne, bo meto­da jest zbyt skom­p­likowana … postaraj się podzielić ją na mniejsze, z odpowied­ni­mi nazwa­mi. Jakie nazwy są dobre? Takie, które jed­noz­nacznie tłu­maczą co robisz.

Doku­men­tac­ja i JavaDocs’y to kole­jny ważny punkt. Wiemy, że może­cie przeczy­tać o pode­jś­ciu, że doku­men­tac­ja kodu nie jest wyma­gana, bo kod powinien się zam tłu­maczyć. I jak najbardziej zgo­da, co do tej 2 częś­ci. Niem­niej, wiele orga­ni­za­cji wyma­ga dodawa­nia doców, więc po pros­tu w ramach ćwiczenia i pokaza­nia, że wiesz o co chodzi, również je dodaj. Więcej o tym przeczy­tasz w naszym wpisie.

Dbanie o jakość kodu

Testy, testy i jeszcze raz testy! Super, gdy możesz się nimi pochwal­ić 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ć kole­jne warst­wy swo­jej aplikacji, a także, że umiesz to robić skutecznie!

Po drugie logowanie. To znowu coś, co jest wyma­gane przez biznes, w pro­duk­cyjnych aplikac­jach logi to rzecz niezbęd­na. Dlaczego? Bo dają nam his­torię akcji wyko­nanych w ramach naszej aplikacji, a więc pozwala­ją śledz­ić zachowanie użytkown­ików, a także wyła­pać możli­we prob­le­my. Dobrze więc dodać do Two­jego pro­jek­tu logi na poziomie INFO, a może i fajnie kil­ka tych devel­op­er­s­kich na poziomie DEBUG. O tym po co i jak to zro­bić przeczy­tasz tutaj: https://www.codeproject.com/Articles/42354/The-Art-of-Logging , a zestaw­ie­nie javowych bib­liotek do logowa­nia zna­jdziesz na naszym blogu.

Po trze­cie, staty­cz­na anal­iza kodu. Po co? By wyła­pać nieuży­wane frag­men­ty i błędy, które łat­wo moż­na popraw­ić. Jest do tego wiele narzędzi, my na blogu pisal­iśmy o Sonar­Qube, czy Check­Style. Dodatkowo warto pomyśleć o PMD/CPD — kole­jnych narzędzi­ach do staty­cznej anal­izy kodu (nie tylko w Javie). To narzędzia, które warto znać, z których korzys­ta się na codzień — pier­wszy pro­jekt będzie więc fajną okazją do ich przetestowa­nia.

Na koniec, trochę oczywistości

Pro­jekt nigdy nie będzie ide­al­ny! Dlat­ego: 1) warto okroić jego funkcjon­al­noś­ci (jeden pełny CRUD wystar­czy), 2) Jeśli widzisz usprawnienia, zas­tanów się czy nie wystar­czy ich opisać, zami­ast wprowadzać wszys­tkie w życie, 3) Cza­sem zami­ast jed­nego ogrom­nego pro­jek­tu warto mieć kil­ka, ale mniejszych!

Do swo­jego repozy­to­ri­um możesz śmi­ało dorzu­cić małe pro­gramisty­czne zada­nia, ale wtedy pokaż dokład­nie czego się wtedy uczyłeś. Nawet proste zadanie, może pokazać, że np. wiesz co to testowanie, albo, że znasz wyraże­nia lamb­da i stru­mie­nie w Javie. Pamię­taj jed­nak, że wszys­tko, co doda­jesz do swo­jego ofic­jal­nego port­fo­lio może być użyte prze­ci­wko tobie. Niedo­pra­cow­ane pro­jek­ty warto ukryć!

Jeśli uży­wasz gita, pokaż, że umiesz to robić. Com­mi­tuj częs­to, z dobry­mi, wartoś­ciowy­mi com­mit mes­sages, a może nawet spróbuj sko­rzys­tać z git-flow i twórz fea­ture branche? To super okaz­ja, by pochwal­ić się zna­jo­moś­cią tego narzędzia!

Tyle od nas mamy nadzieję, że nasze rady okażą się pomoc­ne! A wszys­t­kich starszych stażem prosimy o dodawanie kole­jnych wskazówek, niech nasi początku­ją­cy czytel­ni­cy sko­rzys­ta­ją jeszcze bardziej!

  • 20
  •  
  •  
  •  
  •