Jakiś czas temu usłyszałem – buzzword – modne słowa, low-code i no-code, które mają opisywać coś rewolucyjnego i nowoczesnego. Zastanowiłem się chwilę i doszedłem do wniosku, że low-code i no-code już używałem w 2007 r. – 16 lat temu. Podzielę się swoimi doświadczeniami w pracy z generatorami magicznego kodu źródłowego (low-code i no-code) dla oprogramowania typu Enterprise, a nie wersji demonstracyjnych w postaci Proof of Concept. Czyżby low-code i no-code, to kolejny – hype – szum reklamowy?
Chcąc dowiedzieć się więcej o low-code i no-code sprawdziłem ich definicje na Wikipedii. Jak, to czasem bywa, używałem tych narzędzi, technologii bez znajomości ich formalnych definicji.
[…] „środowisko programistyczne używane do tworzenia aplikacji za pośrednictwem graficznego interfejsu użytkownika.”. […] „jest oprogramowaniem umożliwiającym budowę aplikacji w sposób wizualny, za pomocą diagramów, grafów czy formularzy bez znajomości języków programowania”.
[…] „pozwalają programistom i osobom niebędącym programistami na tworzenie aplikacji za pomocą graficznych interfejsów użytkownika i konfiguracji zamiast tradycyjnego programowania komputerowego.”. […] „”.
Obie platformy mają część wspólną, o której pisze Wikipedia:
[…] Platformy programistyczne bez kodu (no-code) są blisko spokrewnione z platformami programistycznymi o niskim kodzie (low-code), ponieważ obie mają na celu przyspieszenie procesu tworzenia aplikacji. Jednak w przeciwieństwie do platform programistycznych o niskim poziomie kodu (low-code), platformy programistyczne bez kodu (no-code) w ogóle nie wymagają pisania kodu, zazwyczaj oferując gotowe szablony, za pomocą których firmy mogą tworzyć aplikacje. […]
Wspomniałem o oprogramowaniu typu Enterprise i wersji demonstracyjnej w postaci Proof of Concept. Warto wyjaśnić oba pojęcia, żeby lepiej zrozumieć charakter, tego typu oprogramowania. W telegraficznym skrócie i dużym uproszczeniu, Proof of Concept jest wersją demonstracyjną docelowego i działającego oraz dużego i złożonego oprogramowania typu Enterprise używanego przez firmy do realizacji swoich celów.
Enterprise software
EN: According to Martin Fowler, „Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data.”.
PL: Według Martina Fowlera „aplikacje korporacyjne służą do wyświetlania, manipulowania i przechowywania dużych ilości często złożonych danych oraz wspierania lub automatyzacji procesów biznesowych za pomocą tych danych.”.
Proof of Concept
EN: Proof of concept (POC or PoC), also known as proof of principle, is a realization of a certain method or idea in order to demonstrate its feasibility, or a demonstration in principle with the aim of verifying that some concept or theory has practical potential. A proof of concept is usually small and may or may not be complete. These collaborative trials aim to test feasibility of business concepts and proposals to solve business problems and accelerate business innovation goals.
PL: Dowód koncepcji (POC lub PoC), znany również jako dowód zasady, to realizacja określonej metody lub pomysłu w celu wykazania jej wykonalności lub demonstracja w zasadzie w celu sprawdzenia, czy jakaś koncepcja lub teoria ma praktyczny potencjał. Weryfikacja koncepcji jest zwykle niewielka i może być kompletna lub nie.
Wyjaśnione pojęcia low-code i no-code brzmią wspaniale: „tworzenie aplikacji za pomocą graficznych interfejsów użytkownika i konfiguracji zamiast tradycyjnego programowania komputerowego” oraz „budowa aplikacji w sposób wizualny, za pomocą diagramów, grafów czy formularzy bez znajomości języków programowania”. Postaram się odpowiedzieć na pytanie – Czy tak jest w praktyce? – przedstawiając narzędzia, których używałem oraz opisując moje doświadczenia i spostrzeżenia w pracy z nimi, bez wnikania w szczegóły techniczne.
Lista narzędzi typu low-code i no-code, z których korzystałem:
- Oracle Forms – bazy danych,
- WebLogic Integration – procesy biznesowe,
- NetBeans – graficzny interfejs użytkownika.
Oracle Forms miało zrewolucjonizować i ułatwić dostęp do bazy danych stworzonej przez firmę Oracle. Ułatwiony dostęp miał być dla osób, które znają podstawy SQL, ale nie wiedzą jak tworzyć aplikacje typu desktop – z graficznym interfejsem użytkownika – umożliwiające wprowadzanie i wyszukiwanie danych w bazie danych za pomocą formularza.
W dużym uproszczeniu do Oracle Forms „zasiadał” techniczny specjalista od baz danych oraz języka SQL i tworzył aplikację z graficznym interfejsem użytkownika.
Formularze umożliwiały np.: zarządzanie magazynem, wprowadzanie produktów, wyszukiwanie. Stanowiły graficzną nakładkę na bazę danych i zapytania SQL, która umożliwiała operacje CRUD na tabelach w bazie danych. Przykład użycia Oracle Forms – Oracle Forms Presentation.
Finalnie, nie było tak kolorowo, zapytania SQL trzeba było opakować w procedury składowane, czyli dodatkowy element po stronie bazy danych. Spowalniało, to działanie GUI, a tym samym interakcje z formularzami. Modyfikacja elementów na styku interfejsu graficznego i bazy danych była czasochłonna i podatna na błędy.
WebLogic Integration miało być ułatwieniem dla programistów przy tworzeniu i modelowaniu procesów biznesowych oraz logiki aplikacji. Modelowane procesy miały być łatwe w modyfikacji bez konieczności zmiany kodu źródłowego aplikacji. Nie mniej jednak wymagały one późniejszego uzupełnienia kodem języka Java.
W odróżnieniu od Oracle Forms do WebLogic Integration „zasiadał” analityk biznesowy, bez technicznej wiedzy i tworzył graficznie modele procesów biznesowych. Graficzne modele procesów opisywały np.: przepływ informacji niezbędnych do realizacji promocji abonamentu dla klientów sieci komórkowych. Przykład użycia WebLogic Integration – Introduction to WebLogic Integration.
Tu również nie było tak kolorowo. Wizualna modyfikacja procesów biznesowych dosłownie szatkowała kod źródłowy języka Java, który należało napisać od nowa. Wdrażanie i uruchamianie modeli procesów biznesowych wymagało serwera aplikacji WebLogic, który potrzebował bardzo dużych zasobów pamięci i mocy obliczeniowej procesora.
NetBeans miało ułatwiać programistom tworzenie graficznego interfejsu użytkownika dla języka Java z wykorzystaniem biblioteki Swing. Sam NetBeans, to w zasadzie IDE, czyli zintegrowane środowisko programistyczne. W NetBeans można wyklikać wiele elementów bez znajomości szczegółów technicznych, np.: połączenia z bazą danych, serwerem aplikacyjnym oraz gotowe aplikacje Web i Enterprise. Przykład użycia NetBeans – Designing a Swing GUI in NetBeans IDE.
Wizualnie, graficzny interfejs użytkownika stworzony w NetBeans wyglądał bardzo ładnie, był szyty na miarę i każdy element – przyciski, pola tekstowe, tabele – były równo ułożone jak spod linijki. „Pod spodem” w wygenerowanym kodzie źródłowym nie było tak kolorowo. Modyfikacja kodu źródłowego wiązała się z „popsuciem” działającej aplikacji – wiele elementów, kodu miało „zabronioną” modyfikację. Wygenerowane zostało również bardzo dużo nadmiarowych elementów, które wzajemnie się duplikowały i wprowadzały zawiłość w kodzie źródłowym.
W jednym z akapitów cytowałem Martina Fowlera, którego artykuły polecam osobom, które chcą uzupełnić swój warsztat programistyczny o dobre praktyki opisane w profesjonalny i wyczerpujący sposób – https://martinfowler.com.
Zdaję sobie sprawę, że opisuję moje doświadczenia z technologiami, których używałem dawno temu. Niemniej jednak, właśnie dzięki temu chcę pokazać, że od wielu lat podejmowane są próby stworzenia magicznych narzędzi, które pozwolą dosłownie wyklikać i wygenerować aplikacje bez potrzeby znajomości języka programowania oraz bez udziału programistek, programistów.
Wszystkie opisane narzędzia korzystały z graficznych komponentów, które można było używać za pomocą mechanizmu przeciągnij i upuść (ang. drag and drop). Oczywiście należało wiedzieć jak połączyć ze sobą poszczególne elementy. Z uwagi na ten fakt narzędzia low-code i no-code wymagają wiedzy, którą musi przyswoić osoba, która z nich korzysta. Po mimo, że w dużej części przypadków nie trzeba znać języka programowania, to należy nauczyć się obsługi narzędzi tworzących oprogramowanie z wykorzystaniem low-code i no-code.
Generatory kodu, bo tak postrzegam narzędzia low-code i no-code mają być uniwersalne, a zarazem dostarczać niestandardowe (ang. custom) oprogramowanie szyte na miarę. Moim zdaniem, jeżeli coś jest uniwersalne, to kosztem czegoś. W większości przypadków są one niezoptymalizowane i wymagają więcej zasobów, tym samym są mniej wydajne. Narzędzia wspierające generowanie kodu są czarnymi skrzynkami, nad którymi mamy ograniczoną kontrolę, które możemy konfigurować w niewielkim stopniu.
W każdym przypadku, gdzie korzystaliśmy z narzędzi low-code i no-code używaliśmy ich jako punktu wejścia, punktu łączącego dany produkt – Oracle Forms, WebLogic Integration, NetBeans – z własnym ręcznie napisanym kodem źródłowym. Pozwalaliśmy tym narzędziom, technologiom wpuścić nas do swojego świata magicznie generowanego kodu, aby następnie rozsiąść się wygodnie z naszym własnym kodem źródłowym.
Poniżej cytat mojego serdecznego kolegi z branży IT, który zapytany przeze mnie o low-code i no-code odpowiedział bardzo trafnie, zgadzam się w 100% z jego słowami.
Marcin o low-code i no-code
„Tak, ludzie od zawsze chcieli mieć prościej. Problem, czy tracą ekspresje na tym, jeżeli tak, to na dłuższą metę nic z tego nie będzie.”.
Podsumowując, biorąc pod uwagę moje doświadczenie z low-code i no-code jestem bardzo sceptycznie nastawiony do wszelkiego rodzaju generatorów magicznego kodu źródłowego, finalnie i tak jest więcej dodatkowej pracy niż początkowych korzyści.
Zdjęcie autorstwa Tima Miroshnichenko z Pexels.
Polski 
English