Bądź eko-programistą.

Tendencje i zagrożenia w rozwoju informatyki.

Praca autorstwa BekaPeka. 

Towarzystwo Ochrony Rozwoju Informatyki.

Polska, Włochy, Niemcy 2024.

Przedmowa:

Jak powstaje obecnie oprogramowanie i co należałoby poprawić w tym procesie, aby spełniało nasze ekologiczne wymagania.

Czy uczy się odpowiedzialności za napisanie własnego kodu?

Podatności, czyli słabo napisany kod powinien być publikowany na wykładach w uczelniach. Jak tego nie robić !

Cykl życia oprogramowania, a praktyka.

Co potrafi oprogramowanie….?

Czy obecny sprzęt musi być dalej rozwijany dla przeciętnego użytkownika…

Zmiany osobowe w zespole

Zmiana decyzji, wizji sponsora, a brak środków do realizacji

Wspieranie programisty narzędziami

Wzrost złożoności oprogramowania

Rozwój sztucznej inteligencji i uczenia maszynowego

Zwiększone zapotrzebowanie na szybkie dostarczanie oprogramowania

Zagrożenia wynikające z rozwoju informatyki

Wnioski

Bibliografia

Informatyka, jako jedna z najszybciej rozwijających się dziedzin nauki i technologii, niesie za sobą zarówno liczne korzyści, jak i wyzwania. Wraz z postępem technologicznym i rosnącą złożonością systemów informatycznych, pojawiają się nowe tendencje oraz zagrożenia, które mogą wpływać na jakość i bezpieczeństwo oprogramowania. W niniejszej pracy zostaną omówione główne tendencje w rozwoju informatyki oraz związane z nimi zagrożenia, wynikające m.in. z nieodpowiednich praktyk programistycznych, braku testowania, braku myślenia o naszej planecie oraz nie weryfikowania źródeł.

Z poważaniem BekaPeka.

Przedmowa:

Rozwój informatyki przynosi wiele korzyści, ale jednocześnie stawia przed programistami i inżynierami oprogramowania nowe wyzwania i zagrożenia. Aby sprostać tym wyzwaniom, niezbędne jest stosowanie dobrych praktyk programistycznych, takich jak efektywne zarządzanie zasobami, gruntowne testowanie oprogramowania oraz weryfikacja źródeł kodu. Ponadto, edukacja i świadomość zagrożeń bezpieczeństwa są kluczowe dla tworzenia bezpiecznego i niezawodnego oprogramowania.

W roku 1996 powstała aplikacja do obsługi piekarni, głównym wymaganiem były wydruki faktur dla konwojenta.  Ten program działał na komputerze 386SX pod kontrolą systemu MS-DOS 6.22  z dyskiem twardym 120 MB z drukarką STAR LC-20. 

Czy taki system mógłby przetrwać do dziś? 

Już nie przetrwa, bo to za wolny obieg informacji jak na obecne czasy. Papier jest teraz  spowalniaczem procesu w dobie internetu szybkiego obiegu informacji i posiadania komputerów, telefonów u każdego w kieszeni, ale czy musi być tak szybko ? Konwojent i tak jutro przyjdzie do pracy, więc drukarka zdąży wydrukować dokumenty …. ale to nie jest ekologicznie … no tak, faktura papierowa wycina nam drzewa Amazonki, więc trudno niech już będzie bez papieru , fakturą elektroniczną na telefon komórkowy konwojenta. Dla Urzędu Skarbowego papier jest również uciążliwy, z jasnych przyczyn kontrola na papierze przebiega wolniej niż na dokumencie elektronicznym.

Z perspektywy roku 1996 (rozkwit komputerów IBM PC) patrzymy na rosnące wielkości pamięci komputerowej i zastanawiamy się czy też stosunkowo więcej funkcjonalności otrzymujemy. Czy obecnie podwojenie, potrojenie daje nam - no właśnie, co nam daje lepszego poza gromadzeniem tej informacji ?  

Oczywiście multimedia, zdjęcia, filmy, muzyka tej pamięci potrzebowały i chyba gromadzenie powoduje, że tej pamięci zużywamy coraz więcej, możemy ją przetwarzać i analizować. Aktualnie nie jesteśmy już w stanie ogarnąć: tej PetaBajtowej ilości i musimy zaangażować AI. 

Zbieramy znaczki, proporczyki, figurki, zabawki, filmy, zdjęcia, ogólnie w informatyce też to robimy … Zbieramy bo… a może się przyda… 

Jak powstaje obecnie oprogramowanie i co należałoby poprawić w tym procesie, aby spełniało nasze ekologiczne wymagania.

Należałoby nauczyć przyszłych programistów jak analizować swój kod pod kątem wydajności. Czy ich ilość odwołań i iteracji jest optymalna, czy nie da się jej już zmniejszyć? Czy panujemy nad wszystkimi iteracjami w pętli , czy umiemy zastosować algorytm z wzorca projektowego, który był już badany wydajnościowo? Czy ich algorytm jest optymalny, czy inny programista może napisać szybszy kod? Jaki narzut na pamięć dyskową, operacyjną i ile cykli procesora zużyjemy ( przy podejściu eko można wyliczyć nawet ile zaoszczędzimy Co2 przy produkcji energii ) Czy wykorzystamy importowaną bibliotekę  w całości - wywołamy wszystkie funkcje i procedury w niej zawarte. Ale nie zawsze da się nie korzystać z biblioteki - sterownik, matematyka ale współcześnie szuka się biblioteki, żeby to, co chcemy zrobić działało, a nie działało optymalnie.

Generalnie przy produkcji dysku HDD SDD też zużywamy energię, więc optymalizacja taka musi  być ekologiczna.  

Czy uczy się odpowiedzialności za napisanie własnego kodu? 

A jeśli już mowa o kopiowaniu i sprzedawaniu tego oprogramowania to co dostaje twórca biblioteki? Jest przecież częścią dzieła. Podarował swoją bibliotekę, ale kto jest odpowiedzialny za błędy w niej znalezione.

Przy zgromadzeniu w swojej działalności programistyczno-twórczej dostatecznej ilości swoich bibliotek i kodu, który znamy i wiemy jak działa powinniśmy umieć podzielić go w taki sposób aby nie był duplikowany i każdy z modułów robił tylko swoją przydzieloną część i nic ponadto.

Stosowanie standardów kodowania i dobrych praktyk programistycznych, takich jak unikanie złożonych konstrukcji czy ograniczenie liczby instrukcji w funkcjach, pomaga w tworzeniu kodu, który jest łatwy do zrozumienia i utrzymania. To jeden z punktów regulaminu programistycznego w NASA.

Ciekawostką może być również fakt, że aby uruchomił się Windows 10 potrzeba kilkanaście tysięcy plików, a DOS 6.22 - UWAGA - Tylko tych trzech:

IO.SYS - Podstawowy plik systemowy odpowiedzialny za podstawową obsługę sprzętu oraz załadowanie systemu operacyjnego.

MSDOS.SYS - Plik systemowy zawierający funkcje systemowe i narzędzia niezbędne do działania DOS-a.

COMMAND.COM - Główny interpreter poleceń DOS, który pozwala użytkownikowi na komunikację z systemem operacyjnym.

Jak tego nie robić!

Podatności - czyli słabo napisany kod powinien być publikowany na wykładach w uczelniach. 

Istnieje wiele repozytoriów podatności (CVE, NVD, ATT&CK).

Repozytorium podatności to centralne miejsce gromadzenia informacji o słabościach i błędach w oprogramowaniu, sprzęcie i systemach. Informacje te obejmują opis podatności, jej wpływ na systemy oraz dostępne rozwiązania.

Repozytoria podatności są cennym źródłem informacji dla osób i organizacji zajmujących się bezpieczeństwem IT. Mogą być wykorzystywane do identyfikacji podatności w systemach: Administratorzy systemów mogą używać repozytoriów podatności, aby sprawdzić, czy ich systemy są narażone na znane luki. Oceny ryzyka. Organizacje mogą wykorzystywać repozytoria podatności, aby ocenić ryzyko związane z różnymi podatnościami i zdecydować, które z nich należy naprawić w pierwszej kolejności.

Cykl życia oprogramowania, a praktyka.

Częstym problemem w procesie wytwarzania jest poprawianie błędów na środowisku produkcyjnym są to fundamentalne zasady, a jednak bardzo często są łamane ze względu na lenistwo, brak czasu, brak finansów.  Każda poprawka powinna przejść ponownie etapy, które są w cyklu życia oprogramowania - proces ten został skonstruowany właśnie po to,  żeby wyeliminować i usystematyzować pracę nad projektem. Na ten cykl składają się - Faza koncepcji, faza wymagania, faza implementacji, faza testów, instalacji lub wycofania instalacji na wersję poprzednią w przypadku niepowodzenia.

Idealnie, zmiany i poprawki powinny przechodzić przez pełny cykl życia oprogramowania, ale w praktyce bywa różnie. Czasem firmy wprowadzają poprawki bezpośrednio na produkcji, zwłaszcza w sytuacjach awaryjnych, aby szybko naprawić krytyczne błędy.Takie podejście niesie ryzyko, ponieważ zmiany mogą wprowadzać nowe błędy lub powodować inne problemy, które mogłyby zostać wykryte podczas testowania. Dlatego najlepsze praktyki zalecają korzystanie z pełnego cyklu życia oprogramowania, z odpowiednim testowaniem przed wdrożeniem zmian na produkcję.

Co potrafi oprogramowanie….

Jeśli już przyjmiemy, na chwilę, że oprogramowanie coś robi i nazwiemy to, że coś potrafi, to musimy sobie uświadomić, że inteligencja jest wynikiem wielu składowych. Nadawanie programom komputerowym cech inteligencji ludzkiej jest nadużyciem. Próbujemy personifikować słownictwo do potrzeb matematyczno-statystycznych algorytmów.

Jest jasne, że niektóre programy są w stanie się modyfikować. Taki GPT to przecież potężne narzędzie korzystające błyskawicznie z ogromnych zasobów. To fakt. Często trudno odróżnić odpowiedzi GPT od odpowiedzi człowieka. Poza tym człowiekowi trudno by było przeszukać zbiory trzystu bibliotek z np. dwudziestoma pięcioma milionami woluminów. Dla GPT to czynność na 0.46 sekundy.

Czy te oraz inne błyskawiczne reakcje programów komputerowych staną się kiedyś inteligencją to nie wiadomo. Na pewno trzeba będzie przedefiniować pojecie inteligencja.

Jeśli jednak intelekt jest tym, co odróżnia nas od innych zwierząt i daje nam przewagę, to co jeśli maszyna przewyższy nas tym swoim intelektem?

Ai w tej chwili ma trudności z następującymi procesami..

Zdolność do rozwiązywania problemów, myślenia logicznego i analizy danych.

Zdolność do generowania oryginalnych pomysłów, myślenia innowacyjnego i twórczego.

Umiejętność stosowania wiedzy w praktyce, rozwiązywania codziennych problemów i podejmowania decyzji w rzeczywistych sytuacjach.

Zdolność do rozpoznawania, rozumienia i zarządzania własnymi emocjami oraz emocjami innych osób.

Zdolność do podejmowania decyzji z niewystarczającymi danymi wejściowymi.

Czy obecny sprzęt musi być dalej rozwijany dla przeciętnego użytkownika…

Tak. Jednak programowanie nie musi wymuszać, ciągle nowego sprzętu ze względu na samo oprogramowanie. Oczywiście, że postęp elektroniczny komputerów będzie miał miejsce. Jednak priorytetem powinna być wygoda i komfort dla użytkownika. A nie podkręcony, najnowszy komputer, żeby obsłużył program. Dlatego sprzęt dla programistów powinien być o jedną generację słabszy niż najnowszy.

Taki podobny zabieg miał już miejsce przy optogramowaniu lotów sond Pathfinder oraz Oportunity i sprawdził się idealnie.

Analiza efektywności programistycznej w odstępach 5 letnich pokazuje, że w latach 2010-2015 wyniki były najlepsze. Dotyczy to , co jest zaskakujące, wszystkich obszarów tj. Windows, Android, Linux, macOS (szczególnie OS X Yosemite), I innych systemów oraz powstałych na nich programów. Nie dotyczy to programistów specjalistycznych. Ponieważ, w tym przypadku ciągle priorytetem jest niezawodność i oczywiste ograniczenia fizyczne sterowników.

Wynik ankiety przeprowadzonej w środowisku informatyków w Polsce:

Przeciętni użytkownicy windows XP nie zauważyli zmian w kolejnych wersjach czyli Windows 7  . 8 ..10 11. Z ich punktu widzenia nie  wnoszą nic nowego, co byłoby dla nich zauważalne i było przyczyną zmiany na wersję kolejną.

Z punktu widzenia informatyka / administratora utrzymującego stacje robocze, nakład pracy w naprawianie systemu drastycznie zmalał przy Windows 7 - przestał się psuć lub zaczął być bardzo odporny na ataki.

Podsumowując aspekt sprzętowy oraz system operacyjny widzimy, że jeżeli coś działa dobrze to należy to wykorzystywać. Tak długo ile jest to możliwe. A nie używać nowości natychmiast. Dopiero życie zweryfikuje przydatność każdej nowości.

Zmiany osobowe w zespole

Jeszcze jest jeden taki aspekt, który poniekąd jest bardzo istotny, a mianowicie wymiana programisty w całym procesie wytwórczym. Czasami zdarza się, że programista nie przetrwa do końca tworzonego oprogramowania i zastępuje go kolejny programista. Ten z kolei ma swoje własne metodyki wykonywania konkretnych zadań. Ma konkretne swoje przygotowane biblioteki, ulubione biblioteki i często dochodzi do krytykowania kodu poprzednika ale programistów takich, którzy wiedzą, co piszą i myślą o swoich następcach jest bardzo niewiele. 

Zmiana decyzji, wizji sponsora, a brak środków do realizacji.

Bardzo często w trakcie pisania kodu, gdy programista będzie miał już wytyczone wymagania do jakiejś konkretnej koncepcji, do konkretnej realizacji bardzo często zlecający zmienia swoją koncepcję przez co w kodzie pojawiają się różne dziwne rzeczy i również często programiści zamiast usuwać to, no po prostu podmieniają w jakiś nieudolny sposób. Ponieważ nie są w stanie, na każdą zachciankę klienta zmienić całkowicie projekt. 

Klient nie zna procesu wytwórczego i nie zdaje sobie sprawy z nakładu jaki musi podjąć dla przykładu analityk, żeby aplikacja była optymalna . Przy budowaniu aplikacji wymagane są tak zwane warsztaty - Grupa programistów wraz kierownikiem projektu wymienia się różnymi koncepcjami, dobierane są algorytmy, biblioteki i analizowane koncepcje projektu.  Proces wytwórczy trzeba rozebrać na czynniki pierwsze i przeanalizować czy dana droga rozwoju spełnia wymogi klienta. 

A jeszcze jednym problemem jest przekonanie klienta do nowych przyzwyczajeń w aplikacji gdy zastosujemy jakieś innowacyjne rozwiązania, a klient tego nie widział. Dochodzi wtedy do negocjacji, żeby wyglądało to po staremu tak jak chce klient, bo stare przyzwyczajenia są sprawdzone i klient nigdy nie wierzy nowemu rozwiązaniu. Przykładowo księgowa, która zawsze pisała ręcznie faktury z kalkulatorem będzie sprawdzała wydruki komputerowe, które wyjdą z obcego programu napisanego przez osobę, której nie zna.

Wspieranie programisty narzędziami 

Narzędziem, które bada kod pod względem jego podatności i potencjalnych błędów jest na przykład sonarcube .  Narzędzie to potrafi analizować wytworzony kod i wskazać miejsca, w których programista powinien poprawić błędy. Specjaliści z BekaPeka sądzą, że narzędzie to niedługo będzie wspomagane sztuczną inteligencją. Aktualnie korzysta ono z gotowych szablonów standardów z ogromnych baz kodów źródłowych, które leżą na przykład na githubie.

Automatyzacja wdrożenia aplikacji to jest już standard . Zdaniem PekaBeka już ten proces nie zmieni się - zaraz po tym jak programista deweloper wyprodukuje kod ten automatycznie kompiluje się i buduje się aplikacja. Jest on automatycznie uruchamiany w środowisku deweloperskim i aplikacja zostaje przekazana testerowi - tester może zacząć od razu testować. 

Tendencja  do kopiowania kodu z internetu, z nieznanych źródeł nie znając algorytmu ani bibliotek jest zasadniczym problemem przy wytwarzaniu oprogramowania. Biblioteki stosuje się jako czarne skrzynki. Te bardzo często mają właśnie podatności czyli słabo napisany kod, który mogą wykorzystać hakerzy żeby dostać się do danych, które aplikacja składuje bądź analizuje.

Jest jeszcze taki problem, który mówi o tym, że klient ma zawsze rację. To klient ma pieniądze. Jak pan nie zrobi tego jak ja to chcę, to pan nie dostanie pieniędzy i programista tworzy dziwoląga, tworzy takie cudo. No tak chciał klient. Nie jest to w żaden sposób optymalne ani nie nadaje się do dalszej sprzedaży, bo było czymś Specyficznym. Czego chciał klient i taka aplikacja, która powstaje była szyta na miarę dla tego konkretnego klienta .

Bardzo ważną osobą, podczas budowania aplikacji jest Projekt Manager czyli osoba, która pilnuje, żeby dana aplikacja miała wymagany kształt i była dobrze napisana oraz zrozumiana przez przyszłych deweloperów. Osób, które będą analizować ten kod, żeby szybko odnalazły się w kodzie i wiedziały co dana biblioteka czy dana funkcja wykonuje. Bardzo ważną też kwestią jest komentarz w kodzie. Stosunkowo bardzo mało jest programistów, którzy komentują swój kod, argumentując to tym, żeby być niezastąpionym. Nie chcą, po prostu pozbywać się pracy. Łatwo przekazywać kolejnemu programiście ułatwień. 

 

Według mnie osoby, które twierdzą, że nie ma co się zastanawiać nad zwięzłością kodu czy oszczędzaniem dysków twardych czy oszczędzaniem czasu procesora - nie są naprawdę ekologiczni .  

A takie jest pytanie kluczowe: 

Jaki kod jest lepszy:

Krótki 

Długi 

Złożony 

Prosty 

Czy taki, który działa???

Według specjalistów z BekaPeka najlepszy kod, jest taki, który działa i to działa optymalnie. Wykorzystując, również, optymalnie pamięć, optymalnie procesor i optymalnie RAM, żeby zużyć jak najmniejszą ilość energii.

Programowanie gdy ma się 32kb pamięci a programowanie bez ograniczenia pamięci - chyba nie trzeba nikogo przekonywać, że im czegoś jest mniej tym bardziej można na tym zapanować. Jest gorzej gdy mamy ograniczone miejsce i nie możemy pomieścić się z naszym projektem wtedy zaczyna się optymalizacja i analizowanie co jest bardziej potrzebne co mniej, dochodzi nieczęsto do sytuacji, że kod skompilowany można jeszcze zoptymalizować znając mapę pamięci i język asemblera. 

Programiści z lat 80 mając komputer 8-bitowy z 64kb pamięci gdzie nie było mowy o rozszerzaniu tej pamięci ponieważ była zintegrowana z komputerem, znali mapę pamięci - pamięć ulotna komputera była podzielona na strony / sekcje odpowiedzialne za wyświetlanie na ekranie, bufory - miejsca do których zapisywane były dane z urządzeń zewnętrznych aby wprowadzić program do komputera, z których czytały urządzenia wyjściowe np. drukarki. Pamięcią stałą była kaseta magnetofonowa lub stacja dysków. Mapa tej pamięci z góry narzucała miejsca do pisania programu, były one do wyboru ale nie było takiej wolności jak jest teraz. Czyli mieliśmy jak gdyby magazyn ale półki do przechowywania były z góry ustalone na konkretne dane czy program. 

Przywołujemy to ponieważ taki super eko-programista musiał od razu porządkować swój program i wiedzieć pod jakim adresem co się znajduje inaczej nie byłby w stanie zapanować nad swoim dziełem.  Adresowaniem - ustalaniem gdzie aplikacja ma się znajdować w pamięci zajmuje się kompilator (kod źródłowy zmienia za jednym zamachem) lub interpreter (wykonuje w locie instrukcje i od razu adresuje).   Obecnie programista nawet nie myśli, że to się wykonuje w tle, a nawet dochodzi do tego, że aplikacja zaraz po zakodowaniu jest od razu instalowana na testowym i potem produkcyjnym środowisku i widzą ją klienci, jest o razu do korzystania.

Poniekąd dostawcy usług chmurowych np. AWS, Google Cloud  zaczynają liczyć zużytą przestrzeń dyskową i moc obliczeniową. Przekłada się to bezpośrednio na pieniądze, więc już zaczynamy być zmuszani do bycia ekologicznymi programistami.

Wzrost złożoności oprogramowania

   W miarę jak aplikacje stają się coraz bardziej złożone, programiści muszą radzić sobie z większą ilością kodu oraz bardziej skomplikowanymi strukturami danych. Tendencja ta prowadzi do tworzenia długich i skomplikowanych programów, które mogą być trudne do zarządzania i utrzymania. Trudność polega na trafnym zorganizowaniu sobie kodu źródłowego, aby projekt zrealizować efektywnie i sprawnie.  Istnieje kilka strategii radzenia sobie z tym problemem:

Modularyzacja - dzielenie aplikacji na mniejsze moduły rozdzielenie funkcji na mniejsze funkcje składowe 

Refaktoryzacja - Cyklicznie przeglądanie kodu i poprawianie go , mile widziane są takie zmiany które nie zmieniają funkcjonalności, a jego czytelność i utrzymanie.

Testowanie - wykonywane automatycznie znacznie przyspiesza wyłapywanie potencjalnych błędów.

Dokumentacja - najbardziej pożądana to taka pisana zaraz w kodzie jako komentarze w odniesieniu do konkretnego kodu. 

Stosowanie wzorców  projektowych - są to rozwiązania sprawdzone dla typowych problemów, które cyklicznie pojawiają się notorycznie w różnych projektach.

Rozwój sztucznej inteligencji i uczenia maszynowego

   Sztuczna inteligencja (AI) i uczenie maszynowe (ML) stają się coraz bardziej powszechne w różnych dziedzinach. Programiści często korzystają z gotowych bibliotek i modeli, co pozwala na szybkie wdrażanie zaawansowanych funkcji, ale jednocześnie może prowadzić do braku zrozumienia działania tych narzędzi.

Niektóre algorytmy uczenia maszynowego są niewyjaśnione, trzymane w tajemnicy (ponieważ leży to w interesie biznesowym ich producentów) lub jedno i drugie. Prowadzi to do ograniczonego zrozumienia uprzedzeń lub błędów, które może popełniać sztuczna inteligencja.

Jeśli kod AI będzie zawierał czarne skrzynki , biblioteki których programista nie rozumie to nietrudno wyobrazić sobie zagrożenia z takiego podejścia. AI to nie tylko sam kod, algorytmy ale i bazy danych którymi jest zasilana i są źródłem analizy, jakość tych danych ma znaczenie. 

…….

Zwiększone zapotrzebowanie na szybkie dostarczanie oprogramowania

   Współczesne metodyki zarządzania projektami, takie jak Agile, Scrum, Kanban, DevOps, Lean kładą nacisk na szybkie dostarczanie oprogramowania. Choć przyspiesza to procesy rozwojowe, może również prowadzić do kompromisów w zakresie jakości i bezpieczeństwa kodu. Statystycznie bardzo często w późniejszych etapach projektu dochodzi do sytuacji, w której grupa projektowa jest pewna, że zbyt mało czasu skupiła na konkretnym modelu bądź integracji. Dlatego też harmonogram nie jest sojusznikiem projektu i warto go aktualizować. 

Zagrożenia wynikające z rozwoju informatyki

1. Brak uwzględnienia ograniczeń sprzętowych

   W obliczu rosnących zasobów sprzętowych, wielu programistów przestaje zwracać uwagę na efektywne zarządzanie pamięcią i zasobami. Piszą oni długie programy, które mogą nadmiernie obciążać pamięć komputerową, prowadząc do problemów z wydajnością oraz stabilnością systemu.

2. Niedostateczne testowanie oprogramowania

 W pośpiechu związanym z dostarczaniem nowych funkcji, programiści często pomijają gruntowne testowanie swoich bibliotek i aplikacji. Brak testów jednostkowych, integracyjnych oraz systemowych może prowadzić do powstawania błędów i luk w zabezpieczeniach, które mogą zostać wykorzystane przez atakujących.

3. Kopiowanie kodu z Internetu bez weryfikacji źródeł

   Programiści często korzystają z kodu znalezionego w Internecie, nie weryfikując jego jakości ani pochodzenia. Kopiowanie niezweryfikowanego kodu może prowadzić do wprowadzenia podatności oraz innych problemów, które mogą negatywnie wpłynąć na bezpieczeństwo i stabilność aplikacji.

4. Brak świadomości zagrożeń bezpieczeństwa

   Programiści skupiają się na dostarczaniu nowych funkcji, często brakuje im czasu i zasobów na naukę o najnowszych zagrożeniach bezpieczeństwa oraz najlepszych praktykach zabezpieczających. Skutkuje to tworzeniem oprogramowania, które jest podatne na różnorodne ataki, takie jak SQL injection, cross-site scripting (XSS) czy ataki typu zero-day.

Wnioski

W miarę jak rozwija się technologia komputerowa rozwijają się również spowalniacze programowe, których zadaniem jest kontrolowanie czegoś, wpisywanie do statystyk i mierzenie przyspieszenia, które, po prostu spowalnia całość konstrukcji.

Inaczej mówiąc: masz kalkulatorek taki jak w latach osiemdziesiątych i do tego urządzenie, które sprawdza poprawność wyników. Czym nowszy kalkulatorek np. Casio tym większy aparat do kontrolowania. Czyli w 2030 roku kupujesz super szybki miniaturowy kalkulator z urządzeniem rejestrująco-kontrolnym rozmiaru telewizora. I oczywiście będzie sam się uczył. Tylko czego? 

Tak widzimy z grubsza, postęp informatyczny i techniczny komputerów.

Ale tak być nie musi.

Bibliografia:

Sommerville, I. (2011). "Software Engineering". Pearson.McConnell, S. (2004). "Code Complete". Microsoft Press.OWASP Foundation. (n.d.). "OWASP Top Ten". Retrieved from https://owasp.org/www-project-top-ten/Martin, R. C. (2008). "Clean Code: A Handbook of Agile Software Craftsmanship". Prentice Hall.