Programowanie wizualne to rodzaj języka programowania, który pozwala ludziom opisywać procesy za pomocą ilustracji. Podczas gdy typowy tekstowy język programowania zmusza programistę do myślenia jak komputer, wizualny język programowania pozwala programiście opisać proces w kategoriach, które mają sens dla ludzi.
Jak duża jest przepaść między programowaniem wizualnym a tradycyjnym, zależy od narzędzia do programowania wizualnego. Na jednym z krańców, narzędzie osłania programistę prawie całkowicie przed przepaścią między ludzkim myśleniem a komputerami tasującymi bity po pamięci.
Oto przykład. Aby stworzyć listę rzeczy do zrobienia za pomocą wizualnego narzędzia programistycznego, programista rysuje przepływ aplikacji. Powstały diagram przepływu opisuje ekrany, interakcje użytkownika i to, co dzieje się z danymi na każdym etapie. Narzędzie następnie przekształca to w oprogramowanie.
Jako programiści wiemy, że tekstowe języki programowania skupiają się całkowicie na implementacji: chodzi o dokładne kroki, które komputer musi podjąć, aby stworzyć doświadczenie, które chcemy dać użytkownikowi. Jasne, języki wyższego poziomu i nowoczesne frameworki dają nam wygodne skróty. Ale zadaniem programisty jest przełożenie ludzkich potrzeb na procesy, które pasują do ograniczonych możliwości komputera.
Inne narzędzia do kodowania wizualnego podążają za tymi samymi procesami i paradygmatami, co programowanie oparte na tekście. Wyobraź sobie rysowanie klasy i jej relacji z obiektami, które instancjonujesz, zamiast wpisywania tego wszystkiego do edytora tekstu.
Wszystko to brzmi świetnie! Ale, możesz zapytać, gdzie są ci wszyscy wizualni programiści? Dlaczego wciąż piszemy kod ręcznie? Czy to znaczy, że programowanie wizualne jest złym pomysłem?
Zanim odpowiemy na te pytania i zagłębimy się w dzisiejszy stan programowania wizualnego, musimy zrozumieć, czym tak naprawdę jest programowanie wizualne: skąd się wzięło, jak ewoluowało i dlaczego.
Odkryj następną generację wizualnych narzędzi programistycznych
Krótka historia oprogramowania do programowania wizualnego
Chociaż historia zdaje się na to wskazywać, nie można powiedzieć, że programowanie wizualne w latach 90. było ograniczone do zestawów do tworzenia gier, narzędzi multimedialnych i baz danych. Firma Rational Software (która została przejęta przez IBM w 2003 roku) tworzyła nie-GUI Ada IDE od połowy lat 80-tych. Ponadto, firma zajęła się również definiowaniem procesu tworzenia oprogramowania. Praca nad ich Rational Unified Process i pokrewne wysiłki doprowadziły w końcu do powstania Unified Modelling Language, który miał potencjał udokumentowania każdej ostatniej części systemu bez pisania choćby linijki kodu. Wyglądało to jak programowanie wizualne, ale bez wytwarzania oprogramowania wykonywalnego.
UML zapewnił znormalizowany i wszechstronny język do opisywania systemów zorientowanych obiektowo. Jednak gorączka UML-a dotknęła niektórych architektów. Współautor książki The Pragmatic Programmer, Andy Hunt, opowiada historię projektu oprogramowania, w którym architekt spędził dwa lata na tworzeniu diagramów UML, zanim napisano choćby linijkę kodu.
Tuż po tym, jak agile nabierał rozpędu, UML wydawał się umożliwiać wszystkie najgorsze aspekty starych sposobów budowania oprogramowania: zbyt dużo planowania i zbyt mało implementacji. Executable UML był próbą dodania tego brakującego elementu – oprogramowania wykonywalnego. Pojawiło się kilka implementacji, ale nie wywarły one zbyt dużego wpływu na świat, który szybko przestawił się na PHP, Ruby on Rails i inne dynamiczne języki skryptowe.
Co ciekawe, jedna z form wykonywalnego UML-a, która się utrzymała, również wyszła z Rational Software. Rational Rose to zestaw narzędzi do tworzenia oprogramowania przy użyciu UML i generowania kodu wykonywalnego w języku docelowym, takim jak C++ lub Java.
Back to the Future: The State of Visual Programming Today
Bazując na tym, co pokazuje nam historia, możesz się zastanawiać: czy programowanie wizualne jest martwe? Entuzjaści programowania wizualnego powiedzą Ci, że jest ono dalekie od śmierci. Zapytajcie ich „co to jest programowanie wizualne?”, a najpierw wymienią jakieś niejasne narzędzie specyficzne dla danej dziedziny. Potem powiedzą, że to narzędzie jest dowodem na to, że programowanie wizualne żyje i ma się dobrze. Ty tymczasem będziesz gorączkowo szukał go w Google. W rezultacie dowiesz się nie tylko o narzędziu, o którym wspomnieli, ale także o wysoce wyspecjalizowanym świecie, w którym ono istnieje.
Bez wątpienia programowanie wizualne ma swoją rolę, czy to w programowaniu syntezatorów, czy w dawaniu entuzjastom UML poczucia spełnienia. Jednak w przypadku oprogramowania ogólnego przeznaczenia, świat jest po prostu zbyt złożony, by modelować go czysto wizualnie. Kiedy twój „kod” wygląda jak schemat obwodu procesora, być może nadszedł czas, by ponownie przemyśleć przydatność programowania wizualnego do tego zadania.
Podobnie, oprogramowanie do programowania wizualnego ma tendencję do bycia ograniczonym przez wyobraźnię twórcy w sposób, który nie przeszkadza tekstowym językom programowania ogólnego przeznaczenia.
A jednak narzędzia takie jak Visual Basic, Delphi i ich potomkowie pokazały nam, że wizualne tworzenie oprogramowania może być niezwykle wydajne; chodzi tylko o to, że istnieje pragmatyczny kompromis, w którym czasami ręcznie pisany kod jest właściwym rozwiązaniem.
Superstars vs. Teams: Nowe życie dla wizualnych języków programowania?
Te wczesne dni programowania były trudne, to na pewno. Ale jedna osoba mogła zrozumieć i być ekspertem we wszystkim, co było konieczne do stworzenia tego oprogramowania. Jeśli jesteś wystarczająco stary, pomyśl o tytułach programów z lat 80-tych. Powszechne było, że pojedynczy programista stawał się marką samą w sobie.
Sid Meier, Mitch Kapor i Jeff Minter zdobyli pewien poziom sławy, tworząc znane aplikacje lub gry samodzielnie lub, co najwyżej, z jednym współpracownikiem. W tamtych czasach, cykle aktualizacji oprogramowania i sprzętu trwały latami. Dziś żartujemy, że każdego dnia pojawia się nowa biblioteka JavaScript. Jednak jest trochę prawdy w tym, że współczesny rozwój oprogramowania porusza się w tempie, za którym wielu z nas nie może nadążyć.
Dzisiaj oprogramowanie jest w dużej mierze budowane przez zespoły specjalistów. Podczas gdy pierwsi programiści robili wszystko sami, współczesny zespół programistów może mieć jedną osobę, której jedynym zadaniem jest opieka nad narzędziem CI. Programiści spędzają całe kariery skupiając się na jednym frameworku lub platformie. Programiści iOS są programistami iOS, a nie programistami mobilnymi. Raz lub dwa razy na dekadę, być może, programista webowy może zmienić swój preferowany framework. Bardzo niewiele osób zajmuje się zawodowo ręcznym pisaniem w języku asemblera.
Nie chodzi tylko o to, że zmienił się zakres oprogramowania. Do pewnego stopnia, sami programiści również się zmienili. Inżynier oprogramowania to w dzisiejszych czasach po prostu kolejna kariera. W minionych dekadach była to pasja kilku osób, które poświęcały się nauce zupełnie nowego systemu, by móc napisać port Atari ST, na przykład, swojej udanej gry na Amigę. Ale to zrozumiałe: informatyka nie jest już niszowa.
Dzisiaj mamy świat, w którym tworzenie oprogramowania składa się z coraz bardziej złożonych elementów, a programiści to zwykli ludzie o niezwykłych specjalizacjach. Ta złożoność i specjalizacja są źle dopasowane do czystego programowania wizualnego tych wczesnych narzędzi, ale to również sprawia, że coraz trudniej jest budować okrągłe zespoły inżynierów oprogramowania.
Gdzie czyste środowiska programowania wizualnego zawiodły, istnieje cały zestaw podobnych narzędzi, które biorą to, co najlepsze z programowania wizualnego i łączą to z kodowaniem tekstowym. Podczas gdy programowanie wizualne było „bezkodowe”, te nowe narzędzia są niskokodowe.
Narzędzia takie jak OutSystems pozwalają programistom tworzyć oprogramowanie wizualnie poprzez rysowanie przepływów interakcji, UI i relacji między obiektami, ale uzupełniając to ręcznie pisanym kodem, gdy jest to lepsza rzecz do zrobienia.
Ta pragmatyczna mieszanka programowania wizualnego i tekstowego jest dobrze dopasowana do potrzeb nowoczesnego rozwoju oprogramowania. Platformy niskiego kodu zmniejszają złożoność tworzenia oprogramowania i przywracają nas do świata, w którym pojedynczy programista może tworzyć bogate i złożone systemy, bez konieczności uczenia się wszystkich podstawowych technologii.
Next Generation of Visual Programming: Delivering on the Promise
Programowanie wizualne miało tak wiele obietnic, a problemy, które chciało rozwiązać, nie zniknęły. W rzeczywistości są one bardziej istotne niż kiedykolwiek.
Ale problemy świata rzeczywistego wymagają większej elastyczności, niż programowanie wizualne mogłoby zaoferować. Low-code bierze tę obietnicę i stosuje ją do zmniejszenia złożoności, jaką można znaleźć w nowoczesnym oprogramowaniu. Nie pytaj więc „czym jest programowanie wizualne?”. Zamiast tego, zapytaj „czym jest low-code?”. Możesz również umówić się na demo online lub nawet wypróbować OutSystems (jest darmowe).