Jak podejść do nowoczesnego programowania WordPress (część 2)

Opublikowany: 2022-03-11

WordPress jest najczęściej używaną technologią witryn na świecie i nie bez powodu. Jednak przestarzały kod w swoim rdzeniu jest bałaganem, a problem ten spływa kaskadą na deweloperów zewnętrznych. Niektórzy programiści biorą to za wymówkę, by pójść na skróty we własnym kodzie WordPress PHP, ale to podejście jest droższe na dłuższą metę w przypadku wszystkich, z wyjątkiem najbardziej trywialnych zmian.

W części 1 naszej dwuczęściowej serii skupiliśmy się na ogólnych narzędziach projektowych i przepływach pracy, a następnie na rozwoju front-endu. Teraz nadszedł czas, aby wziąć byka za rogi i zmagać się z PHP: W szczególności, jak postępować zgodnie z najlepszymi praktykami podczas pracy z back-endowym kodem WordPress. Możesz pomyśleć o tym jako o samouczku PHP/WordPress, ale nieco bardziej zaawansowanym, z założeniem, że wykonałeś już pewne dostosowanie zaplecza WordPress.

Jakie zatem zasady projektowania nowoczesnych programów i funkcje PHP zapewnią Ci najlepszą wartość za Twój czas? Oto 10 praktyk programistycznych WordPress i PHP, które bardzo polecam.

Najlepsza praktyka rozwoju nowoczesnego WordPressa nr 1: Postępuj zgodnie z „separacją obaw”

Rozdzielenie obaw oznacza, że nie należy mieszać ze sobą części kodu WordPress PHP o różnych funkcjach lub przeznaczeniu. Zamiast tego powinny być zorganizowane w odrębne sekcje lub moduły, przekazujące sobie dane przez zdefiniowany interfejs. ( Interfejs to zestaw zdefiniowanych parametrów, które moduł przyjmuje jako dane wejściowe i co zwraca z powrotem.) Ściśle powiązanym pojęciem jest zasada pojedynczej odpowiedzialności : każdy moduł kodu (lub funkcja) powinien być odpowiedzialny tylko za jedną rzecz.

Ostatecznym celem przestrzegania tych zasad jest stworzenie kodu, który jest modułowy, a zatem możliwy do utrzymania, rozszerzalny i wielokrotnego użytku.

To było całkiem niezłe, więc spójrzmy na przykład WordPressa PHP (z rdzenia WordPressa), który łączy wszystko w całość. Ten styl kodowania jest często nazywany „kodem spaghetti”, ponieważ zrozumienie jego wewnętrznego działania jest prawie niemożliwe. Poniższy fragment został zredagowany dla zwięzłości; zachowano jednak oryginalny styl i formatowanie.

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

Przede wszystkim jest to całkowicie niezrozumiałe. I podoba mi się, że jedyny komentarz to End foreach , który jest całkowicie zbędny. Mamy zapytania do bazy danych, przetwarzanie wyników zapytań, dodatkowe przetwarzanie osadzone w HTML (jest tam zagnieżdżone if / else , jeśli nie zauważyłeś), ucieczki wyjścia i szablony HTML wszystko połączone. Innym problemem jest parametr $id pochodzący bezpośrednio z globalnego $_REQUEST , w przeciwieństwie do przekazywania rzeczywistego parametru do funkcji.

Patrząc na to, jest całkowicie zrozumiałe, dlaczego rdzeń WordPressa od lat pozostaje taki sam. Refaktoryzacja tego rodzaju kodu — zwłaszcza przy zachowaniu istniejącego zachowania — to naprawdę epickie zadanie, którego nikt nie chciałby wykonać.

Jak więc robimy to właściwie? Cóż, należy pamiętać, że nie ma jednej prawdziwej drogi. Wspomnieliśmy powyżej cechy, do których powinniśmy dążyć: Potrzebujemy niestandardowego kodu PHP WordPress, aby był łatwy w utrzymaniu i modułowy. Spójrzmy, jak możemy podzielić powyższy kod na moduły.

Zapytania SQL powinny oczywiście znajdować się w osobnym module. WordPress ma już ładnie abstrakcyjną klasę WP_Query , której należy użyć jako przykładu.
Cały kod HTML trafia do szablonu. Szablony PHP omówimy poniżej.
Pozostały kod PHP powinien być opakowany w funkcję — kilka funkcji, jeśli kod jest zbyt długi lub zbyt złożony dla jednej funkcji. Parametry takie jak $id są przekazywane przez argumenty funkcji.

To jest znacznie uproszczone przepisanie powyższego przykładu:

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

Nowoczesna najlepsza praktyka programowania WordPress nr 2: unikaj zmiennych globalnych

WordPress ma zbyt wiele zmiennych globalnych. Dlaczego zmienne globalne są złe? Sprawiają, że kod WordPress PHP jest trudny do naśladowania, a stan aplikacji jest zawodny. Każdy fragment kodu PHP — a to oznacza każdą wtyczkę, która jest zainstalowana w WordPress — może odczytywać i zapisywać zmienne globalne, więc nie ma gwarancji, że zawierają prawidłowe dane. Próba zrozumienia, jakie zmienne globalne są używane w czymś takim jak Pętla, również nie jest trywialnym zadaniem.

Spójrzmy na to z praktycznego punktu widzenia. Ten przykład pochodzi z WooCommerce. Prawdopodobnie każdy programista WordPress wie, co to jest — pętla:

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

Powyższy fragment kodu renderuje szablon produktu. Skąd wie, jaki produkt ma pokazać, skoro do wc_get_template_part nie są przekazywane żadne parametry? Patrząc na szablon, widzimy, że zaczyna się od global $product; , więc to tam jest przechowywany bieżący obiekt produktu.

Teraz wyobraź sobie, że mamy stronę katalogu, która wyszukuje i filtruje produkty, i chcemy wyświetlać wyskakujące okienko „szczegóły produktu”, pozostając na tej samej stronie. Za kulisami skrypt frontonu wykonuje żądanie AJAX, aby uzyskać ten konkretny szablon produktu. Nie możemy po prostu wywołać wc_get_template_part('content', 'single-product') , ponieważ nie używa parametrów, więc musimy ustawić kilka zmiennych globalnych, aby to zadziałało.

Bardziej złożone przypadki użycia obejmowałyby więcej niż jeden szablon, haki uruchamiane w tych szablonach i wtyczki innych firm dodające swoje wywołania zwrotne do tych haczyków. Może szybko się nasilać. Nie wiemy, na jakim stanie globalnym polegają te wywołania zwrotne. Wtyczki innych firm mogą dowolnie modyfikować dowolną zmienną globalną w swoich wywołaniach zwrotnych. Zamiast korzystać z systemu, zaczynamy z nim walczyć, napotykając na dziwne błędy, które pochodzą z niewiarygodnego stanu globalnego.

Czy nie byłoby rozsądniej przekazać ten identyfikator produktu jako parametr? Wtedy moglibyśmy ponownie użyć tego szablonu, nie martwiąc się o zepsucie zmiennych globalnych używanych przez WordPress.

Nowoczesna najlepsza praktyka programowania WordPress nr 3: Użyj programowania obiektowego (OOP)

Modułowość prowadzi do koncepcji obiektów i programowania obiektowego. Na bardzo podstawowym poziomie OOP jest sposobem organizowania kodu. Funkcje i zmienne są łączone w klasy i nazywane odpowiednio metodami i właściwościami klas. Podręcznik wtyczki WordPress zaleca używanie OOP do organizowania niestandardowego kodu PHP WordPress.

Ważną zasadą w OOP jest ograniczanie dostępu do metod i właściwości — lub w terminologii PHP, oznaczanie ich jako private lub protected — tak, aby tylko inne metody klas miały do nich dostęp i mogły je zmieniać. Terminem OOP na to jest enkapsulacja : dane są enkapsulowane wewnątrz klasy, a jedynym sposobem na zmianę tych danych jest użycie dostarczonych metod klasy.

Dzięki temu debugowanie i utrzymanie kodu jest znacznie łatwiejsze niż w przypadku korzystania ze zmiennych globalnych, które można modyfikować w dowolnym miejscu w całej bazie kodu. Rozważ globalną zmienną post WordPress. Możesz uzyskać do niego dostęp z dowolnego miejsca w kodzie, a wiele funkcji zależy od jego użycia. Co by było, gdybyś mógł ograniczyć modyfikacje tylko do podstawowych funkcji WordPressa, ale czytanie byłoby dozwolone dla każdego? Ukrywanie lub hermetyzacja globalnej zmiennej post w klasie i budowanie interfejsu wokół niej umożliwiłoby to.

To tylko bardzo podstawowy opis OOP i tego, jak można go wykorzystać w nowoczesnym programowaniu WordPress. Do dalszych badań gorąco polecam e-book Carla Alexandra, Odkryj programowanie obiektowe przy użyciu WordPressa, który zawiera najbardziej obszerną i użyteczną treść dostępną na temat OOP w WordPressie.

Ważne jest, aby pamiętać, że OOP nie jest srebrną kulą: zły kod można napisać za pomocą OOP tak łatwo, jak za pomocą dowolnego innego paradygmatu programowania.

Zagłębmy się w konkretne porady dotyczące używania PHP do programowania WordPress.

Nowoczesna najlepsza praktyka PHP nr 1: Celowanie w PHP 7.0+

Korzystanie z nowoczesnych funkcji PHP wymaga, no cóż, nowoczesnej wersji PHP. Po prostu nie ma powodu, aby wspierać wersje PHP starsze niż 7.0. Nawet rdzeń WordPressa będzie wymagał PHP 7.0 już pod koniec 2019 roku.

Niemniej jednak dobrą praktyką jest sprawdzenie wersji minimalnej, aby uniknąć „białego ekranu śmierci” w niekompatybilnych środowiskach. Poniższy fragment kodu pokazuje użycie nagłówka wtyczki do zadeklarowania minimalnej wersji PHP z warunkiem ochrony w kodzie.

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

Nowoczesna najlepsza praktyka PHP nr 2: Przyjęcie standardów branżowych PHP (przewodnik po stylu kodowania PSR-2)

PSR to rekomendacje publikowane przez PHP Framework Interop Group. Są one de facto standardami branżowymi w każdym nowoczesnym przepływie pracy PHP i można śmiało powiedzieć, że społeczność PHP jako całość przestrzega tych standardów. PSR-2 to rekomendacja opisująca styl kodowania. Popularne frameworki PHP, takie jak Symfony i Laravel, podążają za PSR-2.

Dlaczego miałbyś używać PSR-2 zamiast standardu kodowania WordPress? Głównie dlatego, że standardy WordPressa są przestarzałe i nie używają żadnej z nowszych funkcji językowych. To zrozumiałe, ponieważ rdzeń WordPressa musi przestrzegać własnych standardów. Do niedawna musiał obsługiwać PHP 5.2, a PSR-2 nie jest kompatybilny z PHP 5.2.

Może nie jest to oczywiste, ale nie ma wymogu używania standardów kodowania WordPress, chyba że angażujesz się w sedno. Nie byłoby problemu z przesłaniem wtyczki zgodnej ze standardem PSR-2 do katalogu wtyczek WordPressa. W rzeczywistości istnieje kilka bardzo dobrych argumentów, aby to zrobić.

Nowoczesna najlepsza praktyka PHP nr 3: Użyj silnika szablonów PHP

PHP nie jest silnikiem szablonów. Zaczęło się jako jeden, ale potem przekształciło się w w pełni funkcjonalny język programowania i nie ma powodu, aby nadal używać go do tworzenia szablonów. Dwa najpopularniejsze silniki szablonów dla PHP to Twig i Blade, z których korzystają odpowiednio Symfony i Laravel. W tym artykule wykorzystamy Twig jako przykładowy silnik szablonów; jednak Blade ma porównywalne funkcje i funkcjonalność. Błagam, abyście przyjrzeli się obu i sami zadecydowali, co najbardziej wam odpowiada.

Poniższy przykład porównuje szablon PHP i odpowiadający mu szablon Twig. Wyświetlanie i unikanie danych wyjściowych jest szczególnie gadatliwe w przykładzie PHP:

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

W Twig jest to bardziej zwięzłe i czytelne:

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

Główne zalety Twig to:

Czytelna i zwięzła składnia
Automatyczne wyjście wyjścia
Rozszerzenie szablonu poprzez dziedziczenie i bloki

Pod względem wydajności Twig kompiluje się do szablonów PHP i praktycznie nie ma żadnych dodatkowych kosztów. Twig ma tylko podzbiór konstrukcji języka PHP ograniczony tylko do tworzenia szablonów. Zmusza to programistów do usunięcia logiki biznesowej z szablonów, wymuszając w ten sposób separację obaw.

Istnieje nawet Twig dla WordPressa. Nazywa się Timber i jest świetnym sposobem na rozpoczęcie tworzenia lepszych szablonów. Motyw Timber starter jest doskonałym przykładem organizacji motywów w sposób OOP.

Nowoczesne najlepsze praktyki PHP nr 4: Użyj kompozytora

Composer to menedżer zależności dla PHP. Jest to narzędzie, które pozwala zadeklarować biblioteki, z których korzysta projekt, a następnie zautomatyzować ich pobieranie, instalację i aktualizację. Następnie wystarczy dołączyć vendor/autoload.php zamiast ręcznie wymagać każdej biblioteki.

Wtyczki i motywy WordPress często nie korzystają z bibliotek innych firm. Wynika to częściowo z tego, że WordPress ma rozbudowany interfejs API, który spełnia prawie każdą potrzebę, a częściowo z powodu możliwych konfliktów wersji. Rozważ dwie wtyczki wymagające tej samej biblioteki PHP, ale różnych jej wersji. Wtyczka, która jest uruchamiana jako pierwsza, otrzymuje poprawną wersję, a druga wtyczka również pobiera tę wersję. Jest to całkiem możliwe, że jest to kolejna sytuacja z białym ekranem śmierci.

Aby uniknąć konfliktów, zarządzanie zależnościami powinno być stosowane na poziomie aplikacji, tj. witryny WordPress jako całości. To właśnie robi Roots (a dokładniej Bedrock). Używany na poziomie pakietu (wtyczki lub motywu), Composer może powodować konflikty podczas korzystania z bibliotek innych firm. To znany problem. Jedynym rozwiązaniem, które jak dotąd istnieje, jest zmiana nazw przestrzeni nazw tej zewnętrznej biblioteki na coś unikalnego, a to nie jest trywialne zadanie.

Kompozytor nadal ma jednak zastosowanie: automatyczne ładowanie własnych klas. Ale zanim przejdziemy dalej z automatycznym ładowaniem, musimy zaznajomić się z przestrzeniami nazw PHP.

Współczesna najlepsza praktyka PHP nr 5: Użyj przestrzeni nazw

Rdzeń WordPressa jako projekt odziedziczony wykorzystuje globalną przestrzeń nazw lub, mówiąc inaczej, w ogóle nie ma przestrzeni nazw. Wszelkie klasy lub funkcje zadeklarowane globalnie (czyli nie wewnątrz innej klasy lub funkcji) są widoczne w dowolnym miejscu w całym kodzie. Ich nazwy muszą być unikalne nie tylko w obrębie Twojej bazy kodu, ale także dla wszystkich wtyczek i motywów, które są używane teraz lub mogą być używane w przyszłości.

Kolizja nazw (np. zadeklarowanie funkcji o nazwie, która już istnieje) zwykle prowadzi do białego ekranu śmierci, a tego nie chcemy. Kodeks WordPressa radzi, aby wszystkie funkcje i klasy poprzedzić czymś wyjątkowym. Więc zamiast prostych nazw klas, takich jak Order , otrzymujemy coś w rodzaju Akrte_Awesome_Plugin_Order , gdzie „Akrte” jest unikalnym przedrostkiem, który właśnie wymyśliłem.

Przestrzenie nazw mogą być postrzegane jako grupy — lub foldery, jeśli użyjemy analogii z systemem plików — które pomagają uporządkować kod i uniknąć kolizji nazw. Możesz mieć złożone przestrzenie nazw oddzielone ukośnikiem, podobnie jak foldery zagnieżdżone. (Przestrzenie nazw PHP używają w szczególności ukośnika odwrotnego).

Te części przestrzeni nazw są nazywane podprzestrzeniami nazw. Nasza przykładowa klasa Akrte_Awesome_Plugin_Order miałaby Akrte\Awesome_Plugin\Order , gdyby została wykonana przy użyciu przestrzeni nazw. Tutaj Akrte i Awesome_Plugin są częściami przestrzeni nazw (lub podprzestrzeniami nazw), a Order to nazwa klasy. Następnie możesz dodać instrukcję use i używać później tylko nazwy klasy. Zdecydowanie lepiej wygląda:

 use Akrte\Awesome_Plugin\Order; $a = new Order;

Oczywiście przestrzenie nazw powinny być unikalne; dlatego powinniśmy nadać pierwszej „głównej” podprzestrzeni podrzędnej unikatową nazwę, która zwykle jest nazwą dostawcy. Na przykład klasa WC_REST_Order_Notes_V2_Controller może zostać ponownie wykonana z takimi przestrzeniami nazw:

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

Baza kodów WooCommerce używa obecnie przestrzeni nazw; na przykład w WooCommerce REST API w wersji 4.

Nowoczesna najlepsza praktyka PHP nr 6: Użyj autoloadera

W większości przepływów pracy PHP typowym sposobem łączenia plików PHP jest użycie instrukcji require lub include . Wraz z rozwojem projektu otrzymujesz dziesiątki require w głównym pliku wtyczki. Autoloader automatyzuje dołączanie plików i robi to tylko w razie potrzeby. Z technicznego punktu widzenia jest to funkcja, która require pliku sa zawierającego klasę lub funkcję, gdy zostanie po raz pierwszy napotkana w kodzie. Nie ma już require ręcznego dodawania instrukcji required.

Często występuje również znaczny wzrost wydajności, ponieważ autoloader ładuje tylko moduły, które są używane w określonym żądaniu. Bez autoloadera cała baza kodu jest uwzględniana, nawet jeśli żądanie wykorzystuje tylko, powiedzmy, 10 procent kodu.

Funkcja autoloadera musi wiedzieć, w których plikach znajdują się Twoje klasy i funkcje. I jest do tego standard PHP-FIG, PSR-4.

Mówi, że część przestrzeni nazw, prefiks, ma odpowiadać folderowi podstawowemu. Podprzestrzenie nazw, które następują po nim, odpowiadają folderom w folderze podstawowym. Wreszcie nazwa klasy odpowiada nazwie pliku. Przykładowa klasa Akrte\AwesomePlugin\Models\Order wymagałaby poniższej struktury folderów:

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

Prefiks przestrzeni nazw Akrte\AwesomePlugin\ odpowiada folderowi includes określony w konfiguracji autoloadera omówionej poniżej. Podprzestrzeń nazw Models ma odpowiadający folder Models , a klasa Order jest zawarta w Order.php .

Na szczęście nie ma potrzeby samodzielnego wdrażania funkcji autoloadera. Composer może stworzyć dla Ciebie autoloader:

Zainstaluj kompozytora
Utwórz plik composer.json w folderze głównym swojego projektu. Powinien zawierać te wiersze:

 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }

Uruchom composer install .
Dołącz plik vendor/autoload.php na górze głównego pliku PHP wtyczki w następujący sposób:

 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

Oprócz przestrzeni nazw, najnowsza baza kodu WooCommerce używa również autoloadera Composera.

Po omówieniu tych zasad projektowania PHP nadszedł czas, aby powiązać wszystkie nasze lekcje PHP z dostosowywaniem zaplecza WordPress z jedną ostateczną rekomendacją.

Nowoczesna najlepsza praktyka programowania WordPress nr 4: Rozważ użycie stosu root

Roots to najbardziej wszechstronny współczesny przepływ pracy programistyczny WordPress. Powiedziałbym jednak, że niekoniecznie powinien być używany w każdym projekcie WordPress, ponieważ:

Korzenie muszą być używane od samego początku. Tak naprawdę to najczęstszy powód. Refaktoryzacja istniejącego projektu byłaby zbyt kosztowna.
Jest uparty. Dobrze, gdy się zgadzasz, źle, gdy się nie zgadzasz. Możesz na przykład preferować inne sposoby organizowania swojego motywu. Opiniowane projekty wymagają również czasu, aby nauczyć się „na swój sposób”.
Nie wszyscy o tym wiedzą. Programista, który przyjdzie po ciebie, aby utrzymać witrynę, którą zbudowałeś za pomocą stosu Roots, może nie mieć pojęcia, co to jest i zastanawiać się, co się stało z folderami WordPress. Powinniśmy pomyśleć o innych programistach WordPress.

Ogólnie rzecz biorąc, chciałbyś w pełni zrozumieć wszystkie zalety i wady każdego mocno opiniowanego projektu, zanim zdecydujesz się go użyć.

Nowoczesne zasady PHP i oprogramowania: tworzenie solidnego back-endu WordPress

Jest dość oczywiste, że nie ma jednego prawdziwego sposobu pisania oprogramowania. Koncepcje, takie jak oddzielenie obaw, mają dziesiątki lat; jednak to, co to oznacza praktycznie zawsze było kwestionowane. Weźmy na przykład CSS. Na początku wstawiliśmy go jako style w HTML, a potem zdecydowaliśmy, że oddzielne arkusze CSS są tym, o co chodzi w separacji obaw.

Przewiń do przodu o dekadę: dzisiejsze aplikacje JavaScript wykorzystują komponenty jako implementację separacji obaw. Programiści front-end skłaniają się ku CSS-in-JS, a to w zasadzie oznacza ponowne wbudowanie CSS w HTML (cóż, to nie jest takie proste, ale masz pomysł). Krąg jest kompletny!

Najlepsze praktyki zawsze dotyczyły poprawy doświadczenia programistów:

Programy muszą być napisane, aby ludzie mogli je czytać, a jedynie przypadkowo, aby mogły się uruchamiać maszyny.
Abelson & Sussman, Struktura i interpretacja programów komputerowych

Niektóre z praktyk w tym samouczku PHP WordPress są szybkie i łatwe do wdrożenia w Twoim projekcie. Na przykład autoloader: Zrób to raz na projekt i po prostu ciesz się. Z drugiej strony, nowe pomysły na architekturę oprogramowania wymagają czasu, praktyki i wielu iteracji, aby były wygodne i wygodne. Nagrody są jednak znacznie większe. Nie tylko będziesz bardziej wydajny w tym, co robisz, ale także będziesz cieszyć się tym, co robisz bardziej. A regularne czerpanie radości z pracy, którą wykonujesz dla klientów, jest prawdopodobnie jedynym sposobem, w jaki może to być zrównoważone.