Dobór odpowiednich technologii może być wyzwaniem, w szczególności, gdy mają one rozwiązywać jakiś istniejący już problem w naszym projekcie. Jak się do tego zabrać? Czym się kierować? Właśnie o tym będzie ten wpis! Przydatny, nie tylko dla Javowców!
0. Określ cel
Może to truizm, ale dodawanie biblioteki, tylko dlatego, że była w poprzednim projekcie, albo korzystanie z technologii X, bo jest teraz modna, jest totalnie bez sensu. Zastanów się więc, jaki problem chcesz rozwiązać, a im szczegółowiej go opiszesz, tym lepiej ( to pomoże również w procesie wyszukiwania rozwiązania).
1. Wyszukaj dostępne rozwiązania
Zacznijmy od wikipedii, gdzie znajduje się wiele spisów technologii, stosowanych do konkretnych rzeczy. Wpisując więc frazę “Java XYZ frameworks” powinnaś dostać takową listę. Znając już kilka technologii warto sprawdzić, czy nie można czegoś do nich dodać — w tym celu w google wyszukaj hasła :“XYZ alternatives”, na 99,9% dostaniesz w wynikach link do StackOverflow, gdzie ktoś już sporządził porządne podsumowanie ;)
Jeśli jednak, nie za bardzo wiesz, jaka biblioteka może rozwiązać Twój problem, a takie otwarte podejście jest czasem lepsze — to “po bożemu” zacznij od wyszukania rozwiązań Twojego problemu (bo to wcale nie musi wymagać dodatkowej technologii), a znajdziesz bibliotekę, która może pomóc — po prostu powtórz wymienione wyżej kroki.
Może nasuwa Ci się pytanie, ale po co dodatkowe poszukiwania biblioteki, skoro mam już tego jednego kandydata? Powiem tak, mam “tylko” 1,5 roku doświadczenia w komercyjnym programowaniu i nie raz miałam już sytuacje w projekcie, gdy ktoś z zespołu rzucał nazwą fenomenalnej biblioteki, którą trzeba dodać do projektu. Ta godzina, czy dwie więcej poświecona na teoretyczne zapoznanie się z nią, a potem wyszukanie alternatyw, uratowało nas od niemałych problemów lub pozwoliło znaleźć coś jeszcze lepszego. Dlatego jestem zdania, że warto!
2. Kryteria oceny
Jeśli masz kilka bibliotek, to najlepiej przyjrzeć się każdej z bliska, ale wiem, że np. bibliotek do mapowania w Javie jest kilkanaście, w takim przypadku, warto “na bieżąco” zawężać porównywany zbiór.
Informacje od twórców. Czerpiemy je ze strony www projektu, GitHuba, JIRA, trackera bugów itp. Powinniśmy móc sprawdzić:
- kto jest jej twórcą — czy to OS, czy ma wsparcie jakiegoś giganta IT?
- ilość issues na trackerze (nie zawsze dużo znaczy źle, warto też patrzeć na to jak aktywni sią twórcy, jak dużo ich jest zamkniętych, co planują w następny releasie)
- kiedy ostatni commit
- jak często są nowe wersje
- która to wersja biblioteki (młody projekt będzie miał małą społeczność wokół siebie, dojrzały, powinien być ok, stary, może okazać się technologią, która jest już ‘niemodna’, bo ma fajniejszego zastępcę
- jak często są nowe wersje ( znowu mamy tutaj informację o tym, jak żyje zespół deweloperów i czy projekt jest prężnie rozwijany)
- ile osób ją dewelopuje (jeśli jest tylko jeden główny deweloper jest duże ryzyko, że jego inne zajęcia mogą kolidować w pracach nad biblioteką, powodując jej obumarcie)
- jak wygląda dokumentacja, jeden z ważniejszych elementów, bez dobrej dokumentacji może być ciężko w mniej trywialnych sytuacjach. JavaDocs to minimum! Fajnie, gdy twórcy oferują jakieś tutoriale czy getting started, a jeszcze lepiej, gdy po wpisaniu w google’a dostaniemy całą masę poradników tworzonych przez użytkowników
- czy biblioteka jest oparta o jakieś standardy, czy korzysta ze współczesnych technologii
- jakość kodu — gdy projekt jest na GitHubie warto trochę w niego zajrzeć — widziałam już biblioteki z klasami na 1,5 tys linijek i metodami, które clean code’u nie widziały ;) A po prostu wyrywkowo kliknęłam sobie na kilka plików ;)
- jak się ją stosuje, czy jest skomplikowana? tak, to też jest ważne, bo wynika z tego jak łatwo będzie Ci się w niej programować
Informacje od społeczności
- ile jest wątków na StackOverflow, i czy ludzie w internecie ją znają
- jak bardzo jest popularna na google trends
- czy korzystają z niej jakieś znane firmy/projekty — czy można znaleźć przykładowe użycie na GitHubie
- czy ludzie nie mówią o tym rozwiązaniu negatywnie, czy jest ono postrzegane jako przyjazne dla programisty i projektu
- czy w Twojej firmie/ wsród Twoich znajomych ktoś z nią próbował — jeśli tak, co o tej technologii sądzi, czy by Ci ją polecił
Informacje od Twojego projektu:
- czy rozwiązuje wszystkie problemy, które macie
- czy robi to w porządny sposób
- czy technologie, jakich dotychczas używacie pozwalają na jej wykorzystanie? Jeśli nie to czy możliwe jest dopasowanie ich do wymagań biblioteki
- czy koszt związany z wprowadzeniem wybranego rozwiązania, jest możliwy do poniesienia przez Twój projekt (dopasowanie kodu, refaktor, konieczność nauczenia zespołu nowego podejścia).
Takie zestawienie najlepiej opracować sobie w tabeli, z linkami, przykładami kodu, tak, by później można było łatwo się odnieść.
3. Eliminacja
Po tak przygotowanej analizie, powinieneś mieć jednego/kilku mocnych graczy, na którymi warto się zastanowić i dokładniej ich przeanalizować. Jednak warto, byś nie robiła tego sama.
Fajnie, jeśli możesz zorganizować spotkanie w swoim zespole i przedstawić przygotowaną wcześniej analizę. Im więcej osób spojrzy na nią, tym trafniejsza dla zespołu decyzja zapadnie. Jeśli nie poproś jednego programistę o pomoc, podeślij mu wszystko i razem wytypujcie faworyta.
Po takim wytypowaniu, warto jeszcze dokładniej przeanalizować “koszty” dodania tej technologii do Waszego projektu: jak działa dana biblioteka? jak wygląda kwestia wydajności (np. może być oparta o refleksję i znacznie spowalniać Wasz projekt, albo długo się uruchamiać, itp.), czy poradzicie sobie z nią i refaktorem? I czy macie na to czas w projekcie ;)
4. Proof of Concept
Rzecz, która często jest pomijana, co może spowodować potem spore koszty (szczególnie czasowe). Sprawdźcie jak się jej używa w praktyce, najlepiej, dodając ją już do projektu — czy są z tym jakieś problemy? Czy wymaga to mnóstwa niezbyt eleganckiego (hehe, oj użyłabym tu innego wyrażenia :P) kodu, czy współpracuje ze Springiem (lub inną technologią, której używasz), a my potrafimy ją uruchomić, zastosować, no i rozwiązać problem, od którego to wszystko się zaczęło? Może warto przetestować w ten sposób 2 opcje i wybrać ten, który bardziej Wam odpowiada?
W końcu, nie chcecie dodać sobie technologii, na którą będziecie kląć jak szewc przy każdym kolejnym zadaniu ;)
Podsumowanie
Wybór biblioteki to rzecz :“simple, but not easy”, jednak warto poświęcić dodatkowy czas i zrobić to porządnie. Mam nadzieję, że opisane przeze mnie podejście ułatwi Ci przygotowanie analizy narzędzi i dzięki niemu wybierzecie coś, co pasuje do Waszego zespołu.
Przykładowe, bardzo proste prezentacje z porównaniem bibliotek, które przygotowywałam w swoim ostatnim projekcie znajdziecie na moim slideShare’a: mappery i fluent interfejsy dla selenium.
Miłego porównywania technologi!!