Jak wybrać odpowiednią technologię, narzędzia, czy framework?

Jak wybrać odpowiednią technologię, narzędzia, czy framework?

Jak wybrać odpowiednią technologię, narzędzia, czy framework?

Trafiłem ostatnio na nowy portal w sieci, który zmusił mnie do pewnej refleksji. Mianowicie myślę, że jedną z najcięższych decyzji przed jakimi możemy zostać postawieni to decyzja związana z wyborem odpowiedniej technologii, narzędzi, czy frameworków, przy użyciu których będziemy realizować dany projekt. Oczywiście takich decyzji nie podejmuje się każdego dnia i zazwyczaj odpowiedzialni są za to architekci, czy ogólnie osoby z dużym doświadczeniem, jednak sam, w mojej wcale nie tak długiej karierze, musiałem dokonać tego wyboru już co najmniej 2-3 razy.

W idealnym świecie (i podobno niektórych firmach) taka decyzja jest wnikliwie analizowana i musi porządnie się „wygrzać” zanim ostatecznie zostanie zatwierdzona. W realiach jednak może okazać się, że nie ma sztabu ludzi, którzy zrobią to za nas. Zegar zaczął tykać, deadline się zbliża, budżet jest napięty i coś trzeba wybrać. Najbezpieczniej jest za bardzo się nie wychylać i brać to z czym mamy już doświadczenie. Problem pojawia się, gdy nasze doświadczenie w danym temacie nie jest zbyt duże, a przykładanie za każdym razem do różnych problemów tego samego rozwiązania może okazać się próbowaniem wkręcania śrubki za pomocą młotka. Warto również pomyśleć o poszerzaniu swoich horyzontów i nauce nowych rzeczy. Nie oznacza to oczywiście, że ma się to odbyć kosztem klienta – wszystko trzeba robić z głową.

Nie tylko nowe projekty

Mowa tutaj nie tylko o nowych projektach, gdzie musimy wybrać cały stack. Może się zdarzyć, że taka decyzja musi zostać podjęta w aktualnie rozwijanym projekcie. Liczba użytkowników zaczęła wzrastać? Nasze rozwiązanie przestaje dawać radę obsługiwać wszystkie żądania? Klient zażyczył sobie funkcjonalności, która wykracza poza ramy aktualnego systemu? Aktualna technologia zaczyna się starzeć? W takim momencie możliwe, że będzie trzeba siąść i przemyśleć sytuację w której się znajdujemy na nowo. Jednak, aby siąść do takich rozważań z konkretnymi pomysłami i propozycjami trzeba orientować się w rozwiązaniach dostępnych wokół nas. Oczywiście możemy pokusić się o autorskie rozwiązania, ale nawet w tym przypadku świadomość dostępnych na rynku technologii, narzędzi i frameworków na pewno nie zaszkodzi.

W jaki sposób zatem pogodzić fakt, że nie mamy jeszcze dużego doświadczenia w pracy z rozmaitymi narzędziami i technologiami, chcemy brać udział w rozważaniach na temat wyboru stosu technologicznego i mieć pewność, że dowieziemy projekt na czas?

Ciężki wybór

Wróćmy może jeszcze na moment do tytułowego wyboru i dlaczego jest on tak ważny i ciężki do podjęcia. Główny problem to uzależnienie od podjętej decyzji. Jeżeli wybierzemy dany framework frontendowy i zaczniemy opierając się na nim budować cały UI łatwo się domyślić, że im więcej czasu upłynie tym ciężej będzie się z tej decyzji wycofać. Nikt z nas nie chciałby dojść w pewnym momencie do ściany i w połowie czasu do deadline’u lub później rozważać konieczność przepisania wszystkiego od nowa.

Historia z życia wzięta

Niestety sam znalazłem się kiedyś w takiej sytuacji. Zaczynaliśmy nowy projekt. Początkowo mięliśmy szybko dostarczyć MVP, jednak miała to być baza pod dalszy rozwój, nie tylko prototyp, który pójdzie do kosza.

Wymaganiem był nowoczesny UI. Bootstrap na ten czas był już dość oklepany postanowiliśmy zatem skorzystać z świeżutkiego Angular Material. Początkowo było ok, klient zachwycony, jednak nadszedł w końcu czas na nowe funkcjonalności i w raz z nimi ogromny ból głowy, gdy okazało się, że zrobić coś customowego w Angular Material jest prawie nierealne. Dodatkowo pojawiło się wymaganie wsparcia przeglądarki IE (ok, może byliśmy zbyt naiwni nie zakładając tego od początku – nauczka na przyszłość). Okazało się, że wydajność Angular Material w tej przeglądarce jest niezbyt dobra, powiedziałbym nawet, że nie ma jej wcale.

To był moment, gdy zaczęło się robić ciepło w spodniach. Deadline się zbliża, a przed nami stoi zadanie uświadomienia naszego „product ownera”, że z tą wydajnością na IE nie mamy za bardzo co zrobić i chyba będziemy musieli przepiąć to wszystko na bootstrapa. Ogólnie słaba sytuacja. Na szczęście problem z wydajnością Angular Material na IE został już zgłoszony wcześniej na GitHubie i lada dzień wyszła nowa wersja, która uratowała nam tyłki.

Świadomie dobieraj technologie, narzędzia i frameworki, których użyjesz do realizacji projektu

Ok, co więc możemy zrobić, aby bardziej świadomie dobierać odpowiednie technologie, narzędzia i frameworki do projektów?

  1. Na pewno dobrze byłoby zbudować wstępne prototypy, ale nie zawsze jest na to czas.
  2. Dobrze byłoby mieć z 10 lat więcej doświadczenia, jednak świadomość czekania 10 lat zanim będę w stanie starać się o udział w podejmowania takich decyzji nie do końca mnie urządza.
  3. Z gotową książką na ten temat też się niestety nie spotkałem i wątpię, że coś takiego powstanie (aczkolwiek uważam, że ostatnie ebooki od MS zrobiły pierwszy krok w tą stronę).
  4. Z pewnością trzeba dobrze zaznajomić się ze specyfikacją projektu i wszystkie wątpliwości dogadać z klientem.
  5. Dobrym pomysłem jest również próba maksymalnego odseparowania naszej czystej logiki biznesowej od zewnętrznego kodu typu framework. W razie problemów takie podejście znacznie nam ułatwi przepięcie się na inne rozwiązanie.

Jednak myślę, że jest jeszcze inny, ważny punkt. Znajomość dostępnych rozwiązań na rynku, o której wspominałem wcześniej. W końcu jeżeli mamy coś wybrać to dobrze byłoby mieć z czego!

Korzystaj z doświadczenia i wiedzy innych

Skoro nie mamy swojego doświadczenia w danym temacie, może warto próbować korzystać z doświadczenia innych? W tym może pomóc portal, o którym wspomniałem we wstępie. Chodzi o StackShare.

Jeżeli nie miałeś jeszcze styczności z tą stroną, pozwól, że przestawię Ci pokrótce o co chodzi.

Generalnie StackShare służy do przedstawiania „stacków”, na których opierają swoja rozwiązania prawdziwe firmy. Nam developerom ma to pomóc w poznawaniu i wyborze nowych rozwiązań. Trzeba przyznać, że brzmi to ciekawie. Wyobraźmy sobie, że ktoś daje nam możliwość poznania w jaki sposób zrobiony jest StackOverflow, którego ruch to setki tysięcy wizyt każdego dnia. Jeżeli szukamy przykładu, jak robić dobry software to myślę, że jest to godny kandydat. StackShare daje nam właśnie taką możliwość.

Po kolei, co ciekawego znajdziemy na StackShare.

Trending

Czyli ranking topowych stacków i technologii – jeżeli chodzi o stacki, nie wiem w jaki sposób wyznaczają oni ten ranking patrząc na to, jak bardzo wymieszane są tam pozycje. Ogólnie jest to średnio przydatne. Jeżeli jednak chodzi o narzędzia to sytuacja jest znacznie ciekawsza. Widać, że rzeczy, które aktualnie są na topie w Internecie również się tam przewijają, także zawsze można podejrzeć, jak się ma sytuacja 🙂

Comparisons

Następnie ciekawa funkcja jaką są porównania. Wybieramy konkretne porównanie i otrzymujemy całkiem zgrabne zestawienie danych technologii/narzędzi/frameworków. Przy okazji wspomnę o profilach konkretnych technologii, które również możemy przeglądać. Minusem tych profili oraz całych porównań jest fakt, że oprócz ogólnych informacji wymienione są tylko plusy. Nie znajdziemy nigdzie informacji o ograniczeniach, co często bywa kluczowe.

Innym portalem, który pod tym względem jest lepszy jest Slant. Możemy zerknąć na zestawienie najlepszych frameworków frontendowych na portalu Slant. Jak widać ludzie raportują zarówno zalety danego frameworka, jak również ich wady. Problem ze Slantem jednak jest taki, że jest to portal o ogólnej tematyce, nie tylko IT i przynajmniej na razie tematy z zakresu IT nie są zbyt popularne.

Stacks

Robi się coraz ciekawiej. Tutaj znajdziemy profile firm wraz z przedstawionymi ich „stosami technologicznymi”. Na pewno warto sobie to poprzeglądać. Jak widać na poniższym screenie możemy tam znaleźć naprawdę topowe firmy, które dzielą się z nami w pewnym sensie swoją wiedzą i doświadczeniem.

Stories

Na koniec prawdziwa armata – Stories. Jeżeli miałbym wybrać najlepszą rzecz z całego portalu to właśnie byłyby to te historie. Znajdziemy tam opisy rozwiązań stosowanych przez firmy w formie blogowych postów. W odróżnieniu od wyżej wymienionych Stacków tutaj dostajemy pełen kontekst, wyczerpujący opis, schematy, kod – w skrócie w pełni opisane rozwiązanie. Historie dotyczą ogólnych opisów stosów technologicznych firm, ale też rozwiązań konkretnych problemów jak np. przejście z jednego rozwiązania na drugie.

Bądźmy świadomi

Kończąc – myślę, że jest to ciekawy (a na pewno lepszy niż żaden) sposób na budowanie swojej świadomości dostępnych na rynku narzędzi, technologii i frameworków. Co ważne, zapoznajemy się z tymi stackami w kontekście konkretnych firm i ich rozwiązań, co stanowi moim zdaniem największą wartość. Posiadanie takiej świadomości z pewnością pomoże nam w lepszym doborze stosu technologicznego do naszego projektu.

  • Ja myślę, że przede wszystkim narzedzia powinny wybierać osoby znajace bardzo dobrze czysty język, a nie tylko frameworki i biblioteki. Wiele razy spotkałem się z problemami, że czegoś nie ma bootstrap czy jQuery i co teraz… ano po prostu czysty js i css i tu zaczyna sie problem jak ktos nie zna czystego js i dobrze css…
    A co do samych narzedzi to niestety czasem jak termin jest krótki trzeba brac to co się zna, a ambicje o nauce nowwego odłożyć na później, klient chce działający produkt, a nie problemy w imie naszych ambicji. Chyba, że mamy pewien zapas czasu to faktycznie można sie rozwijać.

    • Adrian Bystrek

      Faktycznie znajomość czystego języka, z którym związany jest np. framework dużo daje, bo szybciej będziemy w stanie zrozumieć co się dzieje pod spodem. Z taką wiedzą znacznie prościej będzie nam podjąć prawidłową decyzję. Oczywiście uratuje to nas również w sytuacji którą przytoczyłeś.
      Co do ambicji – to prawda, że czasami (myślę, że nawet można powiedzieć, że w większości przypadków :P) trzeba je odłożyć na bok, ale to nie zawsze rozwiązuje problem. Tak, jak pisałem możemy stanąć przed problemem, do którego aktualnie znane przez nas rozwiązania nie do końca pasują no i wtedy trzeba wyjść poza to co znamy i w czym dobrze się czujemy.

  • Przemek Smyrdek

    Od siebie dodam, że warto pamiętać o skali danej firmy patrząc na jej stack technologiczny. Już wiele razy spotkałem się z przypadkiem, gdzie narzędzie które potocznie uważane jest za „przestarzałe” a które znam, było podstawą do sukcesu danego projektu – np. przez to, że było ono nieskomplikowane, łatwo było zbudować prototyp czy wersję którą można przedyskutować z klientem – ale dowiedzieć się tego można było dopiero pytając o to od czego dana firma zaczynała. Także jeśli narzędzie którym się posługujesz sprawdziło się w boju i np. nie ma już zbyt wielu min które mogą ci wybuchnąć w twarz (jak brak wsparcia dla IE w dawnych wersjach Angular Material) to po prostu trzeba je brać i działać – mało kto może sobie pozwolić na działy R&D których jedynym zajęciem jest testowaniem nowych zabawek.