Praktyczna Java: jak porównać i wybrać bibliotekę do projektu?

By 13 July 2016 Praktyczna Java

Dobór odpowied­nich tech­nologii może być wyzwaniem, w szczegól­noś­ci, gdy mają one rozwiązy­wać jak­iś ist­nieją­cy już prob­lem w naszym pro­jek­cie. Jak się do tego zabrać? Czym się kierować? Właśnie o tym będzie ten wpis! Przy­dat­ny, nie tylko dla Javowców!

0. Określ cel

Może to tru­izm, ale dodawanie bib­liote­ki, tylko dlat­ego, że była w poprzed­nim pro­jek­cie, albo korzys­tanie z tech­nologii X, bo jest ter­az mod­na, jest total­nie bez sen­su. Zas­tanów się więc, jaki prob­lem chcesz rozwiązać, a im szczegółowiej go opiszesz, tym lep­iej ( to pomoże również w pro­ce­sie wyszuki­wa­nia rozwiązania).

1. Wyszukaj dostępne rozwiązania

Zaczni­jmy od wikipedii, gdzie zna­j­du­je się wiele spisów tech­nologii, stosowanych do konkret­nych rzeczy. Wpisu­jąc więc frazę “Java XYZ frame­works” powin­naś dostać takową listę. Zna­jąc już kil­ka tech­nologii warto sprawdz­ić, czy nie moż­na czegoś do nich dodać — w tym celu w google wyszukaj hasła :“XYZ alter­na­tives”, na 99,9% dosta­niesz w wynikach link do Stack­Over­flow, gdzie ktoś już sporządz­ił porządne podsumowanie ;)

Jeśli jed­nak, nie za bard­zo wiesz, jaka bib­liote­ka może rozwiązać Twój prob­lem, a takie otwarte pode­jś­cie jest cza­sem lep­sze — to “po boże­mu” zacznij od wyszuka­nia rozwiązań Two­jego prob­le­mu (bo to wcale nie musi wyma­gać dodatkowej tech­nologii), a zna­jdziesz bib­liotekę, która może pomóc — po pros­tu powtórz wymienione wyżej kroki.

Może nasuwa Ci się pytanie, ale po co dodatkowe poszuki­wa­nia bib­liote­ki, sko­ro mam już tego jed­nego kandy­da­ta? Powiem tak, mam “tylko” 1,5 roku doświad­czenia w komer­cyjnym pro­gramowa­niu i nie raz miałam już sytu­acje w pro­jek­cie, gdy ktoś z zespołu rzu­cał nazwą fenom­e­nal­nej bib­liote­ki, którą trze­ba dodać do pro­jek­tu. Ta godz­i­na, czy dwie więcej poświecona na teo­re­ty­czne zapoz­nanie się z nią, a potem wyszukanie alter­natyw, ura­towało nas od niemałych prob­lemów lub poz­woliło znaleźć coś jeszcze lep­szego. Dlat­ego jestem zda­nia, że warto!

2. Kryteria oceny

Jeśli masz kil­ka bib­liotek, to najlepiej przyjrzeć się każdej z bliska, ale wiem, że np. bib­liotek do mapowa­nia w Javie jest kilka­naś­cie, w takim przy­pad­ku, warto “na bieżą­co” zawężać porówny­wany zbiór.
Infor­ma­c­je od twór­ców. Czer­piemy je ze strony www pro­jek­tu, GitHu­ba, JIRA, track­era bugów itp. Powin­niśmy móc sprawdzić:

  • kto jest jej twór­cą — czy to OS, czy ma wspar­cie jakiegoś gigan­ta IT?
  • ilość issues na track­erze (nie zawsze dużo znaczy źle, warto też patrzeć na to jak akty­wni sią twór­cy, jak dużo ich jest zamknię­tych, co planu­ją w następ­ny releasie)
  • kiedy ostat­ni commit
  • jak częs­to są nowe wersje
  • która to wer­s­ja bib­liote­ki (młody pro­jekt będzie miał małą społeczność wokół siebie, dojrza­ły, powinien być ok, stary, może okazać się tech­nologią, która jest już ‘niemod­na’, bo ma fajniejszego zastępcę
  • jak częs­to są nowe wer­sje ( znowu mamy tutaj infor­ma­cję o tym, jak żyje zespół dewelop­erów i czy pro­jekt jest prężnie rozwijany)
  • ile osób ją dewelop­u­je (jeśli jest tylko jeden główny dewelop­er jest duże ryzyko, że jego inne zaję­cia mogą koli­d­ować w pra­cach nad bib­lioteką, powodu­jąc jej obumarcie)
  • jak wyglą­da doku­men­tac­ja, jeden z ważniejszych ele­men­tów, bez dobrej doku­men­tacji może być ciężko w mniej try­wial­nych sytu­ac­jach. JavaDocs to min­i­mum! Fajnie, gdy twór­cy ofer­u­ją jakieś tuto­ri­ale czy get­ting start­ed, a jeszcze lep­iej, gdy po wpisa­niu w google’a dostaniemy całą masę porad­ników twor­zonych przez użytkowników
  • czy bib­liote­ka jest opar­ta o jakieś stan­dardy, czy korzys­ta ze współczes­nych technologii
  • jakość kodu — gdy pro­jekt jest na GitHu­bie warto trochę w niego zajrzeć — widzi­ałam już bib­liote­ki z klasa­mi na 1,5 tys lin­i­jek i meto­da­mi, które clean code’u nie widzi­ały ;) A po pros­tu wyry­wkowo kliknęłam sobie na kil­ka plików ;)
  • jak się ją sto­su­je, czy jest skom­p­likowana? tak, to też jest ważne, bo wyni­ka z tego jak łat­wo będzie Ci się w niej programować

Infor­ma­c­je od społeczności

  • ile jest wątków na Stack­Over­flow, i czy ludzie w internecie ją znają
  • jak bard­zo jest pop­u­lar­na na google trends
  • czy korzys­ta­ją z niej jakieś znane firmy/projekty — czy moż­na znaleźć przykład­owe uży­cie na GitHubie
  • czy ludzie nie mówią o tym rozwiąza­niu negaty­wnie, czy jest ono postrze­gane jako przy­jazne dla pro­gramisty i projektu
  • czy w Two­jej firmie/ wsród Twoich zna­jomych ktoś z nią próbował — jeśli tak, co o tej tech­nologii sądzi, czy by Ci ją polecił

Infor­ma­c­je od Two­jego projektu:

  • czy rozwiązu­je wszys­tkie prob­le­my, które macie
  • czy robi to w porząd­ny sposób
  • czy tech­nolo­gie, jakich doty­chczas używa­cie pozwala­ją na jej wyko­rzys­tanie? Jeśli nie to czy możli­we jest dopa­sowanie ich do wyma­gań biblioteki
  • czy koszt związany z wprowadze­niem wybranego rozwiąza­nia, jest możli­wy do poniesienia przez Twój pro­jekt (dopa­sowanie kodu, refak­tor, konieczność nauczenia zespołu nowego podejścia).

Takie zestaw­ie­nie najlepiej opra­cow­ać sobie w tabeli, z linka­mi, przykłada­mi kodu, tak, by później moż­na było łat­wo się odnieść.

3. Eliminacja

Po tak przy­go­towanej anal­izie, powinieneś mieć jednego/kilku moc­nych graczy, na który­mi warto się zas­tanow­ić i dokład­niej ich przeanal­i­zować. Jed­nak warto, byś nie robiła tego sama.

Fajnie, jeśli możesz zor­ga­ni­zować spotkanie w swoim zes­pole i przed­staw­ić przy­go­towaną wcześniej anal­izę. Im więcej osób spo­jrzy na nią, tym trafniejsza dla zespołu decyz­ja zapad­nie. Jeśli nie poproś jed­nego pro­gramistę o pomoc, podeślij mu wszys­tko i razem wyty­pu­j­cie faworyta.

Po takim wyty­powa­niu, warto jeszcze dokład­niej przeanal­i­zować “kosz­ty” doda­nia tej tech­nologii do Waszego pro­jek­tu: jak dzi­ała dana bib­liote­ka? jak wyglą­da kwes­t­ia wyda­jnoś­ci (np. może być opar­ta o reflek­sję i znacznie spowal­ni­ać Wasz pro­jekt, albo dłu­go się uruchami­ać, itp.), czy poradzi­cie sobie z nią i refak­torem? I czy macie na to czas w projekcie ;)

4. Proof of Concept

Rzecz, która częs­to jest pomi­jana, co może spowodować potem spore kosz­ty (szczegól­nie cza­sowe). Sprawdź­cie jak się jej uży­wa w prak­tyce, najlepiej, doda­jąc ją już do pro­jek­tu — czy są z tym jakieś prob­le­my? Czy wyma­ga to mnóst­wa niezbyt ele­ganck­iego (hehe, oj użyłabym tu innego wyraże­nia :P) kodu, czy współpracu­je ze Springiem (lub inną tech­nologią, której uży­wasz), a my potrafimy ją uru­chomić, zas­tosować, no i rozwiązać prob­lem, od którego to wszys­tko się zaczęło? Może warto przetestować w ten sposób 2 opc­je i wybrać ten, który bardziej Wam odpowiada?

W końcu, nie chce­cie dodać sobie tech­nologii, na którą będziecie kląć jak szewc przy każdym kole­jnym zadaniu ;)

Podsumowanie

Wybór bib­liote­ki to rzecz :“sim­ple, but not easy”, jed­nak warto poświę­cić dodatkowy czas i zro­bić to porząd­nie. Mam nadzieję, że opisane przeze mnie pode­jś­cie ułatwi Ci przy­go­towanie anal­izy narzędzi i dzię­ki niemu wybierze­cie coś, co pasu­je do Waszego zespołu.

Przykład­owe, bard­zo proste prezen­tac­je z porów­naniem bib­liotek, które przy­go­towywałam w swoim ostat­nim pro­jek­cie zna­jdziecie na moim slideShare’a: map­pery i flu­ent inter­fe­jsy dla sele­ni­um.

Miłego porówny­wa­nia technologi!!