Wstęp do odcinka

Podejmujesz decyzję o tym, aby napisać system dedykowany. I teraz powstają dwa pytania. Po pierwsze, albo w czym to napisać, albo drugie, czy wybrana przez zespół technologia jest właściwa. Wybór technologii to nie tylko kwestia w czym się najlepiej programuje, ale też realne sprawy dla biznesu. Koszty, łatwość utrzymania, czy też dostępność specjalistów. Dlatego warto podejść do tego racjonalnie i na spokojnie.Jestem osobą techniczną z zamiłowaniem do języka PHP i tego ukrywał nie będę, natomiast postaram się być jak najbardziej obiektywny w zakresie przedstawienia technologii w dzisiejszym odcinku. I cóż, będąc tym miłośnikiem PHP powinienem wam powiedzieć, że PHP jest zawsze najlepszy. I oczywiście w wielu przypadkach jest bardzo dobry, ale oczywiście też nie zawsze. Więc jeśli akurat stoisz przed wyborem języka programowania dla swojego projektu, przedstawię ci 7 nieoczywistych, ale bardzo ważnych biznesowo porad. Także zostań ze mną do końca tego odcinka. No i co, serdecznie cię zapraszam. Cześć, dzień dobry. Z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie.

7 porad dla biznesu przy wyborze języka programowania

Cześć, dzień dobry. Dzisiaj odcinek 66, czyli dedykowany system IT, w czym go napisać. No i temat nie jest raczej łatwy, jeżeli chodzi o podejmowanie decyzji, szczególnie jako osoba bardziej z biznesu, przedstawiciel bądź przedstawicielka biznesu. A bardzo często zdarza się, że osoby techniczne, czy to z działu IT, czy z zewnętrznego software house'u, proponują jakąś technologię i niewiele o niej wiedząc, mogąc tylko trochę pogooglować albo zapytać czata, musimy podjąć decyzję, czy ta technologia, z którą się zwiążemy na lata, faktycznie jest tego warta. Podpowiem, że tak jak Zbigniew i Zbyszek to te same imiona akurat, tak JavaScript i Java to jednak dwa różne języki programowania. Oczywiście pół żartem, pół serio. No i teraz, w jaki sposób podchodzić do technologii? Przedstawię wam takie 7 swoich opinii i porad zarazem, aby pomóc wam jako osobom z biznesu w podejmowaniu tego typu decyzji. 

Porada nr 1 – technologia a doświadczenie zespołu

Pierwsza rzecz. Dana firma lub zespół z reguły proponuje język, który bardzo dobrze zna, lub który, uwaga, bardzo dobrze chce poznać. Jeżeli to jest ten pierwszy przypadek, kiedy firma proponuje ci zwyczajnie język, który bardzo dobrze zna, trzeba upewnić się, że ten język faktycznie pasuje do rodzaju oprogramowania, jaki chcesz napisać, do funkcjonalności, jakie chcesz pokryć. Może się okazać, że zamówiowanie do języka będzie znacznie ważniejsze, niż to, jakie masz cele i co chcesz osiągnąć. I może się okazać, że ten konkretny język nie zawsze jest najlepszym wyborem. Drugi przypadek, kiedy dana firma chce bardzo poznać jakiś język, to jest coś, co trzeba też wykryć na etapie rozmów i na etapie negocjacji, po to, żeby, w cudzysłowie, nie wkopać się w moment, kiedy to my będziemy tym królikiem doświadczalnym jako przedstawiciele biznesu i to na naszym projekcie ktoś będzie się uczył tego, jak dana technologia działa, lub czy ona może faktycznie dany projekt pokryć. Jak to sprawdzić? Trzeba rozrysować sobie funkcjonalności i punkt po punkcie przejść przez to, w jaki sposób technicznie będzie to rozwiązane, napisane, jak będą wyglądały algorytmy, ale też, jak od strony kodu widzimy wydajności danego obszaru w tym kodzie, czy tutaj nie widzimy przeciwwskazań ze strony zespołu. Ważne jest to, żeby zaplanować na tym etapie dobrze architekturę całego systemu i rozwiązania, no i też tą wspomnianą roadmap'ę produktu i według tego krok po kroku z zespołem potwierdzić, jak dane rzeczy będą napisane w danym języku. I to pozwoli ocenić, czy dany język pozwala pokryć wszystkie wasze potrzeby, czyli na przykład, jeżeli jest jakaś funkcjonalność, która wymaga obsługi tak zwanego WebSocketa, czyli czegoś takiego, co sobie działa w tle i przesyła informacje z serwera do przeglądarki w dużym uproszczeniu, a nie na odwrót, jak to się dzieje zazwyczaj, to musimy mieć to potwierdzone, że dana technologia na przykład owe WebSockety obsługuje. A teraz skąd powinniśmy wiedzieć, czy tych WebSocketów potrzebujemy? To powinien ocenić architekt oprogramowania w ogóle budując architekturę właśnie, czy projekt architektury danego systemu. AbCD

Porada nr 2 – technologia a zasoby w firmie

Druga porada, jaka technologia jest używana w firmie kontra jakich masz specjalistów w firmie? To jest super istotna kwestia, żeby zastanowić się co do tego, z jakich języków programowania do tej pory korzystaliśmy w firmie, czyli jeżeli jakiekolwiek rozwiązania już w tej firmie były kiedykolwiek pisane jako rozwiązania dedykowane, to konkretnie w czym? I teraz, jeżeli to jest technologia raczej nowoczesna, czy jakiś nowoczesny język, to warto rozważyć wdrożenie nowych rozwiązań w tym konkretnym samym języku, dzięki czemu łatwiej będzie je wszystkie utrzymywać tym zespołem wewnętrznym, z którym współpracujemy do tej pory. Ale zdarza się też, że wewnętrzny zespół i tak nie będzie w stanie utrzymywać tych aplikacji, bo jest na przykład za mały albo ma tych aplikacji do utrzymania zwyczajnie za dużo, no i wtedy to jest moment, że można rozważyć dobór innego języka oprogramowania, organizując utrzymanie wraz z inną firmą. Mega ważne jest to, żeby po prostu nie uzależniać się od jednych i tych samych specjalistów z jednej strony, no ale z drugiej strony też nie wybrać technologii kompletnie innej niż ta, którą używamy, czyli na przykład mając w firmie PHP niekoniecznie wybierać technologię Node.js, jeżeli chcemy, żeby ci sami specjaliści utrzymywali daną aplikację, bo może się okazać, że ci od PHP zwyczajnie w świecie nie znają Node.js i będzie im to wszystko zajmowało więcej czasu i będzie dla nich znacznie trudniejsze. 

Porada nr 3 – więcej niż jeden język w projekcie

Porada numer trzy.Nie zawsze musisz wybierać jeden język programowania jako jedyny czy nawet jako wiodący. Generalnie jest tak, że jeżeli mamy architekturę aplikacji, to dzielimy ją z reguły na co najmniej backend i frontend, czyli tą część taką bardziej logiczną, która coś realizuje, taki bardziej mózg operacji i frontend, czyli bardziej coś, co widać, coś, co jest wizualne, czyli taka warstwa prezentacji. Już tutaj przy tylko tym podejściu możemy wyróżnić co najmniej dwie technologie osobną na backend i osobną na frontend, a możemy jeszcze wyróżnić na przykład trzecią, która będzie obsługiwała te wspomniane na przykład websockety. Ważne jest tutaj to takie trochę kreatywne, trochę otwarte podejście i przede wszystkim doświadczenie osoby doradzającej w doborze technologii, tak aby na przykład nie próbować gwoździa w cudzysłowie wbić deską zamiast młotka. Więc to trzeba wziąć pod uwagę, żeby nie zafiksować się mówiąc kolokwialnie na tym, że tylko jeden język programowania do wyboru. Może być tak, że różne funkcjonalności, różne potrzeby nasze biznesowe dobrze zmapowane w architekturze pokrywa się różnymi językami programowania i pisze się jako osobne tak zwane mikroserwisy.

Porada nr 4 – forma aplikacji przed językiem

Porada numer 4. Najpierw wybierz formę działania twojej aplikacji, a dopiero potem język programowania. Czyli generalnie powinniśmy się najpierw zastanowić, czy my chcemy uzyskać aplikację webową, czy lub także aplikację mobilną, czy lub także aplikację desktopową. Aplikacja webowa, czyli to co mamy dostępne w przeglądarce, aplikacja mobilna, czyli tą którą instalujemy na swoich smartfonach, aplikacja desktopowa, czyli taka którą instalujemy na swoich komputerach. I teraz co do zasady, nowoczesne rozwiązania raczej wybiera się webowe, lub webowe i mobilne. Rzadko kiedy już buduje się aplikacje desktopowe, chyba że są ku temu jakieś określone konkretne powody potrzeby, wtedy jak najbardziej. Teraz jeżeli już określimy jaki rodzaj aplikacji chcemy wykonać, bo czujemy, że na przykład taki rodzaj będzie w porządku, zastanawiamy się nad celami danej aplikacji, czyli kto będzie korzystał z aplikacji webowej, i dlaczego, i w jakich okolicznościach, a kto na przykład będzie korzystał z aplikacji mobilnej. I to jest też ciekawe, że osoby pracujące w terenie koniecznie muszą mieć aplikację mobilną, bo w aplikacji webowej bardzo często będą miały problemy z zasięgiem, czy z internetem i niekoniecznie ona będzie działała dobrze. Więc to jest właśnie to, że te cele i to kto będzie korzystał z danej aplikacji trzeba sobie dobrze pokryć i opisać. Funkcjonalności i obszary danej aplikacji, czyli właśnie jakie elementy tej aplikacji na przykład webowej muszą być obsługiwane w taki sposób, że gdzieś klikamy, coś się pojawia, a jakie na przykład elementy aplikacji webowej muszą się pojawiać na ekranie po prostu, w taki najprostszy sposób ujmując. I dopiero wtedy wybieramy jakieś języki programowania. Tutaj z takich najpopularniejszych, jeżeli chodzi o ten backend, o ten mózg operacji dla aplikacji webowych, czyli tych przeglądarkowych, można spokojnie wybrać na przykład PHP lub Node.js. Jeżeli chodzi o frontend, czyli tą warstwę prezentacji, można spokojnie wybrać React.js, Vue.js, albo na przykład Angular. Natomiast jeżeli chodzi o rozwiązania desktopowe, można spokojnie wybrać na przykład C Sharp lub Java, lub na przykład Node.js z odpowiednią biblioteką. To co ważne tutaj na tym etapie już wybierając jakiś konkretny język, to to czy my wybierzemy na tym etapie PHP czy Node.js, to nie do końca ma aż takie duże znaczenie samo w sobie, co bardziej biorąc pod uwagę wszystkie czynniki, o których mówię w dzisiejszym odcinku. Dlatego zostań ze mną, proszę, do końca. Warto tutaj skupić się na używaniu języków w najnowszych, dostępnych wersjach i to jest akurat porada uniwersalna. Taka przy okazji porady numer 4. 

Porada nr 5 – koszty i stawki programistów

Porada numer 5. Sprawdź stawki programistów w danej technologii. Myśląc o tym, że twoja aplikacja to nie jest coś, co ma zadziałać przez 3-4 miesiące i być wyłączone, tylko raczej być czymś, co będzie dla ciebie długoterminowym wsparciem, trzeba też pomyśleć o tzw. utrzymaniu tej aplikacji. No i teraz niezależnie, czy to utrzymanie będzie realizowane przez dany software house, który na przykład zbuduje taką aplikację, czy też przez zespół wewnętrzny, warto sprawdzić sobie średnie stawki wynagrodzeń programistów z danej technologii. Pamiętajcie, że napisanie danej funkcjonalności czasowo wbrew pozorom, jeżeli mamy specjalistę od PHP kontra specjalistę od Node.js, zajmie to mniej więcej podobną ilość czasu patrząc na rzędy wielkości. W sensie, jeżeli coś w PHP pisze się w kilka godzin, to w Node.js nie będzie się tego pisało nagle kilkanaście czy kilkadziesiąt roboczo godzin, porównując pracę specjalisty PHP i specjalisty Node.js. Bardzo mocno chciałbym na to zwrócić uwagę. Natomiast stawki tych programistów mogą być różne. I to trzeba akurat wziąć pod uwagę w kontekście właśnie doboru stawki i dostępność. Te dwie rzeczy, jeżeli chodzi o programistów, którzy mieliby potencjalnie zajmować się tą aplikacją w przyszłości. A to, że na przykład teraz planujemy utrzymanie z zespołem wewnętrznym, to nie zawsze tak będzie. Ani też utrzymanie z Software House'em też nie zawsze musi być długoterminowo jedyną dostępną opcją. Dlatego warto te stawki programistów nawet pod tym kątem sprawdzić.

Porada nr 6 – nie ulegaj stereotypom

Porada numer sześć. Nie ulegaj stereotypom wobec danego języka czy też nie ulegaj szerokiej opinii. To jest jedna z moich ulubionych porad i w ogóle obserwacji, że jeżeli zapytamy na przykład osobę, która pisze całe życie w C Sharpie, jaki jest najlepszy język programowania, no to nie uwierzycie, ale jest bardzo małe prawdopodobieństwo, że powie, że PHP. Co więcej, pewnie powie, że PHP to jest w ogóle stary język programowania i absolutnie nie warto się nawet nim zajmować, bo w tym to się pisze proste stronki, a ten C Sharp albo Java, tego używają korporacje, więc ty też przedsiębiorco z MŚP powinieneś używać Java. No otóż nie. To jest tak, że jednym z takich stereotypów, jaki na przykład usłyszałem jeszcze, to to, że napisanie aplikacji mobilnej właśnie w Java, czyli tak zwanie natywnie, bo aplikacja musi być bezpieczna i wydajna, to jest dobry pomysł. I teraz dla większości aplikacji biznesowych będzie działała ta aplikacja tak samo dobrze, gdy będzie napisana w React Native, czy na przykład w Eflaterze, jako też jednym z takich popularnych rozwiązań, bardzo podobnej czy tej samej klasy co React Native, czyli takie rozwiązanie, w ramach którego piszemy raz kod źródłowy w Javascript, ale potem możemy wygenerować od ręki aplikację na Androida i na iOS, to większość tych aplikacji będzie działała tak samo dobrze w React Native, czy w Eflaterze, będąc napisanym kontra, jakbyśmy napisali w Java pełni natywnie, tylko, że powstaną dwa razy szybciej, no czy co najmniej półtora raza szybciej. Generalnie będzie szybciej i w kontekście utrzymania dalszego też będzie szybciej, pracując oczywiście ze specjalistami z tych technologii. Teraz możecie zapytać, dlaczego to tak jest, że ktoś forsował koniecznie tą Java, no bo właśnie przed tym takim paradygmatem, że jeżeli z Java korzystają banki, to my też musimy w MŚP, co nie do końca jest tutaj prawdą i co więcej, szczególnie jeżeli to były aplikacje właśnie takie typowo biznesowe, gdzie jest po prostu kilka, kilkanaście różnych zakładek, jakiejś funkcjonalności i niekoniecznie sięgamy do rzeczy w telefonie dostępnych typu Bluetooth, typu jakieś takie rzeczy w pełni tzw. natywne, czyli właśnie te funkcjonalności, czy nawet rzeczy techniczne, takie hardware'owe z telefonu, to niekoniecznie musimy to pisać zawsze zupełnie od podstaw i tutaj będę mocno przy tym stał. Drugi z takich stereotypów to właśnie ten dotyczący języka PHP, że to stary język programowania. Uważam, że na dzisiaj PHP uzyskał swoją w pewnym sensie drugą młodość, bo jest to język, który został w 100% przepisany, znaczy napisany tak naprawdę od nowa, jeżeli chodzi o jego core i PHP w wersji ósmej na dzisiaj uważam, że jest bardzo bliski bycia takim językiem korporacyjnym i też nie boję się użyć tego sformułowania tutaj, przy czym jednocześnie jest językiem dużo tańszym niż języki korporacyjne typu Java. Kolejny stereotyp, C-sharp, który jest dobry dla aplikacji desktopowych, jak pisać aplikację desktopową, czyli tą taką właśnie dostępną na komputerze typowo, to tylko w C-sharpie, uważam, że jest jak najbardziej ok, co do tego celu, natomiast uważam, że jeżeli np. ma być on używany jako ten tzw. backend, czyli mózg operacji dla rozwiązań webowych, czyli tych dostępnych w przeglądarce, bo też może być, to jest to rozwiązanie droższe, bo jednak trochę bardziej czasochłonne, jeżeli chodzi o wszelkie kompilacje, uruchomienia niż np. właśnie wspomniany PHP czy Node.js, a nie dający w zamian żadnych korzyści przez to, że coś, co w nim mamy zrobić będzie zajmowało więcej czasu, czy będzie trochę bardziej skomplikowane. To też nie oznacza, że różnica jest kolosalna, że będzie w tym języku turbo trudniej coś zrobić, natomiast uważam, że mniej się on po prostu do tego nadaje względem np. właśnie tego wspomnianego PHP czy Node.js. I ostatni z takich stereotypów w ramach tego punktu, który sobie zapisałem, to taki, że jeżeli chcemy działać z AI-em czy z przetwarzaniem danych, to tylko używajmy Pythona. I teraz generalnie co do zasady jest tak, że faktycznie do Pythona jest masa bibliotek, rozszerzeń i w ogóle dostępnych rzeczy do tego, żeby z AI-em faktycznie pracować, czy wszelkie kwestie związane np. z machine learningiem, no to też ten Python generalnie jest wiodącą technologią i nie ma co do tego wątpliwości, ale pamiętajmy, że właśnie wychodząc od tego, co my chcemy osiągnąć z tym AI-em, może się okazać, że my zwyczajnie do aplikacji np. na PHP musimy dodać tylko jakąś bibliotekę do obsługi np. OpenAI i takie bardzo proste, rzekłby nawet wręcz prymitywne wdrożenie AI-a jesteśmy zwyczajnie w dowolnej technologii w stanie zrobić. Więc jeżeli nie robimy jakichś turboskomplikowanych aplikacji, jakichś agentów AI, którzy mają ogromny szereg zadań, to niekoniecznie to oznacza, że to zawsze trzeba zrobić w Pythonie i to chciałbym, żeby tutaj wybrzmiało. 

Porada nr 7 – skalowalność to architektura, nie tylko język

I porada numer 7. Skalowalność technologii nie zawsze zależy od wybranego języka programowania. Bardzo często wybór danego języka tłumaczy się tym, że będzie to skalowalna technologia, która będzie wspierała biznes na lata. I uważam, że od tego jaki język wybierzemy pod kątem skalowalności i wydajności, porównując tylko to, czy dany język jest mniej lub bardziej wydajny, to dużo ważniejsze jest to, jak zaplanujemy naszą architekturę, jak zaplanujemy np. komunikację z bazą danych, jak zaplanujemy np. pisanie kodu, aby był on czysty, czyli tą architekturę kodu i aby był on też zrozumiały, bo pamiętajmy, że kod piszemy raz, ale czytamy go wielokrotnie i tak samo np. z użytymi wzorcami programowania, jak np. DDD, czyli taki wzorzec, którym piszemy w pewien sposób tak, żeby jak najbardziej ten kod był zbliżony do realiów biznesowych, do tych procesów, jakie w ramach tego biznesu się dzieją, tak w dużym uproszczeniu, czyli zwracając uwagę właśnie na to, to tak samo można to napisać w PHP, jak i np. w C Sharpie. Kwestia, jak będzie zaplanowana architektura całościowa wszystkich rozwiązań, w ramach których działa nasza aplikacja czy aplikacje, jak będzie zaplanowana architektura kodu tego pojedynczego rozwiązania, czyli np. osobna architektura kodu aplikacji webowej, osobna aplikacji mobilnej i dopiero wtedy można kłócić się o milisekundy, czy szybszy będzie PHP, czy np. Node.js, ale podkreślam, że jeżeli będzie to dobrze zaplanowane na poziomie architektury rozwiązań i dobrze napisane faktycznie w danym języku, czyli mamy faktycznie specjalisty od danego języka, który umie używać też np. wzorców projektowych, to wybór tego kontra tego, porównując dwie technologie, które jednak od strony takiej, nie wiem, kwestii społeczności, kwestii dostępności specjalistów są podobne, nie będzie miało to aż takiego znaczenia. I teraz przechodząc powoli w stronę podsumowania, a jednocześnie żeby zostawić Was z takim miąskiem, a nie tylko z takim ogólnym podsumowaniem, chociaż uważam, że te właśnie siedem poprzednich punktów jest super istotne dla osoby, która nie siedzi w świecie technologii stricte, tylko bardziej podejmuje decyzje i w oparciu o coś musi ją podjąć.

Najważniejszy wniosek z odcinka

To uważam, że najważniejszy wniosek, z jakim chciałbym, żebyście wyszli z tego odcinka jest taki, że jeżeli będziemy mieli programisty znającego dany język, to on z pewnością zbuduje nam w tym języku tą daną aplikację dobrze, patrząc z strony technicznej. Upewnijmy się w takim wypadku, że cel biznesowy, czyli ta taka wizja końca jest znana temu programiście bądź programistom, czyli że on rozumie, co my chcemy osiągnąć, że my mu jak najwięcej opowiemy o tym, jak ten użytkownik będzie z tego naszego rozwiązania korzystał. Upewnijmy się, że ten programista też podejmuje decyzje ze wsparciem jakiegoś architekta bądź będąc samodzielnie w roli architekta, że on nie forsuje na siłę technologii, którą lubi, tylko że faktycznie on udowadnia i potwierdza, że ta dana technologia faktycznie jest OK dla tej wizji końca, którą chcesz osiągnąć. W ten sposób zwyczajnie ograniczymy te najpopularniejsze, takie największe ryzyka, które mogłyby się tu pojawić, czyli właśnie technologia niedopasowana do potrzeb, czy to, że ktoś forsuje na siłę, bo tylko ją zna, czy to, że zwyczajnie w świecie specjalistów od danej technologii byłoby super mało. 

Technologie warte uwagi – praktyczne podsumowanie

I teraz biorąc pod uwagę powyższe na podstawie moich doświadczeń i bardzo mocno to podkreślam, mogę powiedzieć, że technologie typu właśnie język PHP, o którym tutaj wspomniałem, że C Sharp, że Node.js to te technologie trzy uważam, że są generalnie bardzo dobre, jeżeli chodzi o stawianie tak zwanego back-endu, czyli tego mózgu operacji, tego, który odpowiada za tą logikę działania systemów. Jeżeli chodzi o tę warstwę prezentacji, front-end, frameworki typu React.js, Vue.js, Angular.js, czyli takie trzy najpopularniejsze frameworki javascriptowe do obsługi warstwy prezentacji. Każdy z nich ma swoje wady i zalety mniejsze lub większe, ale generalnie jeżeli mamy specjalistę od danej technologii, to każda z nich jest z mojej perspektywy tutaj równoważna. React Native i Flutter, jeżeli chodzi o aplikacje mobilne, to takie dwa rozwiązania, które faktycznie można tutaj polecić. Tutaj gorąco uczulam na to pisanie natywnie, zupełnie od podstaw aplikacji mobilnych. Zastanowiłbym się pięć razy nad tym, czy na pewno moja aplikacja jest na tyle faktycznie wymagająca, że trzeba ją faktycznie napisać zupełnie natywnie, bo wymaga tylu dostępności do funkcjonalności wybranego systemu, ma dużo połączeń z bluetoothem, z jakimiś urządzeniami zewnętrznymi itd. Ale nawet jeżeli tak jest, to przynajmniej jeszcze dodatkowo dwa razy bym się nad tym zastanowił, bo ten React Native czy Flutter można też rozbudowywać o komponenty natywne, czyli można napisać większość kodu w React Native, a taką mikro część kodu napisać za te rzeczy takie typowo natywne, odpowiadające dodatkowo. Więc to też trzeba wziąć tutaj pod uwagę. Aplikacji rodzaj czwarty, czyli aplikacje desktopowe, czyli te, które są dostępne na naszym komputerze, można napisać natywnie w C Sharpie, czy też np. w Javie. Można też napisać tak nazwijmy to pół natywnie w Node.js z wykorzystaniem dodatku typu np. ElectronJS. Natomiast to też jest kwestia do ustalenia jaka to jest dokładnie aplikacja desktopowa i co ona ma zawierać i na jakich systemach przede wszystkim też działać. To tutaj jest ważną, istotną kwestią. Możecie tutaj wysnuć też taki wniosek, myślę, że to mogło wybrzmieć, że to, że lubimy PHP to wiecie, ale to, że my go lubimy to nie oznacza, że on dla was będzie zawsze najlepszy. I to chciałem, żeby wybrzmiało i mam nadzieję, że tak jest. 

Rola Javascriptu jako uniwersalnego języka

Możecie też wysnuć wniosek, że np. Javascript jest dość uniwersalnym językiem. Ten wspomniany Javascript nie Java. No bo mamy na froncie ReactJS, VueJS, Angular wszystkie oparte o Javascript. Mamy Node.js, który może obsługiwać backend, czyli ten mózg operacji. Mamy Node.js i ElectronJS, które mogą tworzyć aplikację desktopową i tam też ten kod jest napisany w Javascript. No i mamy React Native albo Fluttera, w którym możemy stworzyć aplikację mobilną. I tutaj też ten codebase, czyli ta podstawa, w której programuje się w tych technologiach, to jest właśnie Javascript. I dokładnie tak jest, że struktura języka w pewnym sensie jest taka sama, więc znając Javascript można przyjąć założenie, że możemy pokryć totalnie wszystko w tym języku, więc on jest najlepszy, bo jest najbardziej uniwersalny. I teraz trzeba wziąć pod uwagę, że sposób organizacji kodu i jego pisania jest nieco inny względem tego, czy się pisze w React.js czy w Node.js na przykład. Także nie do końca tak jest, że znajdując jednego programistę Javascript mamy wszystkie cztery obszary pokryte i w ogóle wszystko mamy przez samodzielnie. Choć fakt jest faktem, że może się tak też stać. To co jest istotne to to, że pamiętajmy, że gwoźdź wbijamy młotkiem, a nie deską czy też na przykład śrubokrętem, więc dobrą technologię, dobre narzędzie do konkretnych potrzeb, w tej analogii do tego gwoździa trzeba dobrać.

Podsumowanie i rekomendacje końcowe

Już zbliżając się faktycznie do końca, pamiętajcie o tym, że do wyboru technologii trzeba podejść na chłodno, że warto też czerpać opinię z różnych źródeł, ale które to źródła patrzą na nasz konkretny problem biznesowy czy cel biznesowy, czy naszą wizję końca do rozwiązania, a nie tylko podają po prostu opinię na podstawie doświadczeń ze wcześniejszych projektów, bo to może się okazać niekoniecznie trafione do twojej konkretnej potrzeby, twojej aplikacji. Ograniczmy ryzyko poprzez zmapowanie właściwej architektury dla tego rozwiązania, tak żebyśmy wiedzieli jak to dokładnie miałoby wyglądać, jeżeli chodzi o ułożenie tych wszystkich funkcjonalności, modułów, przepływ danych. To są elementy architektury, które trzeba na pewno sobie pokryć i to jest oszczędność, bo z perspektywy czasu, jeżeli wybierzesz złą technologię, to jest ogromny koszt potem przerobienia tego, czy dostosowania technologii nieadekwatnej do danych potrzeb. Ograniczmy sobie też ryzyko poprzez potwierdzenie z zespołem co, jak będzie wykonane, jakie są ograniczenia danej technologii versus oczekiwania co do funkcjonalności i co najważniejsze tych celów danych rozwiązań. No i finansowo sprawdźmy też stawki i dostępność specjalistów dla wybranej technologii, na ile ona pod tym kątem jest popularna na rynku pracy. I myślę, że biorąc pod uwagę te wszystkie kwestie jesteśmy w stanie rzeczywiście jako osoba przedstawiciel bądź przedstawicielka biznesu podjąć właściwą decyzję co do tego wyboru technologii albo przynajmniej ograniczyć ryzyka co do złego wyboru na tym etapie. No i cóż, ja Wam bardzo dziękuję za wysłanie tego odcinka. Mam nadzieję, że trochę wiedzy udało się tutaj podsumować, jeżeli chodzi o ten świat techniczny, że on jest teraz Wam troszeczkę bliższy. Jeżeli macie jakiekolwiek pytania co do technologii nie ujętej w tym podsumowaniu, w tym odcinku tego podcastu, śmiało dajcie znać czy to w komentarzu czy po prostu napiszcie do nas na maila. Chętnie odpowiemy Wam na to jak byśmy postąpili w Waszej sytuacji lub jeżeli nie będziemy w stanie tak od razu odpowiedzieć, to zrobimy sobie spotkanie godzinne, dwugodzinne i tam pogłębimy temat i wtedy już postaramy się to oszacować. Dzięki Wam raz jeszcze za wysłanie dzisiejszego odcinka i do usłyszenia za tydzień we wtorek. Cześć!