Programowanie w świecie nowych technologii

Programowanie w świecie nowych technologii

---

Trzy podstawowe pytania

• Programiści – czy tworzą działające, zgodne z potrzebami klienta aplikacje, czy tylko produkują i kompilują kod źródłowy?

• Rozwój technologii – czy to tylko bardziej wypasiona elektronika oraz systemy operacyjne i języki programowania o coraz dziwaczniejszych nazwach, czy również zmiany metod, procesów, organizacji?

• Nowość – dla jednej osoby, dla danej firmy, czy autentyczna nowość?

Co to właściwie jest „programowanie”?

Czy oznacza to tworzenie oprogramowania, a więc złożony proces, obejmujący całą drogę od analizy wymagań, poprzez projektowanie, pisanie kodu, integrację, testowanie, wdrożenie i utrzymanie? Czy też programowanie, to samo kodowanie: pisanie kodu źródłowego, kompilowanie, ewentualnie analiza statyczna i testy jednostkowe – czyli to, co zwykle wykonują osoby zwane programistami?

Jeśli programowanie, to samo pisanie kodu źródłowego na podstawie względnie dokładnej specyfikacji, wtedy zależność programisty od zmian technologii bywa mniejsza. Wiemy jednak, że w praktyce, na dobre i złe, programiści – chcąc nie chcąc – pełnią wiele funkcji: zbierają wymagania, testują, wdrażają, odpowiadają za utrzymanie. Tak dzieje się czasem z powodu niefrasobliwości kierownictwa, które nie rozumie potrzeby istnienia innych uczestników projektu poza skrzętnymi programistami. Czasem firma i projekt są po prostu bardzo małe. Niekiedy taki stan rzeczy bywa wynikiem świadomego wyboru metod zwinnych, „agile” lub podejścia "DevOps". Wówczas programiści muszą dobrze rozumieć dziedzinę, dla której tworzą kod – jest to niewątpliwe wyzwanie.

Co to właściwie jest „technologia”?

Słysząc słowo „technologia”, zwykle wyobrażamy sobie coś twardego: nową elektronikę, nowe procesory, nowe światłowody, nowe sposoby produkcji tychże, i tak dalej. Jeśli nie elektronika, mechanika ani nie chemia, to ostatecznie nowe aplikacje: systemy operacyjne (np. zaroiło się nam w ostatnich latach od pseudo-nowości w formie plejady androidów, iOS-ów, blackberries’ów, symbianów.), nowe algorytmy, nowe języki programowania. Słowa „technologia” i „technika” są po polsku powszechnie stosowane zamiennie.

Tymczasem angielskie słowo „technology” oznacza coś więcej: także procesy, procedury, sposoby organizacji. Przy takim rozumieniu technologii, wyzwaniem dla programisty byłyby również zmiany procesu tworzenia oprogramowania, takie jak, na przykład, przejście od modelu kaskadowego do przyrostowego, wdrożenie RUP, stosowanie formalnych metod modelowania wymagań. Tak, to często bywa dla programistów większym wyzwaniem, niż nowe techniki.

Co znaczy „nowe”?

W jakimś stopniu każde zadanie programisty jest nowe – nie programuje się zwykle ponownie tego, co już działa, lecz realizuje funkcjonalność dotąd nie istniejącą. Po drugie, nowość to pojęcie względne: coś może być nowością dla danej osoby, na przykład język C# dla kogoś znającego Java, albo programowanie aplikacji MacOS dla kogoś, kto wcześniej pracował pod Windows.

Technologia może być nowością w jednej firmie, czy branży, choć gdzie indziej istniała już wcześniej. Wreszcie, istnieją też prawdziwe nowości: technologie, które wcześniej nie istniały w ogóle. Takie technologie są dla programistów największym wyzwaniem: czasem wymagają radykalnej zmiany dawnego podejścia, brak podręczników, brak narzędzi, jest większe ryzyko popełnienia błędów.

---

Programowanie dla nowych technologii

Nowe technologie biznesu

Większość zmian w oprogramowaniu bierze się z nowych potrzeb biznesowych. To biznes przychodzi do programistów i prosi „zróbcie to a to, najlepiej na wczoraj”. Stara funkcjonalność na nowych urządzeniach, na przykład mobilnych; nowa funkcjonalność ze starych elementów, na przykład możliwość zeskanowania kodu kreskowego towaru telefonem i sprawdzenie, czy produkt jest naprawdę markowy; wreszcie zupełnie nowa funkcjonalność – na przykład nowe usługi bankowe albo ubezpieczeniowe, dostępne przez Internet.

Tak, realizacja takich nowych technologii biznesowych to główny cel, podstawowe zadanie i największe wyzwanie dla programistów. Dziś oprogramowanie nie jest, jak 30 lat temu, dodatkiem do działania firmy czy instytucji, lecz jej motorem. Umiejętność IT, aby szybciej, skuteczniej i taniej niż konkurencja realizować w niezawodnym, łatwym do modyfikowania kodzie, zmieniające się jak w kalejdoskopie potrzeby biznesu, jest kluczem do sukcesu firmy, albo… powodem jej klęski, jeśli IT zawiedzie.

Nowe technologie platformy

Pojawienie się nowego procesora, zmiany w systemie operacyjnym, nowe usługi internetowe (Web services), nowy protokół komunikacyjny, nowy algorytm szyfrowania danych, nowe, pojemniejsze dyski – czy to wyzwania dla programistów, czy też sprawy dla nich obojętne?

Bywa bardzo różnie. Nowe urządzenie jest wielkim wyzwaniem dla osoby, która pisze sterownik dla tego urządzenia, a sprawą często najzupełniej obojętną dla kogoś, kto tworzy kod wysokiego poziomu. Pod warunkiem… pod warunkiem, że oprogramowanie ma dobrą strukturę, realizuje zasady hermetyzacji (encapsulation), modularyzacji, i ma właściwie zbudowaną hierarchię klas.

Niezależnie od tego, jakiego rodzaju zmiany w technologiach miały, mają i będą miały miejsce, umiejętność radzenia sobie z nimi przez programistów zależy od umiejętności stosowania przez nich dobrego stylu programowania, wyboru właściwych języków i nieulegania pokusie stosowania brzydkich sztuczek (kludge) w pisaniu kodu.

Programowanie jakiego poziomu?

Różne zmiany technologiczne mają różny wpływ na pracę programistów, zależnie od tego, ja jakim poziomie ich programowanie się odbywa. Programista sterowników sprzętu musi rozumieć nową technologię i dostosowywać swój kod do jej zmian przy każdej technicznej nowości, natomiast jest zwykle obojętny na nowe wyzwania biznesowe. Programista aplikacji WWW być może nie dba (pod warunkiem, wspomnianej w poprzednim akapicie, poprawnie realizowanej hermetyzacji) o zmiany technologii układów scalonych, dysków i wyświetlaczy, ale za to musi stawić czoła modyfikacjom biznesu, który jego aplikacja realizuje.

Tak więc, podsumowując, rozwój różnych technologii jest – lub nie – trudnym wyzwaniem dla programistów, zależnie od tego, na jakim poziomie wirtualnej maszyny działają.

---

Programowanie przy pomocy nowych technologii

Nowe języki programowania

Programista szukający pracy ma czasem wrażenie, że znajomość właściwego języka programowania jest podstawowym warunkiem powodzenia. Jeśli wśród wymagań wobec stanowiska, o które programista się ubiega, napisano „znajomość ADA95 | APL | Assembler | AWK | Bash | Basic | C | C# | C++ … Ruby | Smalltalk … Xbase | XHTML”, to nie ma zmiłuj. Bez znajomości tego języka jest się bez szans.

Cóż, wynika to z krótkowzroczności pracodawców, lub wręcz rozpaczliwej ignorancji działów zajmujących się rekrutacją, nie zdających sobie sprawy z tego, że nowego języka programowania można się doskonale nauczyć w ciągu kilku dni, natomiast opanowanie najlepszych praktyk i zasad inżynierii oprogramowania zajmuje o wiele dłużej. Kiepski programista znający „właściwy” język, będzie wydajniejszy od dobrego programisty, który tego właśnie języka nie zna… przez pierwszy tydzień, a potem role się odwrócą.

Czyli z punktu widzenia interesów własnej kariery, zalecałbym programistom sprostanie wyzwaniu uczenia się najnowszych, najmodniejszych języków, albo – przeciwnie – opanowaniu jakiegoś archaicznego dialektu, który jest i niemodny, i bardzo potrzebny… jak COBOL w roku 1999.

Natomiast z punktu widzenia faktycznych umiejętności zlecam raczej znajomość kilku języków, co wybitnie ułatwi – w razie potrzeby – szybkie uczenie się kolejnych. Nie zapominajmy, że języki programowania są dla ludzi, nie dla maszyn – mikroprocesor i tak dostaje do wykonania sekwencję instrukcji napisanych w kodzie maszyny, a psychologiczne podstawy, na których opiera się gołosłowne twierdzenia o wyższości jednych języków nad innymi, są zwykle bardzo wątłe. Nie ma się czym ekscytować.

Nowe paradygmaty programowania

W przeciwieństwie do poszczególnych języków, ważna jest natomiast znajomość różnych paradygmatów, sposobów podejścia do programowania. O ile przejście między C++, C# i Java nie powinno nastręczać żadnych trudności, o tyle zmiana paradygmatu z asemblera na język strukturalny, z języka strukturalnego na obiektowy, a z każdego z nich – na rekurencyjny, jak Lisp czy Prolog, to już większe wyzwanie. OK – takim wyzwaniom programiści muszą sprostać, tak jak leśniczy nie powinien błądzić w lesie, i nic ponadto. Zresztą, nie wydaje się, aby należało się spodziewać czegoś nowego w tej dziedzinie w najbliższej przyszłości.

Niekiedy, nowa technologia produktu programistycznego pociąga za sobą nowy paradygmat. Na przykład rozszerzająca się technologia tworzenia usług internetowych, wykorzystująca architekturę SOA, pociąga za sobą pewne nowe sposoby programowania, niezależnie od używanego języka.

Czy nowe metody to też nowe technologie?

To wprawdzie sprawa do teoretycznej dyskusji (patrz wcześniejszy akapit: Co to właściwie jest „technologia”?), ale nie ulega wątpliwości, że nowości czysto techniczne są dla programistów w praktyce o wiele mniejszymi wyzwaniami, niż stosowanie nowych metod wytwarzania oprogramowania. Dlatego pominięcie tego tematu oznaczałoby zamykanie oczu na to, co najistotniejsze.

Temu wyzwaniu programiści stawiają czoła, ze zmiennym powodzeniem, od ponad 60 lat. Kiedyś programowanie było zajęciem dla samotnych geniuszy, często lauretaów Nobla z fizyki. Potem stało się zadaniem zespołowym, trochę z pogranicza sztuki, trochę rzemiosła, stopniowo – manufaktury. Rosnąca złożoność przedsięwzięć informatycznych oraz ich efektowne niekiedy niepowodzenia spowodowały, że usiłowano je uporządkować, zbiurokratyzować, uczynić bardziej przewidywalnymi. Z pra-oceanu pra-programowania wyłoniły się nowe, nieznane wcześniej dyscypliny: analiza biznesowa, inżynieria oprogramowania, zarządzanie konfiguracją, zapewnienie jakości, testowanie, utrzymanie. Potem nadeszła kontr-rewolucja „agile”, próba powrotu do pre-biurokratycznych korzeni. Każda z tych zmian wywierała ogromny wpływ na treść i kształt pracy programistów, każdorazowo wyzwaniem było poradzenie sobie w nowej rzeczywistości.

---

Programowanie, kiedy świat się zmienia

Rozwój technologii oznacza zmiany. Jakim wyzwaniem są dla programistów zmiany?

Jak radzić sobie ze zmiennością

Na pierwszy rzut oka, zmiany, także te wynikające z rozwoju technologii, nie są dla programistów ani większym, ani mniejszym wyzwaniem, niż dla każdego innego. Zmiany powodują obawy, poczucie zagrożenia, uaktywniają syndromy „tak robiliśmy zawsze” oraz „lepiej nie próbować naprawić tego, co nie jest zepsute”. Jednak, zmiany w IT mają też swoją specyfikę, która odróżnia je od zmian w, dajmy na to, hutnictwie, a upodabnia do zmian mody – są niezwykle szybkie i nagłe.

Zmiany oprogramowania, wynikające ze zmiany technologii, łatwo mogą doprowadzić do chaosu, którego bezwinnymi (czasem, współwinnymi…) ofiarami często stają się programiści i testerzy. Jeśli nie ma dobrze działającego procesu zarządzania zmianami wymagań, programiści o zmianach dowiadują się często chaotycznie i na ostatnią chwilę. Jeśli nie ma dobrego projektu, zmiany wdrażane przez programistów mogą być niespójne. Jeśli nie dokonuje się analizy wpływu (impact analysis), to zdarza się, że realizacja żądanej zmiany wymaga znacznie więcej czasu, niż przewidywano. Tę litanię można by ciągnąć jeszcze długo.

Łatwość modyfikacji

Rozwój technologii IT zwykle nie odbywa się skokowo, kwantowym skokiem, lecz drogą stopniowych, niewielkich zmian. Tak więc wyzwanie dla programistów nie oznacza zwykle, że wyrzuca się komplet starego oprogramowania i wszystko pisze zupełnie od nowa, lecz że dokonuje się modyfikacji już istniejących aplikacji i systemów. Dlatego łatwość, na ile oprogramowanie poddaje się zmianom, tak zwana łatwość utrzymania (maintainability)
decyduje, na ile rozwojowi technologii towarzyszy nieustanna trauma, a na ile może się on odbywać bezboleśnie, płynnie.

Niestety, przy projektowaniu systemów i podczas ich realizacji w projektach, ta właściwość pada zbyt często ofiarą krótkowzroczności, chęci osiągnięcia pozornego sukcesu w bieżącym projekcie kosztem… przyszłych pokoleń, jak deficyt budżetowy państwa. W końcu szybciej jest – zacytuję Adama Kolawę, polskiego, niestety nieżyjącego, programistę-miliardera – przyspawać zapasowe koło do osi, niż mozolnie przykręcać pięć śrub. Zaś kierownik projektu zostanie pochwalony za zakończenie projektu w terminie - nikt nie widzi, że osiągnięce kosztem jakości i łatwości utrzymania. I tak oszczędność wynikająca ze zwykłego niechlujstwa, wynosząca, dajmy na to, 100 K, powoduje wzrost kosztów testowania, wdrożenia i napraw w ostatniej chwili o 1000 K, zaś rozłożone na lata koszty utrzymania mogłyby być może i o 100.000 K mniejsze.

Nie magiczne języki programowania, nie mistyczne – zwinne, ekstremalne – metodyki, nie betonowe normy typu PRINCE-2, ITIL czy COBIT, lecz wyłącznie dobry proces inżynierii oprogramowania, dobre praktyki zapewniają, że programiści będą sobie radzic z wyzwaniami płynącymi z rozwoju technologii bez potrzeby wylewania hektolitrów potu i łez.