Gdyby robotnicy budowali budynki tak jak programiści piszą programy to pierwszy dzięcioł, który by nadleciał, zniszczyłby całą cywilizację.

Powyższy cytat to dosyć popularne powiedzenie, które można często usłyszeć przy okazji rozmów o jakości projektów informatycznych. Na pewno jest ono fajnym bon motem, ale czy zawiera w sobie choć ziarno prawdy? Odpowiem po internetowemu: nie sądzę.

Ależ jak to? - ktoś może odkrzyknąć - dokładnie tak jest, programy się zawieszają z byle powodu, psują dane albo zwracają błędne wyniki. Co by było gdyby budowle się tak zachowywały?

No cóż - odpowiem przewrotnie w ten sposób - gdyby inwestorzy podchodzili do budowy domu, tak jak do realizacji projektu IT, to rzeczywiście budowlanka stanowiłaby dla nas śmiertelne zagrożenie.

A mówiąc mniej żartobliwie, pomiędzy zasadami funkcjonowania konstrukcji budowlanych a sposobem działania programu komputerowego nie ma żadnego przełożenia. Żadnej analogii, dzięki której można by uznać, że przytoczony na wstępie cytat niesie za sobą jakąś mądrość.

Czym się różni wznoszenie budynku od tworzenia programu komputerowego

Zacznijmy od różnicy najmniej istotnej - powtarzalności procesu. Wznoszenie domu jest procesem wysoce powtarzalnym: każdy kolejny budynek jest tworzony cegła po cegle, słup po słupie, strop po stropie. Strop na pierwszej kondygnacji nie różni się od stropu na drugiej i kolejnych. Słupy mają w większości te same przekroje, zalewane są tym samym betonem i zbrojone tą samą stalą.

W przypadku programu komputerowego także występują pewne powtarzalne procesy - można przyjąć, że w większości aplikacji występują elementy wspólne, jak logowanie użytkowników, jednak jest ich zdecydowanie mniej. Każdy program, każda aplikacja mobilna jest inna, gdyż w odróżnieniu od wznoszenia takich samych domów, tworzenie takich samych aplikacji mija się z celem.

Znacznie bardziej istotny jest natomiast fakt, iż po rozpoczęciu robót budowlanych w projekcie nie zachodzą żadne fundamentalne zmiany. Owszem, przesuwa się okno albo zmienia kolor elewacji, ale czy możecie sobie wyobrazić sytuację, gdy po wylaniu fundamentów inwestor dochodzi do wniosku, że wolałby jednak zrobić garaż dwustanowiskowy, zamiast poddasza "pierdyknąć" dwa piętra, a obrys domu powiększyć, bo mu się inaczej wszystkie bibeloty na półkach nie pomieszczą?

No cóż, w IT takie fundamentalne zmiany są chlebem powszednim. Przesunięcie okna można porównać do przesunięcia przycisku logowania na ekranie, a zmianę koloru elewacji do zmiany wyglądu ikonki. Ale produkcja programowania mierzy się z dużo większymi wyzwaniami - zmiana procesu zakupowego w sklepie internetowym to jak zmiana poddasza na dwa piętra, a dodanie dodatkowego kroku podczas rejestracji użytkownika to z kolei jak przebudowanie garażu jednostanowiskowego na taki, który mieści dwa samochody.

Dodatkowo, nie przegapmy faktu, iż konstrukcja budynku jest wysoce redundantna - nie istnieje w niej jeden pojedynczy element, którego wyjęcie spowoduje, że dom się rozpada (odpowiednik zawieszenia się programu). Dziura w ścianie, wymontowanie drzwi, a nawet niespodziewany wybuch spowodowany eksperymentami młodego chemika, zwykle nie kończą się katastrofą budowlaną. Czy można napisać tak odporne oprogramowanie? No cóż, można, i tworzy się takie oprogramowanie dla krytycznych systemów, od których na przykład zależy zdrowie i życie ludzi. Jednak nikt nie inwestuje w taki poziom zabezpieczenia dla zwykłych aplikacji użytkowych, gdyż gdyż koszt takiego zabezpieczenia byłby wielokrotnie wyższy od ceny podstawowego rozwiązania.

Na koniec warto jeszcze wspomnieć o kwestii zależności pomiędzy oprogramowaniem a zewnętrznymi usługami. Obecnie mało który program jest monolitem, który do działania nie wykorzystuje żadnych zewnętrznych usług. Większość aplikacji działa obecnie w połączeniu z internetem, wymieniając intensywnie różnego rodzaju dane i korzystając z zewnętrznych dostawców.

W budowlance zależności te są zdecydowanie mniejsze, a co więcej, konsekwencje problemów po stronie dostawcy są zrozumiałe dla każdego. Gdy następuje awaria transformatora i w budynku nie ma prądu, nikt nie wysuwa żądań w kierunku architekta, aby coś z tym zrobił. W przypadku oprogramowania natomiast, specyfiką branży jest, iż zamawiającego nie interesuje przyczyna problemu - program ma działać, a jeżeli nie działa, to odpowiedzialność ponosi najczęściej jego autor.

Wszystkie wymienione powyżej argumenty jednak nic nie znaczą w obliczu prawdziwego trupa. Albowiem...

Prawdziwy trup chowa się w szafie

A dokładniej w czymś, co programiści nazywają środowiskiem uruchomieniowym. Aby wyjaśnić moją myśl, pozwolę sobie na takie odważne stwierdzenie: prawa fizyki są inne dla budynków, a inne dla programów komputerowych.

Dom jest budowany w środowisku, w którym obowiązują ogólne prawa fizyki i podejście bardzo analogowe. Nic się nie stanie, jeżeli ściana będzie o 5 mm krótsza albo beton o 2% chudszy niż w specyfikacji. Jeżeli murarz położy co 5 cegłę nieco krzywo, bo miał gorszy dzień, to również nie wpłynie to na konstrukcję całości, a jedynie będzie wymagało nieco więcej tynku do zakrycia fuszerki.

Program komputerowy jest natomiast uruchamiany na procesorze, dla którego coś jest jedynie białe albo czarne. Jest jeden albo zero. Liczba 11 nie jest dla procesora w żaden sposób podobna do liczby 111, a mała litera ‘a’ to zupełnie inny symbol niż duże ‘A’. Program, moduł czy funkcja, aby w ogóle się uruchamiały, muszą być napisane bezbłędnie na poziomie składni. To znaczy, w sytuacji gdy programista zrobi jedną, jedyną w całym kodzie, zwyczajną literówkę, to w momencie wykonania tego kodu program się albo zawiesi, albo z bardzo dużym prawdopodobieństwem graniczącym z pewnością, zwróci niepoprawne dane. Tutaj nie da się położyć grubszej warstwy tynku, która przykryje błąd.

Ze względu na ten ten zero-jedynkowy sposób działania komputerów, programy są także nieodporne na zmiany w środowisku, które nie zostały z góry przewidziane. W budynku, jeżeli wściekły sąsiad wyrąbie wam dziurę w ścianie, nawet jeżeli byłaby to ściana nośna, to najpewniej nic złego się nie stanie. Ale jeżeli nazwa funkcji w zewnętrznej bibliotece, z której program korzysta, zmieni się z refreshProject na reloadProject, to program się wyłoży.

Czy można pisać programy tak, aby były bardziej odporne? Można, wracamy jednak do pytania, ile to będzie kosztować i czy faktycznie klient chce za to zapłacić...

Jedno jest pewne. W KISS digital dbamy o jakość naszych projektów i zawsze dokładnie je wyceniamy. Chcesz się o tym przekonać?