Aplikacje

Postrzegam aplikacje jako zdigitalizowaną formę narracji prowadzącą użytkownika poprzez dane miejsce w celu osiągnięcia danego celu.

Aplikacje są dla mnie zdigitalizowanym dostępem do danego zbioru historii które stały za jej powstaniem przy pomocy określonych komponentów które są odległe od historii opowiadanej przez twór jakim jest aplikacja.

Esencją aplikacji jest historia według której jest budowana. To ona nadaje kierunek zachowaniom użytkownika, jego intencjom oraz końcowemu doświadczeniu — zanim jeszcze napisze się pierwszą linię kodu. Istnieje cienki podział między zachowaniem technicznym a narracją: to pierwsze powinno służyć tej drugiej, nie ją kształtować.

Spójność narracyjna, jasno określeni aktorzy i przewidywalne skutki ich działań — to niepodważalna podstawa każdej aplikacji. Aplikacje mogą wymieniać fragmenty narracji z innymi aplikacjami dedykowanymi do wzajemnej komunikacji, ale powinny pozostać oddzielnymi historiami — scalającymi się tylko wtedy, kiedy to konieczne. (Czy ty mi tu właśnie API opisujesz?)

Każda aplikacja prędzej czy później wyodrębnia różne miejsca — tak jak udajemy się do bankomatu albo oddziału banku zależnie od tego, co chcemy zrobić.

Komponenty w aplikacjach bywają powtarzalne - według ich odpowiedzialności oraz spójności, nie według frameworka, zewnętrznego serwisu czy języka którego użyto do implemenntacji - patrząc w ten sposób nasuwa się oczywiste stwierdzenie że “Wszystko jest kurwa mać takie samo!”.

Namiastą czynności które uważam za powtażalne oraz miałem okazję pracować dotychczas to między innymi:

Implementacja AuthN (JWT, OAuth 2.0, Passwordless, Basic) wraz z AuthZ (RBAC, ACL) do zarządzania dostępem do zasobów. Zarządzanie kontem użytkownika: dane osobowe w bazie, zmiana nazwy użytkownika, emaila, hasła, przywracanie hasła, dezaktywacja i permanentne usunięcie konta — zgodnie z OWASP.
Zarządzanie profilami do reprezentacji użytkownika — oddzielonymi od kont używanych do autentykacji, otwartymi na integrację z zewnętrznymi serwisami (CRM, ERP).
Modelowanie danych według indywidualnych modeli biznesowych, z wykorzystaniem schema.org dla zachowania struktury zrozumiałej bez wysiłku kognitywnego.
Logowanie i telemetria do zbierania informacji o realnych zdarzeniach w domenie aplikacji — z poziomami hierarchii, nie płaskim dumpem.
Konfiguracja aplikacji w sposób schodkowy: plik wsadowy, pliki konfiguracyjne, zmienne środowiskowe, sekrety, API — spójna, udokumentowana, z domyślnymi ustawieniami pozwalającymi uruchomić aplikację po wyjęciu z pudełka.
Implementacja wewnętrznego systemu płatności niezależnego od dostawcy (Stripe, gotówka) — z rozróżnieniem między dostawcą, metodą płatniczą dostępną dla użytkownika i historycznym zapisem transakcji aktualizowanym przez eventy w czasie rzeczywistym.

Zwracjąc uwagę na standaryzację, separację odpowiedzialności oraz ekosystem programistyczny faworyzowałem biblioteki których stabilne utrzymanie oraz audyty są czymś z czego warto korzystać kiedy takowe rowiązywały problem z którym miałem doczynienia co bezdyskusyjnie wymaga poprawnej identyfikacji problemu oraz (płytszego… ale wciąż) zrozumienia implementowanego rozwiązania.

Kod jest warstwą odpowiedzialności — tak jak projekt graficzny, model danych czy decyzja o tym, które funkcje w ogóle wchodzą do produktu. Każda z tych warstw ma swoją wagę i każda może zawalić cały system jeśli jest zaniedbana. Kiedy jako główny programista mówiłem że “nie obchodzi mnie kod źródłowy”, miałem na myśli że nie zarządzam przez kod — tak jak architekt nie trzyma w ręku młotka. To nie znaczy że jakość wykonania jest mi obojętna. Znaczy że widzę więcej niż jedną warstwę naraz.