5 linijek kodu, które mogą zmienić czyjeś życie

Dla większości programistów, czy administratorów systemowych odpowiedzialnych za tworzenie oprogramowania, kod jest sprawą czysto utylitarną, którego zadaniem jest  rozwiązanie danego problemu. Oczywiste jest, że w ramach tworzenia kodu produkcyjnego istotne jest dbanie o poprawność składni, wykorzystanie właściwych wzorców projektowych, obsługę błędów itd. Wszystko to jednak mieści się w ramach dobrze pojętego rzemiosła i profesjonalizmu programującego. 

Kod taki może być w całości stworzony przez człowieka, czasem w jego powstaniu pomagać mogą auto generatory i i gotowe biblioteki, ale efektem zawsze powinno być coś, co realizuje zapotrzebowanie. Dodatkowo jeszcze dobrze, jeśli może przez autora być określone jako “dobrze zrobione i spełniające zadanie”. 

Dawniej

Kilkanaście lat temu albo jeszcze dawniej, nie było dyskusji i problemu związanego z tym, jakie są oczekiwania użytkownika co do sposobu używania tak stworzonego oprogramowania. Komputery były urządzeniami o ograniczonym dostępie i z założenia ktokolwiek, kto do nich siadał, musiał mieć pewne umiejętności techniczne. Program i jego interfejs mogły więc mieć pewien stopień skomplikowania, bo mówiło się, że programiści tworzą dla innych programistów. 

Analogicznie sytuacja wyglądała w systemach łączności dla służb publicznych. Rozwiązanie miało być przede wszystkim niezawodne w codziennym działaniu i tej funkcji był podporządkowany. Również ówczesne radiotelefony, choć proste w obsłudze, miały jeden cel: umożliwić komunikację głosową pomiędzy użytkownikami. Zawiłości procesu konfiguracji, czy zmiany wersji systemu stały na drugim planie i należały do wyspecjalizowanego personelu. 

Dzisiaj

Obecnie sytuacja wygląda kompletnie inaczej. Oprogramowanie otacza nas na każdym kroku, a przeciętny człowiek używa nie tylko komputera, ale otoczony jest też przez smart urządzenia, takie jak telewizory, telefony, zegarki, pół autonomiczne samochody, urządzenia IoT, na serwisach dostępnych w chmurze kończąc. 

Ta różnorodność platform, przypadków użycia i środowisk, na których aplikacje będą pracowały, dla kogo są tworzone i przez kogo będą używane, przynosi do wcześniejszych wymagań formalnych jeszcze jedno, ale jakże ważne wymaganie - kontekst. Już nie wystarczy napisać poprawnego, bezbłędnego kodu, do którego użycia na końcu potrzebny będzie użytkownik z tytułem inżyniera (chyba że to system dla inżynierów). Dziś równie istotne przy projektowaniu i tworzeniu oprogramowania jest to, jak użytkownik chciałby takiego programu używać.

Jako użytkownik czego innego spodziewamy się po aplikacjach znajdujących się na naszych telewizorach, telefonach, czego innego spodziewamy się od software’u uruchamianego w samochodzie, a jeszcze czego innego chcemy od aplikacji i serwisów dostępnych w chmurze i na laptopach. Jeszcze bardziej widoczne jest to w przypadku oprogramowania tworzonego w konkretnym celu i dla ograniczonej grupy użytkowników. 

W przypadku aplikacji mobilnych istotna jest prostota i intuicyjność obsługi, płynność działania czy dostępność nowych funkcjonalności i wersji na jedno kliknięcie oraz optymalizacja zużycia baterii i rozsądne ilości transferowanych danych, podczas gdy dla serwisów w chmurze równie ważna jest niezawodność rozwiązania i wielość opcji i możliwości oprogramowania.

Rosnące standardy

To powoduje, że nie wystarczy być już mistrzem w swoim fachu i pisząc kod, trzeba mieć w głowie nie tylko kryteria odnoszące się do jego poprawności formalnej, ale też perspektywę potencjalnego użytkownika, bądź zastosowania oprogramowania. To z kolei sprawia, że pojawiają się dodatkowe parametry wpływające na to, w czym oprogramowanie jest tworzone (język, technologia), jakie są jego podstawowe KPI, ale przede wszystkim determinuje całościowy projekt takiego software’u. Parametry programu dekodującego muzykę mogą być całkowicie zadowalające, ale już ten sam algorytm może kompletnie się nie sprawdzać w przypadku przetwarzania toczącej się pomiędzy dwoma użytkownikami rozmowy. 

Dla zobrazowania spójrzmy na rynek aplikacji dla urządzeń mobilnych. Według danych z maja 2020 Google Play zawiera 2.65mln aplikacji, a Apple app store 1.85mln. Nic więc dziwnego, że zawsze, kiedy potrzebujemy, możemy znaleźć przynajmniej kilka, bądź kilkanaście programów odpowiadających wyszukiwaniu. Jednocześnie jedynie niewielki procent z nich przebija się do szerszego grona użytkowników i staje się nieodzownym elementem telefonu. Ciekawe w tym przypadku jest to, co można znaleźć w komentarzach tych mniej popularnych. Biorąc pod lupę prostą aplikację kompasu widać, że zawiłość interfejsu, nadmiar reklam, czy niewystarczające wytestowanie jest boleśnie punktowane w komentarzach. Z drugiej strony, te, które zbierają najlepsze noty, wcale nie są diametralnie różne, bo trudno w tym wypadku o wielkie różnice, ale oceny mówią same za siebie: “prosta i niezawodna”, “szybko się instaluje”, “robi, co ma robić”. 

To przykład prostej aplikacji mobilnej, z tym że użytkownik na co dzień przyzwyczajony do takiego doświadczenia, przenosi je do świata bardziej złożonych i zaawansowane rozwiązań i systemów, oczekując tego samego w większej skali. 

Specjalne wyzwania

Moje osobiste doświadczenie jako architekta systemów związanych z komunikacją dla służb ratunkowych dostarczanych przez Motorola Solutions jest podobne. Dziś policjant, biorąc do ręki radiotelefon Motoroli, oczekuje od niego tych samych cech co przez lata, ale też łatwości i intuicyjności obsługi znanych z dzisiejszych urządzeń mobilnych oraz przynajmniej części ich funkcjonalności.  

To wyzwanie dla projektantów i programistów, bo oprócz niezawodności i dobrze sobie znanych parametrów związanych z obsługą komunikacji głosowej, dochodzi całkiem nowa warstwa dla danych, lokalizacji, map, video czy obsługi połączeń do sieci komórkowej. Wszystko to musi zostać stworzone w sposób, który poda potrzebne informacje prosto do rąk i oczu policjanta, będąc dodatkową pomocą, a nie zajęciem, które rozproszy uwagę. Szczególnie istotne jest to w sytuacjach “awaryjnych”, gdzie system łączności ma pomagać, ale w żadnym wypadku nie może stanowić dodatkowego, całkowicie zbytecznego w takiej sytuacji balastu.

To właśnie kontekst pozwala na zdefiniowanie potrzeb, sposobu pracy i wykonywania codziennych zadań. Dość łatwo np. wywnioskować obserwując pracę policjanta, że w czasie interwencji jego ręce powinny pozostać w miarę możliwości wolne, ale już bez obserwacji trudniej jest odpowiedzieć na pytanie, w jakich czynnościach system może pomóc w czasie interwencji i po niej. Łącząc te dwa parametry, czytelne stanie się, że aplikacje używane podczas akcji będą raczej asystentami, a te używane w innych okolicznościach, absorbujące więcej uwagi, mogą być bardziej interaktywne.

Podobnie obserwacja operatora w centrali prowadzić będzie do wniosku, że kluczowe w sytuacji alarmowej jest dotarcie do informacji, zorganizowanie pomocy oraz dostarczenie potrzebnych informacji do rąk służb udających się na miejsce zdarzenia. System powinien więc pomagać wyłowić to, co w danym momencie istotne i umożliwić efektywne ich przekazanie, jednocześnie dając kontrolerowi wszystko, co potrzebne, żeby panować nad sytuacją.

Wracając do perspektywy programisty, informacje w takim zakresie są w przypadku bardziej skomplikowanych rozwiązań rzadko dostępne. Dlatego też często ma on ograniczoną wiedzę o tym, jak jego kod będzie później wpasowany w system. Tym samym brak mu tego, co kluczowe, aby tytułowe pięć nowych linii kodu stworzonego przez pojedynczego człowieka mogło być maksymalnie pomocne w ratowaniu czyjegoś zdrowia, lub dbaniu o bezpieczeństwo samego użytkownika i nader często wydają się być jedynie usprawnieniem na poziomie pojedynczej aplikacji.

Niemniej istotny jest kontekst w tworzeniu scenariuszy testowych. Tam nowy kod sprawdzany jest razem z już istniejącym i weryfikowane są wymagania systemu łączności krytycznej (mission critical communication). To w testach pojedyncza funkcjonalność staje się częścią systemu składającego się z radiotelefonów, infrastruktury, stacji bazowych itd., więc wiedza o możliwych (oraz niespodziewanych) przypadkach użycia całych ekosystemów jest tu równie ważna, jak przy pisaniu samych aplikacji. 

Oczywiście ostateczną weryfikację i tak przyniesie dopiero osadzenie w realnym świecie użytkownika, ale wszystkie wcześniejsze etapy mają na celu uzyskanie maksymalnej pewności, że dostanie on w ręce w pełni sprawne i adresujące jego potrzeby narzędzie.

Podsumowanie

Podsumowując, niezależnie od tego, czy jest się architektem, programistą, bądź testerem oprogramowania i na którym etapie jest się zaangażowanym w proces jego tworzenia, dziś bardziej niż kiedykolwiek do tej pory ważne jest przyjęcie i zrozumienie perspektywy użytkownika, jego oczekiwań i sposobu używania aplikacji. To oczywiście nie zawsze będzie kwestia czyjegoś życia bądź śmierci jak w przypadku systemu łączności krytycznej, gdzie ogromną różnicę przy wszystkich dostępnych funkcjach nadal stanowi to, czy odbiorca usłyszy słowo “nie” przed “strzelać”, czy też, czy operator wyśle karetkę na czas.

W każdym przypadku jednak warto się starać, bo otacza nas coraz więcej oprogramowania i nie zapowiada się na to, żeby ten trend miał się zmienić. A zatem któregoś dnia to my lub nasi bliscy mogą potrzebować naszego własnego oprogramowania.