Wybór rozwiązań technicznych – co warto wziąć pod uwagę?

Temat może wydać się trywialny i oczywisty, jednak z mojego doświadczenia wynika, że chyba jednak nie do końca… Czy spotkaliście się kiedyś z systemami, w których użyte rozwiązania nie pozwalały (lub znacząco utrudniały) na wprowadzenie niektórych zmian wymaganych przez biznes? A może widzieliście na swojej drodze zawodowej systemy, które były zbyt skomplikowane (rozbudowane) jak na problem, który miały rozwiązywać?

Myślę, że na pewno tak. Ale czy zastanawialiście się, z czego może wynikać taki stan rzeczy? Przyczyn oczywiście może być kilka, jednak bardzo istotnym krokiem w każdym projekcie jest wybór rozwiązań, w jakich będzie on tworzony.

Z mojego doświadczenia wynika, że wśród programistów częstym argumentem wyboru danej biblioteki/frameworka jest:

• bo biblioteka jest nowa/popularna/fajnie będzie się jej nauczyć i wpisać sobie ją w CV,
• zbuduję system w oparciu jedynie o to, co znam i czego używałem przez ostatnie lata.

O tyle o ile w tych podejściach nie ma niczego złego (szczególnie w zastosowaniach prywatnych, gdzie celem może być nauka nowych rzeczy lub szybkie zbudowanie rozwiązania na chwilę), o tyle w projektach komercyjnych zdecydowanie nie wystarczą i nie powinny być jedynym kryterium wyboru danej technologii.

Pamiętajmy, że jako programiści/architekci jesteśmy inżynierami, osobami technicznymi, na decyzjach których opierają się nasi klienci/pracodawcy. Wybrane przez nas rozwiązania mają na celu przynieść im określone rezultaty, które z kolei ostatecznie (pośrednio lub bezpośrednio) przyczynią się do zysku finansowego naszego klienta (pracodawcy).

Dlatego właśnie, wybierając rozwiązania systemowe, warto wziąć pod uwagę kilka czynników:

1. Odpowiedni wybór do rozwiązania problemu

Technologie (biblioteki, frameworki, język programowania, itd.) to jedynie narzędzia, służące do rozwiązania konkretnego problemu.

Zgodnie z zasadą YAGNI (You aren’t gonna need it), powinniśmy upewnić się nie tylko, że nasz wybór umożliwi nam efektywną realizację zadania, ale również nie będzie przerostem formy nad treścią.

Oznacza to, że nie zawsze rozbudowane frameworki SPA, rozwiązania chmurowe czy mikroserwisy są idealnym wyborem. Rozwiązania te dają określone benefity, jednak użyte w aplikacji, która nie będzie czerpać z nich bezpośredniej korzyści, mogą znacząco zwiększyć próg wejścia do projektu nowych programistów lub zwiększyć koszty utrzymania naszych systemów.

2. Cena

Wybierając narzędzie powinniśmy przede wszystkim uwzględnić jego licencję oraz koszt.

Niektóre rozwiązania na pierwszy rzut oka mogą wydawać się idealne dla osiągnięcia pożądanego rozwiązania. Jednak opłaty licencyjne mogą okazać się blokerem dla budżetu naszego Klienta.

Dla przykładu:

Próbując zbudować rozwiązanie typu Log Management dla naszych systemów, możemy celować m.in. w takie rozwiązania jak ELK, GrayLog itp. Ich koszt jednak może znacząco się różnić w zależności od wolumenu danych, jaki chcemy za ich pomocą obsługiwać. Warto więc na samym początku przeanalizować koszty licencji aby w przyszłości uniknąć przykrej niespodzianki.

3. Technologia a pozyskanie zasobów (budowa zespołu)

To punkt, który przede wszystkim zainteresuje managera, jednak i o tym aspekcie powinniśmy pamiętać.

Praca programisty to przede wszystkim praca w zespole.

Będąc osobą wybierającą rozwiązania techniczne, dobrze jest pamiętać nie tylko o tym, że jeśli będziemy mieć zbyt stare rozwiązania (duży dług techniczny), to wprowadzanie nowych zmian może z czasem być coraz trudniejsze i zabierać więcej czasu. Do tego, niewielu programistów będzie zainteresowanych pracą przy naszych systemach. A jeśli będzie, to zapewne za większą stawkę, co spowoduje, że koszt utrzymania naszego systemu zwiększy się.

Podobnie sytuacja ma się z narzędziami nowymi lub mało popularnymi.

Jeśli będzie trudno znaleźć specjalistów od danej technologii, może okazać się, że musimy zapłacić więcej, by pozyskać taką osobę lub wyszkolić takiego specjalistę od podstaw. Co oznacza czas, a tym samym kolejny koszt.

Dla przykładu:

Wybierając framework SPA, o wiele łatwiej pozyskamy z rynku specjalistów od Angulara czy Reacta, niż np. Aurelii. Czasem jednak ryzyko może się opłacić i zostać przekute w zysk. Gdy wybrane przez nas (obecnie mało znane, jednak z potencjałem) rozwiązanie stanie się już mocno popularne (a może nawet stanie się standardem w świecie danego języka), my już będziemy posiadać specjalistów z doświadczeniem.

4. Wsparcie / społeczność

Który programista nie utknął w trakcie prac z nową biblioteką i nie szukał pomocy społeczności w takich serwisach jak StackOverflow, niechaj pierwszy rzuci kamieniem.

Przy dużej popularności danego narzędzia jest dużo większa szansa znalezienia odpowiedniej pomocy, kiedy napotkamy problem, z którym nie możemy sobie poradzić, a dokumentacja nie wystarcza. Możemy również konsultować pomysły z członkami danej społeczności, którzy mają większe doświadczenie w danej dziedzinie.

Duża społeczność wokół danego narzędzia zwiększa również prawdopodobieństwo, że będzie ono nadal rozwijane w przyszłości.

5. Alternatywy

By przekonać biznes do inwestycji w jakieś rozwiązanie (np. wykup licencji na użycie nowej biblioteki lub inwestycja w przepisanie części systemu), musimy potrafić przede wszystkim uzasadnić nasz wybór.

Warto w takim razie porównać wybraną przez nas technologię z jej alternatywami – zarówno tymi płatnymi, jak i darmowymi.

Oferty pracy z

Bardzo prostym przykładem mogą być biblioteki do wstrzykiwania zależności (dependency injection), gdzie do najpopularniejszych należą:

• Castle Windsor,
• Autofac,
• Unity,
• Ninject,
• Structure Map.

Teoretycznie służą do tego samego, ale w praktyce różnice między nimi mogą być duże – od ich możliwości zaczynając, na wydajności kończąc.

Znajomość rozwiązań alternatywnych i umiejętność porównania ich daje nam większą gwarancję odpowiedniego wyboru narzędzia do problemu, który chcemy rozwiązać.

6. Przyszłość danej technologii/biblioteki/frameworka

Trzymanie się znanych nam i sprawdzonych rozwiązań wydaje się oczywiście logiczne i bezpieczne.

Świat IT nie stoi jednak w miejscu. Wręcz przeciwnie, zmienia się bardzo szybko. Co chwilę powstają nowe biblioteki, frameworki, narzędzia, technologie. Jedną z cech dobrego programisty/inżyniera jest stałe śledzenie branży i bycie na bieżąco. Dzięki temu możemy dowiedzieć się, jaki jest planowany rozwój rozwiązania, w które celujemy, jak również poznać alternatywy i nowe możliwości.

Dla przykładu:

Czy dobrym pomysłem było rozpoczynanie nowych projektów budowanych na AngularJS (nawet mając specjalistów w tej dziedzinie), kiedy na rynku pojawił się już Angular 2, a Google zapowiedział zakończenie wsparcia tego pierwszego za jakiś czas?

7. Proof of Concept (PoC)

Wybierając narzędzie, którego nie jesteśmy pewni lub w którym nie mieliśmy dotychczas większego doświadczenia, warto poświęcić nieco czasu na przygotowanie Proof of Concept, czyli przykładowego projektu, którym potwierdzimy sobie, czy na pewno jest to odpowiedni wybór do rozwiązania danego problemu. Jest to swego rodzaju poligon doświadczalny, który może odpowiedzieć nam na wiele stawianych sobie na początku projektu pytań. Może się to wydać niepotrzebną pracą i kosztem, jednak uważam, że warto poświęcić trochę dla takiej formy refleksji na starcie zamiast później wychodzić z wybranej technologii, przepisywać całość lub część systemu itp.

Podsumowanie

Jak widać, przy wyborze technologii nie ma złotego środka. Nie możemy zawsze kierować się jedną zasadą podążania za najnowszymi technologiami, jak również nie możemy zostać w długu technicznym. Powinniśmy dobierać rozwiązania przede wszystkim odpowiednio dopasowane do problemu i pilnować, by jak najbardziej spełniały istotne w projekcie i w firmie kryteria. Czynniki, które wymieniłem, z pewnością ułatwią ten wybór, a być może nawet pomogą uniknąć kilku niepożądanych konsekwencji, które mogłyby objawić się dopiero po jakimś czasie.

Zdjęcia ilustrujące artykuł pochodzą z pexels.com.