„Low-code” nie jest nowym terminem. Został wymyślony przez firmę Forrester w 2014 roku, aby sklasyfikować „platformy programistyczne, które skupiają się na prostocie programowania i łatwości użytkowania. Platformy te umożliwiły programistom i użytkownikom na wszystkich poziomach umiejętności kodowanie aplikacji bez konieczności posiadania wiedzy na temat kodowania”. Trend rozprzestrzenił się lotem błyskawicy.
W międzyczasie, nie mogę określić dokładnie kiedy, pojawił się termin „no-code”. Sporo zamieszania wywołało ustalenie co jest czym. W kolejnych akapitach postaram się przedstawić mój punkt widzenia w tej kwestii.
Definicja low-code / no-code
Rzecz polega na tym, że na pierwszy rzut oka oba terminy wydają się być oczywiste. Wiele źródeł definiuje je w ten sposób:
- Low-code – platformy, które przyspieszają budowę oprogramowania przez umożliwienie stworzenia szkieletu aplikacji w trybie graficznym, w celu dalszego jej dostosowywania. Ograniczają zapotrzebowanie na kodowanie, ale nadal go wymagają do zbudowania produktu końcowego.
- No-code – platformy, które pozwalają na graficzną budowę aplikacji, bez konieczności pisania kodu.
I tu pojawia się pewna niejasność . Zgodnie z powyższą definicją nasza platforma archITekt jest platformą no-code, ponieważ w większości przypadków można zbudować system bez pisania nawet jednej linijki kodu. Czy jest więc naprawdę platformą no-code? Odpowiedź brzmi: “nie”.
Podobnie jak inne platformy programistyczne low-code, archITekt nie wymaga znajomości żadnego języka programowania ani frameworków technologicznych. Aby jednak efektywnie z niego korzystać, musisz mieć ogólną wiedzę techniczną na temat systemów IT, modeli danych itp. Jeśli chcesz zbudować rozwiązanie skalowane dla korporacji, powinieneś również wiedzieć o dodatkowych aspektach, takich jak najlepsze praktyki w zakresie podnoszenia wydajności, masowego przetwarzania danych itp.
W przeciwieństwie do low-code, platformy no-code w ogóle nie wymagają wiedzy technicznej. Możesz używać dużych, predefiniowanych bloczków konstrukcyjnych i łączyć je ze sobą, z pewną dozą parametryzacji. Jest to możliwe, ponieważ takie bloczki mają już wbudowaną logikę biznesową, dostosowaną do zamierzonego zastosowania biznesowego.
Myślę, że bardzo trafną analogią byłyby klocki LEGO.
Wyobraź sobie no-code jako LEGO Duplo lub zestawy tematyczne. Dzięki wielu predefiniowanym elementom możesz szybko zbudować np. Zamek Lodowy z filmu „Kraina Lodu”. Ale jeśli zamiast tego chcesz użyć takiego samego zestawu do budowy Sokoła Millennium ze Star Wars, byłoby to, cóż… trudne.
Z drugiej strony, wyobraź sobie low-code jako Lego Technic lub Mindstorms. Wiele ogólnych, szczegółowych elementów. Do zbudowania efektu końcowego potrzeba znacznie więcej pracy. Jednocześnie wyobraźnia nie ma granic, możesz zbudować prawie wszystko.
Plusy i minusy obu typów platform
W tym momencie może pojawić się pytanie: co jest lepsze; no-code czy low-code?
Niestety nie ma na to prostej odpowiedzi. Każda opcja ma swoje zalety oraz konsekwencje, które należy wziąć pod uwagę.
Z no-code możesz zbudować coś bardzo szybko i łatwo. Korzyścią będzie więc niski koszt wejścia i brak wymogu umiejętności technicznych, aby rozpocząć pracę. Narzędzia no-code są również dobrze dostosowane do wymagań biznesowych, biorąc pod uwagę wąską, specyficzną niszę dla zamierzonego zastosowania. Ceną za to jest dość szybkie dojście do ograniczeń narzędzia. Co więcej, raczej nie ma możliwości przezwyciężenia takich ograniczeń. Ponieważ komponenty dostępne do użycia są wcześniej zdefiniowane, nie ma możliwości tworzenia niestandardowych funkcjonalności lub wprowadzania dostosowań innych niż dozwolone.
Platformy low-code wymagają nieco więcej czasu. Różnorodność opcji sprawia, że są one bardziej złożone i wymagają nauki z samouczkami lub odbycia szkoleń. Ponadto, aby efektywnie z nich korzystać, potrzebna jest wiedza o architekturze systemów informatycznych i modelach danych. To z pewnością może być niedogodnością. Na szczęście nasz archITekt, podobnie jak wiele innych platform, pozwala na stopniowe przejście od najprostszych przypadków użycia do złożonych rozwiązań korporacyjnych. Dostępne są również zaczyny modułów lub kompletnych aplikacji, co ułatwia pracę, ponieważ nie trzeba rozpoczynać od zera.
Bonus, który otrzymujemy po początkowych niedogodnościach, to niemal nieograniczona pula opcji w zastosowaniu platformy. Nawet jeśli dojdziesz do ograniczeń samej platformy, udostępnia ona mechanizm elastycznych wtyczek pozwalających na rozszerzenie funkcjonalności o własny kod. W takim przypadku rzeczywiście potrzebujesz programisty, ale nie ma sytuacji, aby platforma zaprowadziła Cię w zaułek bez możliwości wyjścia.
Warto pamiętać, że taka elastyczność oznacza nieco bardziej generyczny sposób, w jaki platformy low-code spełniają wymagania biznesowe. Dobrym przykładem jest GUI. Będzie ładne i funkcjonalne, ale nie tak „wyrafinowane”, jak w przypadku zakodowania go przez zespół programistów front-end.
Kiedy użyć którego typu rozwiązań?
Czy powyższe oznacza, że w imię wolności i tak powinniśmy zainwestować w używanie narzędzi low-code? Niekoniecznie.
Jeśli możesz znaleźć narzędzie no-code, które dokładnie odpowiada Twoim potrzebom biznesowym, nie wahaj się i wykorzystaj je. Przyniesie ci szybki sukces. A nawet jeśli w przyszłości dotrzesz do ograniczeń, wciąż będzie czas na rozważenie innych opcji.
Jeśli nie możesz znaleźć narzędzia no-code, które adresowałoby Twój konkretny kontekst, ale z jakiegoś powodu zaczniesz z takiego korzystać, wcześniej czy póniej pojawi się frustracja. Będziesz próbował przebudowywać coś, co na pierwszy rzut oka wyglądało użytecznie, ale nie możesz tego dostosować tak jak chcesz. W takim przypadku powinieneś rozważyć platformę o low-code.
Platformy low-code różnią się między sobą, więc aby wybrać właściwą, powinieneś rozważyć ich specyfikę w stosunku do swoich wymagań. Ale to temat na inny post.
Wreszcie, nie ma takiej zasady, że należy trzymać się tylko jednej platformy. Możesz użyć nawet kilku narzędzi no-code do konkretnie zdefiniowanych celów i jednej platformy low-code do uniwersalnego zastosowania (przeczytaj post na ten temat).
Slawomir Gierek
Head of Business Development for VSoft archITekt
Let’s connect on LinkedIn
