1. 1. Legacy code – co to takiego?
2. 2. Legacy code – co zrobić z takim kodem?
3. 3. Refactoring kodu – narzędzia
4. 4. Rector PHP – pogromca legacy code?
5. 5. Refaktoryzacja – jakie mamy możliwości w takim przypadku?
6. 6. Zmiana architektury kodu
7. 7. Dlaczego Rector, a nie IDE?
8. 8. Rector – konfiguracja
9. 9. Rector a kod legacy – podsumowanie

Legacy code – co to takiego?

Zanim przejdę do opisania możliwości Rectora, chciałbym w kilku zdaniach nakreślić, czym jest legacy code i jakie są najczęściej wybierane sposoby radzenia sobie z tymże problemem. W sieci trafimy na wiele definicji legacy code. W dosłownym tłumaczeniu legacy code oznacza nic innego, jak „kod dziedziczony”, czyli kod, który de facto otrzymujemy w spadku po innych programistach, na przykład w momencie dołączenia do nowego projektu. Taki kod budzi lęki i obawy – kod działa, lecz nie znamy jego zawiłej logiki. Szczególny postrach sieje trudny do zrozumienia i okiełznania spaghetti code. Legacy code to również kod, który… piszemy w danej chwili, ale nie został jeszcze pokryty testami, zatem nie jest przygotowany na zmiany w przyszłości. Według mnie każda z powyższych definicji opisuje istotę problemu.

Legacy code – co zrobić z takim kodem?

W pracy z legacy code mamy do wyboru podejścia, które albo minimalizują jego wystąpienie, albo usuwają taki kod całkowicie. Możemy zatem zastosować takie rozwiązania jak refactoring kodu lub całkowicie go przepisać. Refactoring kodu dotyczy optymalizacji jego małych fragmentów, bez zmiany podstawowej funkcjonalności, drugie podejście wymaga przepisania całego kodu aplikacji na nowo, z uwzględnieniem aktualnych standardów.

Przeczytaj także:

• Clean Architecture
• Behavior-Driven Development
• Test-Driven Development

Refactoring kodu – narzędzia

Jak już wspomniałem we wstępie, mamy obecnie wiele narzędzi umożliwiających walkę z długiem technologicznym w kodzie PHP. Wśród narzędzi do refaktoryzacji można wymienić takie jak:

• PHP_CodeSniffer,
• PHP CS Fixer,
• PHP-Parser,
• PHPStan,
• Psalm,
• Rector.

Które z narzędzi wybrać? Wszystko zależy od tego, czego zespół programistów potrzebuje w danym momencie oraz tego, czy narzędzie spełnia nasze oczekiwania. Jednym z decydujących czynników będzie też znajomość danego narzędzia przez członków zespołu developerskiego. Jedne z powyższych narzędzi przeprowadzają analizę statyczną kodu, drugie modyfikują go zgodnie z aktualnymi standardami, a jeszcze inne umożliwiają obie te rzeczy – tak jak właśnie Rector.

Rector PHP – pogromca legacy code?

Rector pojawił się w 2017 roku, a inicjatorem jego powstania był Tomasa Votruba. Rector to program CLI (Command Line Interface) na licencji open source, oparty na  komponentach

Symfony. To narzędzie, które poza analizą statyczną kodu dokonuje też jego zmiany. Podstawowe zastosowania Rectora to sprawna i szybka aktualizacja i refaktoryzacja kodu, a także zmiana architektury aplikacji.

Refaktoryzacja – jakie mamy możliwości w takim przypadku?

W przypadku aktualizacji i refaktoryzacji możemy tutaj wymienić takie możliwości jak:

• migracja z PHP 5.3 do PHP 8.1,  
• migracja z Symfony 2.8 do Symfony 4.4,  
• usuwanie tzw. martwego kodu (ang. dead code, czyli kodu, który nigdy nie będzie wykorzystany),
• zmiana nazw klas, metod, parametrów.
  

Zmiana architektury kodu

Co do zmian architektury, zmiana fasady w Laravel na DI czy przeniesienie aplikacji z TYPO3 na Symfony. Oczywiście współczesne IDE umożliwiają refaktoryzację kodu, jednak mogą działać wolno i być skomplikowane w obsłudze. W przypadku wykorzystywania wyrażeń regularnych do wyszukiwania fragmentów kodu mogą znajdować nie wszystkie wystąpienia lub wręcz przeciwnie – wyszukiwać znacznie więcej. Kopiowanie i wklejanie przez programistę także może być obarczone pewnym błędem wynikającym ze zmęczenia czy rozkojarzenia.

Dlaczego Rector, a nie IDE?

Rector nie zrobi nic, na co nie pozwoli programista! Opiera się na regułach (to zdefiniowane, pojedyncze „przepisy”, które dokonują pojedynczej zmiany w kodzie), zgrupowanych w zestawy reguł wykonujących zmiany o zbliżonej charakterystyce.

Pojedyncze reguły:

• ArrayKeyFirstLastRector,
• IsCountableRector,
• JsonThrowOnErrorRector.

Zestawy reguł:

• PSR4,    
• Php70,
• Php71, TypeDeclaration,
• DowngradePhp71.

W momencie pisania artykułu Rector udostępniał około 660 reguł, zebranych w ponad 48 zestawów.

Rector – konfiguracja

Zasada działania Rectora jest bardzo prosta – zaczynamy od zainstalowania narzędzia i jego konfiguracji. Rector w pierwszej kolejności wyszukuje wszystkie pliki wskazane przez programistę, następnie, analizując każdy z nich z osobna, buduje dla nich AST (Abstract Syntax Tree), tzw. drzewo abstrakcji składniowej. Do każdego takiego drzewa stosuje zdefiniowane przez programistę w pliku konfiguracyjnym reguły. Gdy cały proces zostanie przeprowadzony, w konsoli otrzymujemy raport dotyczący naniesionych zmian. Warto wspomnieć, że Rector nie opiera się wyłącznie na domyślnych regułach – narzędzie umożliwia tworzenie własnych, bardziej wyspecjalizowanych. 

/** @var SplFileInfo[] $fileInfos */
foreach ($fileInfos as $fileInfo)  {
    // 1 file => nodes
    /** @var Parser $phpParser */
    $nodes = $phpParser->parse(file_get_contents($fileInfo->getRealPath()));
    // nodes => 1 node
    foreach ($nodes as $node) { // rather traverse all of them
        /** @var PhpRectorInterface[] $rectors */
        foreach ($rectors as $rector)  {
            foreach ($rector->getNodeTypes() as $nodeType)  {
                if (is_a($node, $nodeType, true))  {
                    $rector->refactor($node);
                }
            }
        }
    }
}

return static function (
    ContainerConfigurator $containerConfigurator
): void {
    // get parameters
    $parameters = $containerConfigurator->parameters();
    $parameters->set(Option::PATHS, [
        __DIR__ . '/src'
    ]);
    // Define what rule sets will be applied
    $containerConfigurator->import(SetList::CODE_QUALITY);
};
ChangeArrayPushToArrayAssignRector
class SomeClass
  {
      public function run()
      {
          $items = [];
-         array_push($items, $item);
+         $items[] = $item;
      }
  }

CombinedAssignRector
-$value = $value + 5;
+$value += 5;
DateTimeToDateTimeInterfaceRector
class SomeClass {
-    public function methodWithDateTime(DateTime $dateTime)
+    /**
+     * @param DateTime|DateTimeImmutable $dateTime
+     */
+    public function methodWithDateTime(
         DateTimeInterface $dateTime
     ){
         return true;
     }
}
SimplifyArraySearchRector
-array_search("searching", $array) !== false;
+in_array("searching", $array);

Kod legacy – podsumowanie

Pracy z legacy code nie sposób uniknąć, prędzej czy później każdy programista spotka się z nim w projekcie. Dobrze jest znać możliwości, jakie w zakresie refaktoryzacji kodu dają dostępne narzędzia, takie jak Rector. Mam nadzieję, że przekonałem was do poznania jego możliwości – a jeśli chcecie dowiedzieć się więcej, zachęcam do obejrzenia mojego wystąpienia na DrupalCamp Poland 2021:

Przejdź do:

1. 1. E-commerce – od czego zacząć?
2. 2. Nikt nie obiecywał, że będzie łatwo
3. 3. Najważniejsze wzorce projektowe w e-commerce
4. 4. Pomyślę o tym później – czyli antywzorce projektowe
5. 5. Podsumowanie

E-commerce – od czego zacząć?

Próg wejścia w przypadku programowania systemów e-commerce, ze względu na ich złożoność, jest dużo większy niż w przypadku pisania systemu od podstaw. Żeby zacząć rozwijać taką aplikację, potrzebne są więc spora wiedza i doświadczenie. Tworząc taki system, można dużą część funkcjonalności pokryć funkcjami “out of the box”, jakich nam dostarcza jego wersja domyślna. Natomiast modyfikacje takiego systemu wymagają już sporej wiedzy na temat jego budowy i funkcjonowania.

Pracę nad aplikacją e-commerce dobrze jest zacząć od szkolenia z zakresu programowania w danej technologii. W ten sposób zdobywamy podstawową wiedzę na temat dobrych praktyk programowania w projekcie. Często zdarza się, że systemy e-commerce wykorzystują gotowe frameworki służące do pisania aplikacji. Złożoność takich systemów jest duża, jednak owocuje to korzyściami dla programistów i użytkowników. Otrzymujemy potężne aplikacje, które są bardzo elastyczne oraz mają spore możliwości konfiguracyjne dla użytkownika obsługującego je od zaplecza.

Czytaj także: Frameworkowe wojny

Nikt nie obiecywał, że będzie łatwo…

Poruszanie się w gąszczu wzorców nie należy do najłatwiejszych. Ponadto jedna funkcjonalność może wpływać na drugą i trzeba wcześniej upewniać się co do wdrażanych modyfikacji w systemie. Warto też pamiętać, że wszystkie modyfikacje należy wykonywać zgodnie z zasadami. Dlatego właśnie moim zdaniem utrzymywanie systemów e-commerce jest trudniejsze niż ich pisanie.

Duże systemy e-commerce napisane w technologii PHP, takie jak Magento czy Shopware, korzystają z bibliotek Symfony i Zend. Na rynku mamy wiele podobnych rozwiązań gotowych do instalacji i rozbudowy. Niektóre systemy oferują wprawdzie wersję enterprise dla bardziej wymagających klientów, jednak licencja jest zazwyczaj kosztowna i przeznaczona dla dużych systemów. Warto więc rozważyć kastomizację, która będzie tańsza i będzie w pełni spełniać wymagania naszej firmy. Co ważne, na rynku narzędzi e-commerce zaczęły się już pojawiać systemy, które można łatwo skalować w chmurze AWS, Google Cloud lub Azure. Idealnie więc jest mieć rozwiązanie, które pozwala na migrację pomiędzy chmurami. Aby stworzyć tak skomplikowany system, trzeba trzymać się sztywnych reguł pisania aplikacji. Jak więc ułatwić sobie pracę?

EXPERT KNOWLEDGE

Read on to discover the importance of Scrum's value of respect.

Read article

Najważniejsze wzorce projektowe w e-commerce

Wzorców projektowych w pisaniu systemów informatycznych jest mnóstwo i nie chciałbym się skupiać na wymienianiu wszystkich. Postaram się przybliżyć najważniejsze z nich, które przynoszą największe korzyści pod względem jakości kodu. Oto kilka wzorców projektowych, bez których stworzenie jakiejkolwiek aplikacji komercyjnej byłoby wręcz niemożliwe.

Wyróżniamy trzy rodzaje wzorców projektowych:

Kreacyjne

Opisują one procesy tworzenia nowych obiektów, do ich zadań należą także wszelkie czynności związane z ich konfiguracją oraz tworzeniem typów danych.

• Property – to najbardziej podstawowy z wzorców kreacyjnych. Służy głównie do przetrzymywania konfiguracji, jest to bardzo ważne ze względu na to, że eliminuje ryzyko duplikowania wartości konfigurujących oraz ułatwia późniejsze modyfikacje i utrzymywanie kodu.
• Abstract factory – jest wzorcem, który może posłużyć w budowaniu aplikacji, określa on interfejs do tworzenia różnych obiektów należących do tego samego typu (domeny).
• Factory method – jest podobnym wzorcem do abstract factory. Również określa interfejs, z tym, że odnosi się do różnych metod zamiast obiektów.
  

  Strukturalne

  Definiują struktury powiązanych ze sobą obiektów.

• Adapter – to przykład wzorca strukturalnego, który może posłużyć obsługi niezgodnych interfejsów w obiektach. Jego zadaniem w takim przypadku jest umożliwienie komunikacji takich obiektów.
• Facade – to kolejny wzorzec strukturalny. Przechowuje on mapę obiektów wraz z możliwością ich obsłużenia. Implementacja tego wzorca może odbyć się przez stworzenie klasy oraz osadzenie w niej wszystkich obiektów, które realizują konkretną logikę aplikacji.
  

  Czynnościowe

  Opisują wzajemne zależności pomiędzy obiektami.

• Observer – to jeden z popularnych wzorców czynnościowych. Służy on do obsługi zdarzeń w aplikacjach i dzięki niemu aplikację można łatwo rozszerzać. Przykładem takiego zdarzenia w systemie e-commerce może być moment wystawienia faktury za transakcję. Przykładowo, programista w zależności od wymogów biznesu może zaprogramować jakąś akcję po wystawieniu faktury, np. dodatkowe powiadomienie dla pracownika sklepu.
• Dependency injection – kolejnym wzorcem czynnościowym jest dependency injection. Polega on na „wstrzykiwaniu” zależności jednego obiektu do drugiego oraz wykonywanie na nim operacji, na podstawie których jest realizowana logika aplikacji. Pozwala na usuwanie zależności pomiędzy danymi komponentami.

Pomyślę o tym później – czyli antywzorce projektowe

Pisząc o wzorcach w e-commerce, chciałbym wspomnieć także o antywzorcach projektowych, których również jest sporo.

• Gold plating – ciekawym antywzorcem projektowym jest gold plating, czyli tzw. złocenie. Mamy z nim do czynienie w sytuacji, gdy prace nad projektem lub zadaniem trwają dłużej, niż jest to wymagane (np. z powodu ciągłego ulepszania funkcjonalności i chęci dostarczenia klientowi jeszcze lepszego produktu). W pewnym momencie zostaje jednak przekroczony punkt krytyczny, w którym dodatkowy wysiłek nie przynosi wartości dodanej w projekcie.
• We’ll handle it later – przykładem równie skrajnym jest wspomniane we’ll handle it later, czyli tzw. „Na tym etapie bym się tym nie przejmował”. Antywzorzec ten stosowany jest, gdy analiza danego zadania lub projektu nie została wykonana prawidłowo lub nie została przeprowadzona w ogóle.
• U mnie działa – kto z nas nie słyszał choć raz w życiu „U mnie działa?”. To często spotykane stwierdzenie można często spotkać przy uruchomieniu aplikacji na różnych systemach operacyjnych lub przy w różnych środowiskach klienckich. A przecież warto zbadać każde zgłoszenie – ignorowanie problemów na początkowym etapie może mieć dalsze konsekwencje na późniejszych etapach projektów.
• Hard code – tzw. umieszczenie w kodzie tej samej zmiennej w kilku miejscach, co drastycznie wpływa na późniejsze utrzymanie takiej aplikacji.

Podsumowanie

Systemy e-commerce nie tracą na popularności i dają duże możliwości zarówno użytkownikom, jak i programistom. Aby nie pogubić się w ich złożoności i w pełni wykorzystać ich potencjał, warto wystrzegać się opisanych przeze mnie antywzorców i pogłębiać swoją wiedzę na temat dobrych praktyk. Nie tylko w programowaniu przekładają się one na najlepsze rezultaty. Mam nadzieję, że opisane przeze mnie przykładowe wzorce zachęcą Was do poznania kolejnych i stosowania ich w projektach.

Przejdź do:

1. 1. Frameworki – zalety i wady
2. 2. Jak prawidłowo korzystać z frameworków?
3. 3. Podejście multi-framework
4. 4. Podsumowanie

Na rynku dostępnych jest wiele rozwiązań dla wykorzystywanej przeze mnie technologii, nie jest więc trudno wybrać najbardziej odpowiedni dla konkretnego projektu lub odpowiednio do osobistych preferencji. Przyjrzyjmy się wszystkim obszarom programowania, w których można używać frameworków.

Można je zastosować w takich obszarach, jak:

• Kompilatory różnych języków programowania – chodzi o programy do automatycznego tłumaczenia kodu napisanego w jednym języku na odpowiadający mu kod w drugim języku,
• Aplikacje do modelowania finansowego,
• Aplikacje do modelowania typu Earth Science Applications (ESA),
• Systemy wspomagające podejmowanie decyzji – systemy dostarczające informacje i wiedzę,
• Aplikacje webowe – programy komputerowe, które działają na serwerach za pośrednictwem sieci komputerowych i łączą się z komputerami użytkowników za pomocą przeglądarki internetowej,
• Middleware – oprogramowanie pośredniczące pomiędzy różnymi aplikacjami, usługami lub systemami.

Na rynku oprogramowania mamy obecnie wiele rozwiązań gotowych do użycia, a większość z nich oparta jest na frameworkach. Zapewniają one bardzo przejrzystą i sformalizowaną architekturę, aby umożliwić programistom dokonywanie dalszych modyfikacji oraz zorganizowaną pracę w grupie. Taka budowa oprogramowania charakteryzuje się wysokim poziomem złożoności. Warto jest jednak się uczyć tych technologii i rozwiązań, ponieważ mogą one przyspieszyć zarówno twoją pracę, jak i pracę całego zespołu. Przyjrzyjmy się temu jeszcze bardziej szczegółowo i spójrzmy na listę zalet i wad frameworków.

Czytaj także: Clean Architecture

Frameworki – zalety i wady

Zalety:

• Wydajność – dzięki budowaniu aplikacji przy użyciu frameworka programista pisze mniej kodu,
• Lepsza jakość kodu – ponieważ frameworki są zaprojektowane w taki sposób, by zapewnić elastyczność, mają dobrą logikę wewnętrzną i narzucają tę samą logikę stworzonej aplikacji,
• Niezawodność – frameworki takie jak szkielety aplikacji są dobrze zaprojektowane i przetestowane.

Wady

• Złożoność – frameworki są trudniejsze do nauki ze względu na szerokie i zaawansowane użycie,
• Wydajność – elastyczna konstrukcja utworzonego oprogramowania często uzyskiwana jest kosztem niższej wydajności (w tym miejscu muszę wspomnieć o systemach pamięci podręcznej, które w dużym stopniu mogą przyśpieszyć odpowiedzi serwera i zrównać je lub zbliżyć do odpowiedzi „czystego” kodu).

Jak widać, plusów jest więcej niż minusów, co moim zdaniem jest największą zaletą frameworków. Musimy jednak pamiętać, że frameworki nie są zawsze najlepszym rozwiązaniem. Na przykład, jeśli potrzebujemy stworzyć aplikację do wyświetlania na ekranie pojedynczej wiadomości jako odpowiedzi serwera, użycie dodatkowych narzędzi bez zaawansowanego systemu pamięci podręcznej spowolni odpowiedź serwera i działanie aplikacji. Taka aplikacja wymaga tylko jednego polecenia do wykonania i nie są potrzebne żadne dodatkowe narzędzia, aby otrzymać wymagany rezultat.

Jak prawidłowo korzystać z frameworków?

Nie można powiedzieć, że frameworki mogą rozwiązać wszystkie problemy związane z programowaniem, ale z pewnością mogą pomóc w codziennych zadaniach. Z drugiej strony – trzeba być ostrożnym. Wiele razy obserwowałem konwersacje na forach poświęconych danemu frameworkowi, w których dyskutujący próbują udowodnić, że wybrany przez nich framework jest najlepszy – czego nie da się jednoznacznie stwierdzić bez dokładnej analizy problemu.

Moim zdaniem frameworki są jak narzędzia – im więcej posiadasz narzędzi, tym więcej problemów jesteś w stanie rozwiązać. Jeśli masz tylko młotek, będziesz mógł jedynie wbić gwóźdź. Jeśli masz natomiast cały garaż pełen narzędzi, możesz stworzyć dużo więcej rzeczy.

Czytaj także: Szaleństwo mikroserwisów

Podejście multi-framework

Takie podejście jest rezultatem architektury obecnych aplikacji, budowanych z bibliotek – oddzielnych modułów z własnymi wymaganiami, które można wykorzystać, aby stworzyć dowolny rodzaj aplikacji. W ten sposób aplikację można podzielić na mniejsze części i dzięki temu będzie bardziej zrozumiała dla większej liczby osób. Biblioteki organizują również strukturę aplikacji i pomagają rozwijać większe projekty.

W myśl tego podejścia możemy używać bibliotek jako niezależnego oprogramowania i instalować je w celu zbudowania większych aplikacji. Nie ma przeszkód w korzystaniu w taki sam sposób z frameworków – każda część aplikacji może być zbudowana przy użyciu innego. Dlaczego tak jest? Kiedy korzystamy z bibliotek utworzonych tylko dla jednego frameworka, nie jesteśmy w stanie korzystać z oprogramowania stworzonego dla innych, które może znacząco ulepszyć i przyśpieszyć pracę nad projektem.

Podsumowanie

Podsumowując – powinniśmy stosować podejście, które pozwoli nam pozostać otwartym na stosowanie różnych bibliotek, a w tym przypadku nazwa frameworka jest tylko źródłem pochodzenia danej biblioteki. Przykładem takiego podejścia są popularne rozwiązania, jak platformy e-commerce Magento i Sylius czy też sklep e-commerce nowej generacji o nazwie Shopware. Zastosowanie podejścia multi-framework to nie tylko e-commerce – zaobserwujemy je również w popularnych i bardzo elastycznych rozwiązaniach CMF takich jak Sulu. Gdy sprawdzamy kod źródłowy tych aplikacji na GitHubie, można zobaczyć, że autorzy korzystali z bibliotek pochodzących z frameworków Zend i Symfony – bibliotekami tymi można zarządzać w technologii PHP za pośrednictwem composera. Na pierwszy rzut oka proporcje nie są duże, jednak możemy zacząć uważać to za wykorzystanie podejścia multi-framework i traktować jako świadomą decyzję w kontekście realizacji architektury projektu.