… czyli ile trzeba się napracować przed startem właściwego projektu, a jeszcze nie ma żadnej funkcji biznesowej.

Wstęp

Każdy programista zaczynając nowy projekt myśli sobie, że tym razem zrobi wszystko “na świeżo”, z użyciem najnowszych bibliotek i wzorców. Ja postanowiłem sobie spisać funkcje szkieletu aplikacji internetowej, które robiłem w różnych projektach i wydają mi się niezbędne, żeby taka aplikacja była “production-ready”. Lista wyszła zaskakujaco długa, począwszy od podstawowych funkcji biznesowych, przez funkcje administracyjne, wybór elementów stosu technologicznego, a skończywszy na kwestiach bezpieczeństwa i organizacji procesów wytwarzania oprogramowania.

Jak programiści i firmy radzą sobie ze startem projektu, skoro jest aż tak wiele do zrobienia, żeby w ogóle zacząć myśleć o implementowaniu funkcji biznesowych, czyli tym, za co “biznes” właściwie chce płacić?

Wydaje mi się, że rozwiązań jest kilka:

1. Użycie gotowego szkieletu używanego w ostatnim projekcie – zespół go zna, jest sprawdzony i ma większość potrzebnych funkcji, ale może wymagać “odświeżenia” i oczyszczenia z funkcji realizowanych dla poprzedniego klienta i niepotrzebnych u nowego
2. Użycie gotowego szkieletu “open source” np. https://www.jhipster.tech/ – jest elastycznie konfigurowalny i uzywa najnowszych technologii, ale jeżeli zespół go nie zna, to musi się go nauczyć oraz przyzwyczaić do pewnych specyficznych, niekoniecznie intuicyjnych wzorców, możliwe też, że nie będzie mieć wszystkich wymaganych funkcji
3. Użycie gotowych szkieletów komercyjnych, np. SAP Commerce (kiedyś “Hybris”) dla aplikacji e-commerce, jednak moje niewielkie doświadczenie z tego typu produktami jest raczej złe, bo w celu zachowania spójności z istniejącymi wdrożeniami są one bardzo rzadko rewolucyjnie usprawnianie i najczęściej zatrzymują się koncepcyjnie w latach, kiedy były wymyślone
4. Wygenerowanie szkieletu aplikacji z użyciem sztucznej inteligencji – pomysł obecnie atrakcyjny, ale wymaga wiedzy o co trzeba prosić i wiedzy, żeby otrzymany kod zweryfikować, a otrzymane rozwiązanie trzeba bardzo dokładnie przetestować i ewentualne błędy poprawić, pewnie też z użyciem AI.

Pomysłem na moje ćwiczenie jest podejście 4., co spróbuję w kolejnym etapie zrobić. 

Opisane niżej elementy składają się na typową aplikację:

• z częścią publiczną z logowaniem użytkowników i płatnościami “za coś”
• z częścią administracyjną umożliwiającą zarządzanie administratorami i podstawowymi funkcjami systemu
• korzystającą z relacyjnej bazy danych
• budowaną do artefaktów w postaci obrazów Docker umożliwiającą instalację w środowisku chmurowym

Elementy funkcjonalne aplikacji w części publicznej

1. Rejestracja nowego użytkownika z użyciem adresu pocztowego (captcha, wymagane silnego hasła, zabezpieczenie przed zgadywaniem haseł)
2. Akceptacja regulaminów (consents)
3. Uwierzytelnianie (popularnie mówiąc “logowanie”) z użyciem loginu i hasła oraz mechanizmu 2FA (kod jednorazowy przez e-mail i aplikacja 2FA) z uwzględnieniem blokowania tymczasowego i całkowitego po nieudanych próbach, zabezpieczenie przed zgadywaniem haseł, zapamiętywanie urządzenia żeby pomijać 2FA
4. Zarządzanie własnym profilem: zmiana hasła, przypomnienie hasła, zapominanie uwierzytelnionych urządzeń, kasowanie profilu
5. Rejestracja nowego użytkownika i późniejsze uwierzytelnianie z użyciem zewnętrznego konta (SSO) np. Google, Microsoft
6. Płatności online – integracja z jakimś popularnym operatorem płatności np. Przelewy24 w Polsce lub Stripe dla płatności globalnych

Elementy funkcjonalne aplikacji w części administracyjnej

1. Uwierzytelnianie, zmiana hasła, przypomnienie hasła
2. Zarządzanie administratorami
3. Zarządzanie grupami i uprawnieniami administratorów
4. Zarządzanie użytkownikami części publicznej, w tym kasowanie profilu
5. Zarządzanie treściami edytowanymi, które są widoczne w części publicznej – minimalna funkcja CMS, żeby poprawka drobnej literówki (np. w regulaminach, danych kontaktowych, itp.) w nie wymagała poprawki developerskiej i deploymentu aplikacji
6. Zarządzanie zamówieniami/płatnościami
7. Zbieranie i przeglądanie zdarzeń wykonywanych przez innych administratorów (na potrzeby audytów)
8. Zarządzanie szablonami e-maili wysyłanymi przez system
9. Zarządzanie ustawieniami systemu

Elementy techniczne 

1. Minimalny look&feel interfejsu użytkownika: tabele, formularze, menu, kalendarz, powiadomienia, tooltipy, filtry itp.
2. Wsparcie wielojęzyczności
3. Walidacja formularzy i obsługa błędów z API REST: ładny komunikat, unikalny numer błędu pozwalający znaleźć szczegóły w logach
4. Wsparcie RWD, żeby aplikacja działała na różnych urządzeniach
5. Obsługa błędów aplikacji
6. Mechanizm cache dla danych i jego inwalidacja w klastrze
7. Wysyłanie e-maili wraz z możliwością zarządzania ich szablonami
8. Mechanizm uruchamiania zadań wsadowych, np. cyklicznie odblokowujących tymczasowo zablokowane konta
9. Informacja o wersji aplikacji
10. Obsługa upload plików przez administratorów oraz użytkowników części publicznej (z obsługą CDN, skalowaniem obrazków na potrzeby RWD i skanowaniem antywirusowym)
11. Mechanizm migracji modelu danych np. Flyway, Liquibase, itp.
12. Mechanizm dokumentowania API REST, np. Swagger
13. Monitoring aplikacji: wystawienie metryk, zbieranie i wizualizacja danych oraz alarmy
14. Mechanizm analizy logów aplikacji i powiadomienia o anomaliach

Bezpieczeństwo aplikacji

1. Ustawienie poprawnych wymaganych nagłówków HTTP
2. Ustawienie nagłówków związanych z cache’owaniem
3. Obsługa nagłówków Content Security Policy, w tym dla skryptów zewnętrznych zaufanych usług, np. analityka
4. Zabezpieczenie wysyłanych danych przez token Cross-Site Request Forgery (CSRF)
5. Walidacja rozszerzenia i treści plików wgrywanych przez użytkowników
6. Ustawienie poprawnego nagłówka Content-Type dla różnych typów danych

DevOps

1. Utworzenie i konfiguracja repozytorium kodu np. GitHub
2. Środowisko PROD i TEST np. AWS
3. Mechanizm Continous Integration z uruchamianiem testów jednostkowych i integracyjnych
4. Mechanizm Continous Deployment instalujący nowe wersje aplikacji w środowiskach
5. Organizacja procesu Code Review
6. Wdrożenie mechanizmu statycznej analizy kodu, np. SonarQube
7. Wdrożenie mechanizmu weryfikacji licencji bibliotek 
8. Wdrożenie mechanizmu weryfikacji podatności bibliotek

Podsumowanie

Zapewne w zależności od doświadczenia czytającego powyższa lista będzie mniej lub bardziej zrozumiała. Dla laika może wyglądać jak chaotyczne notatki, ale dla kogoś kto ze mną już pracował to będzie prawie kompletna lista zadań do backlogu.

Jak znajdę trochę czasu to zrobię próbę wygenerowania takiej aplikacji z użyciem AI, zobaczymy ile czasu to zajmie i jaki efekt przyniesie.

Jeżeli macie jakieś uwagi lub sugestie, to zapraszam do komentowania.