15 lutego, 2018

“Kto nie idzie do przodu, ten się cofa”. Kiedy Goethe wypowiadał te słowa, nie miał pojęcia, jak znamienne będą one kilka wieków później. Oczywiście słynny poeta nie wiedział wtedy, co to jest Internet, ale – jak widać – nie przeszkodziło mu to, w sformułowaniu jednego z najistotniejszych przykazań branży IT. A skoro Goethe był tak miły i przekazał nam swoją mądrość, to dlaczego nie brać jej pod uwagę?

“Kto nie idzie do przodu, ten się cofa.”

– Johann Wolfgang von Goethe

No dobra, tylko czym właściwie jest to owe “zmierzanie do przodu”? Szczególnie czym ono jest w dziedzinie IT oraz z perspektywy projektu widzianego oczami Tech Leadera? O ile samo znaczenie “zmierzania do przodu”, czyli po prostu rozwijania się, jest dość oczywiste, o tyle interpretacja tego w poszczególnych aspektach już niekoniecznie jest oczywistą oczywistością. Aby przybliżyć temat, omówię aspekty pierwszego sortu.

Aktualizacje

Serwisy tworzone są z użyciem najróżniejszych elementów, do których możemy zaliczyć m.in.:

  • języki programowania (np: .NET, Ruby, PHP),
  • technologie (np: HTML5, CSS3, Apache, Haproxy),
  • biblioteki (np: jQuery, gemy Ruby’ego),
  • frameworki (np: Rails, UiKit, Bootstrap),
  • API (REST, JS, SOAP, wszystkie w różnych implementacjach i wersjach).

a także wiele innych składowych. Tak wiele, że szkoda przetworzonego drewna (lub prądu – w końcu mamy online), aby je tutaj wypisywać.

Po prostu grupy mądrych ludzi, postanowiły zrobić narzędzia i je udostępnić, abyśmy za każdym razem nie musieli tworzyć młotka, gdy chcemy zrobić krzesło. Ci sami ludzie zazwyczaj dbają o rozwój tych narzędzi i co jakiś czas wydają ich kolejne, ulepszone oraz zabezpieczone wersje.

Warto aktualizować te elementy także w swoim serwisie (kto by chciał wbijać gwoździe krzywym kamieniem, jak właśnie ukazał się metalowy, idealnie wyważony, młotek?). Oto kilka najistotniejszych powodów:

  • zwiększa to bezpieczeństwo, gdyż kolejne wersje często mają łatane luki bezpieczeństwa lub wprowadzane obsługi nowych sprawniejszych sposobów zabezpieczeń (czyli nie obijemy sobie palca kamieniem, ani nikt nie popsuje nam projektu),
  • rośnie wydajność, ponieważ wraz z następnymi wersjami dochodzą optymalizacje i szybsze rozwiązania (np. młotek ma większą powierzchnię, więc trafienia młotkiem są celniejsze),
  • poszerzają się możliwości, a ewentualne dalsze prace nad oprogramowaniem mogą przebiegać szybciej (czyli młotek może mieć końcówkę do wyciągnięcia źle wbitego gwoździa i gumowaną rączkę),
  • kolejne wersje często mają też usunięte wykryte dotychczas błędy (np. w naszym młotku nie będzie już odpadał trzonek :D).

Oczywiście bywa, że aktualizacje do kolejnej wersji wprowadza tak dużo zmian, że wymaga to dużo zmian i adaptacji po stronie pozostałych elementów. Trzeba wtedy wyważyć decyzję pomiędzy potrzebami, rozsądkiem, możliwościami i mocami przerobowymi. Reasumując – aktualizujmy jak najwięcej, ale z głową.

Rozwój i usprawnianie kodu

Skoro autorzy bibliotek, frameworków i technologii i tych wszystkich wspaniałości z poprzedniego rozdziału, mogą aktualizować i usprawniać swoje dzieła, to dlaczego my byśmy mieli nie móc zrobić tego samego ze swoją aplikacją? Ano możemy i nawet powinniśmy.

 

Optymalizacja

Wyobraźmy sobie, że nasz serwis zyskuje na popularności, a klienci, żądni naszych produktów, walą drzwiami i oknami (przeglądarki rzecz jasna). Po prostu Black Friday i klienci zombie :). Jeszcze wczoraj serwis działał szybko i wydajnie, a dziś? No cóż… niespieszno mu do jakichkolwiek akcji, a na każde zapytanie odburkuje mało przyjemnym błędem 502. Nie jest to najpiękniejszy scenariusz.

Kod całego serwisu warto optymalizować, gdyż pozwoli to na szybsze jego działanie w przypadku nagłego większego obciążenia (np. wzrost liczby odwiedzających, spowodowany promocją lub mailingiem). Przyspieszy to też operacje, które mogą być istotne z punktu widzenia czasu wykonania i oczekiwania na odpowiedź (np. częste prace administracyjne, proces zakupowy, okresowe generowanie danych dla narzędzi zewnętrznych). Poza tym szybko działający serwis to mniej odrzuceń i większy współczynnik konwersji.

Łatki i poprawki

Łatanie serwisu, to jeszcze istotniejsza rzecz. Ale zaraz? Jak to łatanie? Mój serwis jest bezbłędny! Otóż nie, niestety nie jest. Każda aplikacja miała, ma i będzie mieć luki i błędy. To jest nie do uniknięcia. Nawet takie tuzy jak amerykańska mało-miękka firma od okien czy wujek Google wydają łatki do swoich programów, i to jeszcze na długo po ich premierze. A zapewniam, że mogliby tak bez końca (gdyby im się opłacało). Co więcej – luki występują nawet w kwestiach sprzętowych (więcej na ten temat na pewno mogą powiedzieć m.in. fachowcy z Intela, gdy spytacie ich o Meltdown i Spectre). Krótko mówiąc – nie robi błędów, ten kto nic nie robi.

Tak więc, jak już wiemy, że luki i błędy są, istotniejszą kwestią staje się co z nimi robić? Jeżeli to luki bezpieczeństwa, to odpowiedź jest jedna: łatać Panie, łatać. W pozostałych przypadkach zdecydowanie dobrym zwyczajem także jest łatanie, ale pilność już zależy od specyfiki błędu. Jednakże prędzej czy później ów błąd też powinien być załatany, a nie – jak to często bywa – zapomniany. Poprawki działania serwisu pozwolą nam przede wszystkim na:

  • zachowanie bezpieczeństwa użytkowników i nie tylko (co w kontekście zbliżającego się RODO, jest bardzo istotne),
  • prawidłowe realizowanie danych funkcjonalności (np. wyeliminowanie problemów występujących w szczególnych przypadkach),
  • zwiększenie wydajności (niektóre błędy, mogą spowodować spadek wydajności).

Refaktoryzacja

No dobra, zoptymalizowaliśmy, połataliśmy. Coś jeszcze? Tak, coś jeszcze. Nasz kod warto też refaktoryzować. Tylko co to znaczy? Ano tyle, że część kodu realizująca jakąś funkcjonalność można napisać zwięźlej, czytelniej i krócej. Po co? Aby przy rozbudowywaniu tej funkcjonalności, można było to zrobić szybciej i sprawniej, bez tracenia zbędnego czasu na utrudnioną analizę kodu. Szybsze będzie też debugowanie i oszacowywanie ewentualnych zmian, a w niektórych przypadkach refaktoryzacja otwiera nowe możliwości rozwoju danej funkcjonalności (np. po refaktoryzacji, dołożenie paginacji wyników jest znacznie prostsze w realizacji).

Weźmy przykład z życia: kiedyś by wyrobić dowód, trzeba było w jednym okienku to zgłosić, potem z druczkiem iść do drugiego okienka piętro wyżej, gdzie należało ów druczek dać i opłacić, potem z potwierdzeniem wpłaty idziemy do kolejnego okienka na jeszcze innym piętrze, aby wreszcie odebrać potwierdzenie zgłoszenia o dowód, a sam dowód był do odebrania później (sic!).

Załóżmy, że z jakichś powodów wszystko musi być załatwiane w tych 3 osobnych okienkach. Tylko dlaczego nie zrobić wszystkich 3 okienek kolejno obok siebie i z informacją, nad nimi, o kolejnych krokach? Pójdźmy dalej – okienko na wpłaty zastępujemy automatem. W poprzednim scenariuszu musimy najpierw odnaleźć to okienko i dopiero wtedy je podmienić na automat. W poprawionym scenariuszu odnalezienie się w sytuacji jest znacznie prostsze – od razu wiemy gdzie jest, które to okienko i czy nasz automat się zmieści i czy może warto wstawić nie jeden, a dwa takie automaty. To tylko jeden z wielu pomysłów na refaktoryzację i optymalizację, tego przypadku.

Jak widać wszystkie te elementy (refaktoryzacja, optymalizacją, poprawki) często się ze sobą łączą. Jeżeli zadbamy o kod teraz (optymalizując, łatając, refaktoryzując), to wszelkie konieczne później prace (poważniejsze łatki, wdrożenia, analizy) będą po prostu szybsze, programiści będę popełniali mniej błędów, a szacowania i wyceny wdrożeń trafniejsze. Żyć nie umierać.

Serwisowanie

Hola, hola! Jakie serwisowanie? Przecież komputery, technologia i czarna magia programistów powinny być samowystarczalne. Niby tak, ale nie do końca ;). Ktoś musi te automaty poustawiać, a następnie nadzorować. Ponieważ nasz serwis się zmienia, to i automatyzacja powinna się dostosowywać do tych zmian. Poza tym nie wszystko da się (albo jest sens) automatyzować. Spójrzmy na samochody. Zawierają układy samosmarujące, samodiagnostyczne, komputery i inne bajery, a i tak co jakiś czas Pan Henio musi wymienić olej, przeczyścić filtry, dysze itd. Z serwisami jest podobnie (no dobra, Pan Henio nie wymienia w nich oleju).

Aplikacje także wymagają co jakiś czas prac serwisowych: kontroli plików, usunięcia zbędnych plików tymczasowych, wpisów w bazie, archiwizowania dzienników aktywności itd. Sprzątanie po szybkich pilnych zmianach/poprawkach, awariach i innych losowych przypadkach.

Jeżeli klient wybrał opcję premium, to serwis jest stworzony w taki sposób, że część takiego diagnozowania i serwisowania jest robiona automatycznie. Ale w to trzeba zainwestować już na początku i nadal jest to część tych prac.

Zarządzanie repozytorium

Stan kodu aplikacji na daną chwilę, przechowywany jest w tzw. repozytorium (np SVN, Git). To jak zmienia się nasza aplikacja (a właściwie jej kod) jest zawarte w repozytorium w postaci tzw. gałęzi, zawierających zapis zmian względem poprzednich stanów (tzw. commity). Dzięki temu wszystkie prace nad aplikacją wychodzą z ustalonego stanu aplikacji, a zmiany są dołączane do znanego nam stanu. To sprawia, że cały cykl prac jest poukładany i czytelny.

Zarządzanie repozytorium, czyli m.in.:

  • przegląd zmian,
  • usuwanie zbędnych gałęzi,
  • dołączanie zmian,
  • aktualizowanie informacji o nich,
  • wiązanie istotnych punktów z opisami zmian i zleceń,

mimo iż nie dotyczy bezpośrednio aplikacji, też jest ważnym elementem.
Higiena pracy z repozytorium ma istotny wpływ na:

  • szybkość pracy deweloperów ,
  • szybkość wprowadzenia zrealizowanych zmian na produkcję,
  • operowanie zmianami (np wycofanie),
  • debugowanie (pozwala zawęzić zakres zmian do sprawdzenia),
  • adaptację zmian między serwisami,
  • tworzenie dokumentacji.

Administrowanie

Naturalną rzeczą jest, że podczas działania serwisu mogą pojawiać się problemy spowodowane m.in. takimi czynnikami jak:

  • awarie sprzętu,
  • awarie w firmach hostujących nasz serwis,
  • awarie sieci,
  • wzrost zapotrzebowania wydajności.

Reagowanie na te sytuacje, zmiany parametrów hostingu, albo zaprojektowanie lub zmiany architektury na serwerze (gdzie baza danych, gdzie serwis lub inne mikroserwisy, czy redundantne czy nie itd.), to też element wymagający trzymania ręki na pulsie.

 Na przykład jeżeli jakaś usługa (dajmy na to API naszego serwisu) powoduje stałe okresowe wzrosty obciążenia, to aby pozostałe usługi (np panel kliencki) nie odczuwały tych obciążeń za bardzo, warto odizolować pracę API od panelu. Inną możliwą korzyścią jest redundantny układ wirtualnych maszyn, dzięki czemu jeśli jedna padnie, jej prace przejmie tymczasowo (do momentu przywrócenia poprzedniej) druga maszyna, a użytkownik nawet nie zauważy różnicy. Możliwości tutaj jest sporo i powinny być dostosowywane do ciągłych zmian oraz szyte na miarę, a krawcem jest właśnie osoba administrująca tym wszystkim.

Zmiany rozwojowe

Z czasem pojawiają się nowe, skuteczniejsze oraz przystępniejsze sposoby komunikacji z użytkownikiem, nowe sposoby i formy serwowania treści oraz nowe standardy wizualne. Ciągłe nadążanie za tymi zmianami zapewnia, że nie zostaniemy w tyle, a nasza strona będzie sprawiała profesjonalne wrażenie i lepiej dotrze do użytkownika.

Serwisy, których wygląd i funkcje nie zmieniają się od lat sprawiają wrażenie, że autor o niej zapomniał. O niej i o użytkownikach. Daje to odczucie, że biznes właściciela przestaje być intratny, a i sama firma i jej produkty/usługi przestają jawić się jako mocno i pewnie osadzone na rynku.

“Dzisiejsza technologia i dzisiejsze rozwiązania, jutro są już nieaktualne.”

Ciągłe ulepszanie serwisu, przemyślane zmiany funkcjonalności, usprawnianie interfejsu i UX, tworzenie nowych narzędzi dla klientów oraz reagowanie na ich potrzeby i sygnały, są dzisiaj niezbędnymi elementami prowadzenia biznesu. Gdy o tym zapomnimy klienci odwrócą się w kierunku konkurencji, która jest na bieżąco z obowiązującymi trendami. Dodatkowo napływ serwisów zagranicznych i praktycznie brak barier krajowych w Internecie, zwiększa konkurencję i przyspiesza napływ nowych rozwiązań pojawiających się na rynku. Jeżeli chcemy być konkurencyjni, musimy za nimi nadążać, a najlepiej sami wyznaczać przemyślane standardy. Z drugiej strony ludzie lubią to, do czego są przyzwyczajeni. Lawirowanie pomiędzy tymi dwoma stanami (nowe rozwiązania vs stare przyzwyczajenia) jest nie lada wyczynem. Dlatego szukanie nowych rozwiązań powinno być poparte badaniami środowiskowymi i przemyślaną strategią, a nie samą sztuką dla sztuki.

Przy planowaniu zmian, należy patrzeć perspektywicznie. Reguła “good enough” sprawdza się tylko na ten moment. Zaoszczędzenie na zmianach dziś, może znacznie utrudnić (i w efekcie zwiększyć koszty) wprowadzenie zmian jutro, a w skrajnych przypadkach praktycznie uniemożliwić ich wdrożenie. Dlatego tak ważne są konsultacje z działem IT i znalezienie rozwiązania optymalnego od strony technicznej oraz biznesowej.

Reakcje na zmiany inne

Często serwisy wymagają zmian z innych przyczyn niż wcześniej opisane, np prawnych (wymóg powiadamiania o cookies, to tylko jeden z najmniejszych przykładów) lub biznesowych (np ekspansja na inne rynki). Modyfikacja oprogramowania pod tym kątem jest wtedy niezbędna i warto ją rozplanować w czasie, zamiast odkładać na ostatnią chwilę. Już w momencie gdy spodziewamy się, że takie zmiany nastąpią, warto zawczasu o nich pomyśleć i przedyskutować z IT. Dzięki temu będzie można tak zaprojektować inne planowane zmiany, aby nie kolidowały one z tą przewidywaną później, a samo wdrożenie nie będzie realizowane w zbędnym pośpiechu.

Podsumowanie

Teraz, kiedy wiemy na jak wielu płaszczyznach możemy rozwijać i pielęgnować nasz serwis, trzeba to wszystko zebrać w całość i rozplanować. Nie raz, nie dwa razy, a stale, bo praca nad serwisem, to ciągła droga przed siebie. Ważne aby wszystkie prace nad rozwojem serwisu prowadzić regularnie i z możliwie jak najdalszym planowaniem. Pozwoli to zredukować ilość sumarycznej pracy nad serwisem. Nie okaże się wtedy, że np wprowadzenie jednej funkcjonalności wymaga gruntownego przebudowania wielu innych. Należy mieć też w pamięci, że coś co wydaje się proste, może jednak wymagać wielu dodatkowych zmian, lub być niewykonalne w założonym budżecie. Dlatego wręcz niezbędną staje się konieczność stałej, jasnej i uczciwej komunikacji z działem IT. Czego życzę wszystkim stronom – wszak płyniemy na tym statku razem 🙂

Adam Kutrasinski

Inne artykuły tęgo autora

Adam Kutrasinski
27 marca, 2018
Adam Kutrasinski
15 lutego, 2018
Adam Kutrasinski
15 lutego, 2018