#Niezbędnik Juniora. Dobre praktyki dla początkującego programisty

Są rzeczy, które już od samego początku two­jej przy­gody z pro­gramowaniem w Javie powinieneś wiedzieć. Pod­stawy to na pewno fun­da­men­ty pro­gramowa­nia obiek­towego, częs­to opisy­wane pod akro­n­imem SOLID. W dzisiejszym wpisie zebral­iśmy dobre prak­ty­ki, które z naszej strony uważamy za najważniejsze i krótko je opisal­iśmy. Zaprasza­my do zapoz­na­nia się z nimi.

SOLID to akro­n­im od:
S – Sin­gle-respon­si­b­li­ty principle
O – Open-closed principle
L – Liskov sub­sti­tu­tion principle
I – Inter­face seg­re­ga­tion principle
D – Depen­den­cy Inver­sion Principle

Więcej o każdym z tych ele­men­tów zna­jdziesz tutaj. — dzisi­aj skupimy się jed­nak przede wszys­tkim na praktyce.

0.Nazewnictwo

Po pier­wsze, kod pisze­my po ang­iel­sku (na naszym blogu wrzu­camy kod w języku pol­skim, po to, by było by go łatwiej zrozu­mieć początku­ją­cym) — jed­nak cały świat pro­gra­mu­je po ang­iel­sku (* — z mały­mi wyjątka­mi, ale nie są to najlep­sze prak­ty­ki, np. w pro­jek­tach rzą­dowych częs­to wyma­gane jest pol­skie nazewnict­wo). Nazwy zmi­en­nych tworzymy od rzec­zown­ików licz­by poje­dynczej, nazwy metod to po pros­tu odpowied­nie cza­sown­i­ki :) Pamię­taj, by nazwy twoich zmi­en­nych były specy­ficzne i jednoznaczne.

Jeśli chodzi o Javę zasady nazewnict­wa zna­jdziecie w tej tabeli:

class Raster;
class ImageSprite;

run();
runFast();
getBackground();

int i;
String surname;
float myWidth;

static final int MAX_PARTICIPANTS = 10;

pl.kobietydokodu.kursjavy

Nasz czytel­nik, Piotr (zerknij na komen­tarz poniżej!) pro­ponu­je dodatkowe reguły, z który­mi całkowicie się zgadzamy:

W zależnoś­ci od typu zwracanego, nazwy metod różnią się między sobą:

• dla metod void — nazwą jest po pros­tu cza­sown­ik (np. ‘run’, ‘init’, ‘exe­cute­Work­flow’ itp)
• dla metod zwraca­ją­cych wartość boolean, uży­wamy pre­fik­sów is*, has*, can* (np.: ‘isValid’, ‘can­Han­dle’, ‘hasChil­dren’ itp)¹
• dla metod zwraca­ją­cych określony typ obiek­tu — rzec­zown­ik (typ obiek­tu) lub getRzec­zown­ik (get­Ty­pO­biek­tu) (np. ‘getN­ode’, ‘getEle­ment’, ‘ele­ments’, ‘node’ itp)

Co bard­zo ważne — jeśli nazwa metody jest cza­sown­ikiem (z wyłącze­niem pre­fik­sów ‘is’, ‘has’, ‘can’, oraz ‘get’), to meto­da nie powin­na nigdy niczego zwracać (czyli być po pros­tu operacją).

¹⁾ Ofic­jal­na kon­wenc­ja Javy mówi, że w przy­pad­ku metod zwraca­ją­cych boolean (prymi­tyw) należy stosować prze­drostek ‘is’, nato­mi­ast w przy­pad­ku metod zwraca­ją­cych Boolean (obiekt) — prze­drostek ‘get’. Wyni­ka to z fak­tu, że meto­da zwraca­ją­ca obiekt w teorii może także zwró­cić wartość null — sugeru­jąc się nazwą, nie sposób określić co ta wartość oznacza (to tak, jak­by na pytanie ‘czy jesteś człowiekiem’ nic nie odpowiedzieć). Ta kon­wenc­ja jest częstym przed­miotem sporów i dyskusji, jest jed­nak częś­cią ofic­jal­nej doku­men­tacji języka.

1. Spójność jest ważniejsza od poprawności (ogólnie)

Lep­szy spójny kod w pro­jek­cie, niż część kodu, która jest zgo­da z ogól­nie przyję­ty­mi zasada­mi. Dlaczego? Odsyłam Cię do cytatu z początku tek­stu. Twój kod nie jest na tu i ter­az, ktoś kiedyś go po Tobie prze­jmie, ktoś będzie musi­ał zrozu­mieć o co w nim chodzi, umieć go zde­bu­gować, utrzy­mać i rozwi­jać. Dlat­ego lep­sza spój­na całość, niż 1001 pomysłów zaczy­nanych i porzu­canych po drodze. Stąd raz na jak­iś czas warto sprawdz­ić, czy nie należy zro­bić refak­toru, i wtedy jak najbardziej jest miejsce na popraw­ian­ie. Całości.

2. Trzymanie się ustalonej architektury

Spój­na architek­tu­ra również ułatwia rozu­mie­nie aplikacji. Jeśli macie ustalone pewne zasady, trzy­ma­j­cie się ich.

Załóżmy, że macie klasy typu „Helper” – jeśli w jed­nej częś­ci aplikacji ich metody są staty­czny­mi meto­da­mi klasy, a w drugiej są udostęp­ni­ane w postaci ser­wisu Springa, to mamy bała­gan. Pomyślisz sobie, że prze­cież obie te rzeczy dzi­ała­ją, to po co się czepi­am? Zadam więc pytanie, dlaczego w jed­nym miejs­cu zas­tosowałeś to specy­ficzne pode­jś­cie i nie możesz w nim zas­tosować tego drugiego? Jeśli nie potrafisz odpowiedzieć na to pytanie, to oznacza, że to nie architek­tu­ra, a bałagan.

3. Dostosuj się do reguł w zespole

Bard­zo fajnie gdy od początku współpra­cy, twój zespół ustali pewne stan­dardy pra­cy. Wspól­ny for­mat­ter (albo cho­ci­aż decyz­ja tab­u­la­to­ry czy spac­je- my gło­su­je­my za spac­ja­mi!), określony schemat nazy­wa­nia branchy, com­mitów, to nie zbyt­nia for­mal­iza­c­ja, ale coś, co ułatwi Wam pracę. W szczegól­noś­ci, że narzędzia takie jak Jenk­ins, Jira itp mogą z takich reguł zro­bić użytek :)

Nic nie stoi na przeszkodzie, byś podzielił się swoi­mi pomysła­mi w tym zakre­sie, być może masz naprawdę fajny patent, który ułatwi Wam pracę. Ważne jed­nak, by mieć wspólne zasady, na które wszyscy się godzi­cie, i na który­mi każdy z członków zespołu czuwa (a wspier­ać dziel­nie może go np. check­style).

4. JavaDocs

Pisanie samotłu­maczącego się kodu to jed­no, doku­men­towanie go to drugie. O ile znaczące nazwy metod, zmi­en­nych, są Ci w stanie wytłu­maczyć lin­ij­ka po lin­i­jce co robi dany frag­ment kodu, o tyle doku­men­tac­ja pozwala na zrozu­mie­nie intencji znacznie szy­b­ciej. Pole­camy więc pisanie javadoców do Twoich klas, inter­fe­jsów i metod pub­licznych (o ile nie są one ogól­nie rozu­mi­any­mi konceptami).

Java doców nie należy mylić z komen­tarza­mi do kodu, jeśli musisz do każdej lin­ij­ki dopisać wytłu­macze­nie, to nie sto­su­jesz się do numeru zero naszego zestawienia.

5. Nie wymyślaj koła na nowo

Jed­ną z rzeczy, które od razy spodobały mi się pod­czas nau­ki pro­gramowa­nia to stan­dardy, na których moż­na pole­gać. Ba, nawet trze­ba. Jeśli coś jest dobrym, pole­canym, sprawd­zonym rozwiązaniem nie ma potrze­by by go nie stosować. Warto być też na bieżą­co. Jeśli masz pro­jekt w Javie 8, to do dat uży­waj api z Javy, a nie zewnętrznych bib­liotek (joda date time — jest świetne, ale dlat­ego, że gdy powstawało,cześć Javy do dat i cza­su stwarza­ła prob­le­my), czy właśnie wspom­ni­anej java.util.date. Zan­im stwierdzisz, ze napiszesz to sam, sprawdź 4 razy w internecie, czy to już nie ist­nieje. Oczy­wiś­cie, stworze­nie włas­nej bib­liote­ki może być zabawą, ale w pro­jek­cie liczy się czas, efek­ty i pewność, że rozwiązanie będzie sta­bilne i skuteczne.

6. Nie twórz świadomie długu technicznego

Jeśli pisząc kod myślisz sobie: ‘a to popraw­ię, jak będzie trochę więcej cza­su’, to właśnie zmarnowałeś go przy­na­jm­niej dwa razy więcej. Nie ist­nieje coś takiego jak pisanie kodu ‘na chwilę’ (*poza hot fix­a­mi na 30 min przed demo — ale tutaj mówimy o reg­u­larnej pra­cy devel­opera), w szczegól­noś­ci, jeśli dostrze­gasz, że Two­je rozwiązanie nie jest eleganckie/zgodne ze standardami/działające/zgodne z Twoim sum­ie­niem. Pod­sta­wowy prob­lem, z takim odkładaniem na później jest taki, że w pro­jek­cie rzad­ko kiedy jest czas na przeglą­danie ot tak kodu i ewen­tu­al­ny refak­tor. Ale może być jeszcze gorzej, możesz nie zdążyć zupełnie tego popraw­ić, możesz o tym zapom­nieć, albo uznać, że dzi­ałało pół roku, to prze­cież będzie dzi­ałać… Pomyśl o oso­bie, która pewnego pięknego dnia siądzie do Two­jego kodu i w najlep­szym razie złapie się za głowę, a w naj­gorszym nie będzie w stanie napraw­ić tego chwilowego rozwiązania.

Potrze­bu­jesz hot fixa? oznacz go jako //TODO i od razu wrzuć jako task do przyszłego sprintu. Nie pro­dukuj dodatkowego długu tech­nicznego, naprawdę go nie chcesz w swoim projekcie.

7. Dobrze się zastanów zanim dodasz nową i super modną bibliotekę

O wyborze bib­liotek pisal­iśmy już na blogu, więc tutaj najważniejszy wniosek — zawsze, ale to zawsze, miej uza­sad­nie­nie do zas­tosowa­nia tej konkret­nej tech­nologii. Uza­sad­nie­niem nie jest to, że jest mod­na, ani  że była w poprzed­nim pro­jek­cie, ani, że chcesz sobie ją wypróbować (to możesz zro­bić na boku, jako proof of con­cept). Upraszcza­jąc najlep­szym uza­sad­nie­niem jest to, że real­izu­je konkret­ną potrze­bę, której nie moż­na było zaspokoić z dostęp­nym stack­iem. Oczy­wiś­cie potrze­bą może być konkret­ny prob­lem biz­ne­sowy, efek­ty­wność pra­cy Two­jego zespołu, wyda­jność aplikacji itp.

Pamię­taj, że każ­da nowa technologia/tool/biblioteka to coś, z czym cały zespół będzie musi­ał się zapoz­nać, by móc stosować ją w swo­jej pra­cy. Waż­na jest więc też doku­men­tac­ja, tuto­ri­ale, opinie innych devel­op­erów. Warto zro­bić małą anal­izę i sprawdz­ić, czy nie jest to zbyt duże ryzyko do Two­jego projektu.

8. done, done, done

To określe­nie pochodzi ze Scru­ma a poszczególne ‘done’ oznaczają:

• kod napisany, czyli taki, który dzi­ała lokalnie (“u mnie działa”)
• kod przetestowany, za pomocą testów jed­nos­tkowych, a także integracyjnych
• kod zatwierd­zony, czyli taki, który został zatwierd­zony przez Prod­uct Own­era, jako real­izu­ją­cy konkret­ną potrze­bę biz­ne­sową wynika­jącą z zada­nia. Taki kod jest zmerdżowany do mas­tera i stanowi cześć naszego produktu.

Moż­na do tego dodać jeszcze jeden “done”, który będzie oznaczał pro­duk­cyjną gotowość, a więc doku­men­tac­je dla użytkown­i­ka, opra­cow­anie szkoleń z użytkowa­nia itp.

9. Staraj się tworzyć bezstanowe serwisy

Pomyśl, że ser­wisy to takie pio­n­ki w grze wiel­kich mafiozów. Jedyne co wiedzą, to co mają robić, nie wol­no im jed­nak pamię­tać, co robiły, ani zapamię­ty­wać szczegółów doty­czą­cych poszczegól­nych spraw. Po pros­tu dosta­ją zlece­nie, real­izu­ją je i czeka­ją na kolejne :)

Metody ser­wisów, mogą więc mody­fikować obiekt który dostały, mogą tworzyć i zwracać nowy, ale nie powin­ny w sobie prze­chowywać żad­nych infor­ma­cji w sobie. W razie przesłucha­nia, mają prze­cież nic nie wiedzieć ;)

10. Nie rzucaj nullami, ale …

W Javie 8 mamy cud­owne wrap­pery, czyli klasę Option­al, która pozwala nam nie robić ‘ulu­bionego’ przez wszys­t­kich sprawdzenia: if (object != null), więc prosimy Cię bard­zo, sto­suj je (a w Javie 7 lub niżej możesz po pros­tu przekazy­wać kolekc­je — pus­ta kolekc­ja nie da nam równie ‘ulu­bionego’ Null­Point­erEx­cep­tion, lub korzys­tać z bib­liotek takich jak Gua­va). Jest tylko jed­no ale… nie opakowuj za pomocą Option­ali kolekcji! Wyni­ka to z tego co napisałam powyżej, kolekc­ja może być pus­ta, więc np. Optional<Elements> (Ele­ments to lista ele­men­tów w bard­zo spry­t­nej bib­liotece do par­sowa­nia HTML — jsoup) nigdy, przenigdy nie będzie pusty.

Podsumowanie

Tak właśnie wyglą­da nasza lista 11 zasad, które warto sobie wpoić od początku. Takich prak­tyk jest pewnie znacznie więcej… Nie zrażaj się jed­nak, bo stan­dardy, to coś naprawdę ekstra. Mając je opanowane, nie musimy się martwić o sta­bil­ność naszego kodu, czy to jak napisać pewne rzeczy. Może­my skupić się na dostar­cze­niu wartoś­ci dla biznesu.

Od nas to tyle (przy­na­jm­niej na razie), ale prosimy naszych bardziej doświad­c­zonych czytel­ników, o podzie­le­nie się w komen­tarzach swoi­mi zasada­mi, tak byśmy mogli na bieżą­co uzu­peł­ni­ać ten wpis!

Rady od Was:

•  Lep­iej pra­cow­ać nad kodem godz­inę codzi­en­nie niż dwie godziny co dru­gi dzień. (Jarek)
  Wdrażanie się do kodu, zostaw­ionego, “roz­grze­banego zada­nia” zawsze zaj­mu­je trochę cza­su. Warto więc nie robić sobie prz­er­wy od pro­gramowa­nia, jeśli nie trze­ba i cho­ci­aż mniej, to pracować/uczyć się codzi­en­nie. W szczegól­noś­ci gdy jesteś na początku/uczysz się nowej tech­nologii, każ­da dłuższa prz­er­wa zmusi Cię do prze­r­o­bi­enia mate­ri­ału na nowo.