Naslijeđeni PHP rijetko zakazuje zato što je star. Zakazuje zato što je kod prestao jasno izražavati svoje namjere.

Poznata aplikacija i dalje može obrađivati vrijedne radne procese, dobro poznavati svoje korisnike i sadržavati godine teško stečenih poslovnih pravila. Prepisivanje cijele aplikacije može biti skupo, rizično i iznenađujuće uspješno u ponovnom stvaranju starih grešaka. Praktičniji je cilj učiniti promjene sigurnijima, jednu promišljenu granicu odjednom.

Moderna održivost nije značka migracije na framework. To je sposobnost razumijevanja zahtjeva, uvođenja male promjene, njezine provjere i implementacije bez kockanja sa skrivenim nuspojavama.

Započnite smanjivanjem neizvjesnosti

Prije promjene arhitekture utvrdite što aplikacija zapravo radi i kako se trenutačno isporučuje. Naslijeđeni sustavi često imaju nedokumentirane cron poslove, webhookove, procedure baze podataka, ovisnosti o datotečnom sustavu i konfiguracijske vrijednosti koje su važnije nego što struktura direktorija sugerira.

Izradite jednostavnu mapu sustava. Identificirajte ulazne točke, ključne tablice, integracije, zakazane poslove, korake implementacije i putanje koda koje podržavaju najvažnije poslovne operacije. To nije birokracija; to je način da izbjegnete „čišćenje” jednog uvjeta koji štiti kritičan rubni slučaj.

Zatim stvorite ponovljivo lokalno okruženje. Docker je ovdje koristan jer pretvara pretpostavke o PHP ekstenzijama, verzijama baze podataka i konfiguraciji web-poslužitelja u vidljivu konfiguraciju.

services:
  app:
    build: .
    volumes:
      - ./:/var/www/html
    ports:
      - "8080:80"
    environment:
      APP_ENV: development
      DB_HOST: db

  db:
    image: mysql:8
    environment:
      MYSQL_DATABASE: app
      MYSQL_ROOT_PASSWORD: local-root-password
    ports:
      - "3306:3306"

Točne slike i postavke moraju odgovarati stvarnim zahtjevima aplikacije. Cilj nije odmah nametnuti moderan skup tehnologija. Cilj je učiniti trenutačni skup tehnologija ponovljivim prije pokušaja njegova razvoja.

Stvorite sigurnosnu mrežu prije pomicanja zidova

Testovi su najvrjedniji ondje gdje su promjene vjerojatne, a pogreške skupe. Naslijeđena baza koda može imati malo ili nimalo automatiziranih testova, zato započnite karakterizacijskim testovima: testovima koji bilježe trenutačno ponašanje, uključujući ponašanje koje djeluje nespretno.

Na primjer, ako funkcija za ukupni iznos narudžbe primjenjuje popuste nejasnim redoslijedom, najprije zabilježite njezine rezultate za reprezentativne ulaze. Tek kada je to ponašanje vidljivo, trebate odlučiti je li ispravno. Time se refaktoriranje odvaja od promjena pravila, što je jedan od najvažnijih načina da napor modernizacije ostane pod kontrolom.

• Najprije zaštitite prihode, autentifikaciju, dozvole, naplatu i uvoz podataka.
• Testirajte javne HTTP odgovore i integracijske ugovore na njihovim granicama.
• Dodajte usmjerene jedinične testove dok se kod izdvaja u manje komponente.
• Upotrijebite staging okruženje ili pažljivo ograničene provjere u produkciji za provjeru ponašanja implementacije.

Statička analiza također može otkriti probleme koje ručni pregled propušta: vrijednosti koje mogu biti null, netočne povratne tipove, nedostižne grane i nedosljedne oblike polja. Uvodite je postupno. Osnovna vrijednost može spriječiti da postojeći nalazi blokiraju usvajanje, uz osiguravanje da novopromijenjeni kod ne dodaje nove.

Razmrsite odgovornosti, a ne sve odjednom

Klasična naslijeđena PHP datoteka često miješa parsiranje zahtjeva, autorizaciju, SQL, poslovne odluke, HTML izlaz i obradu pogrešaka. Zamjena u jednom velikom pull requestu stvara previše pokretnih dijelova. Umjesto toga, izdvojite jednu odgovornost iza malog sučelja.

Razmotrite skriptu nalik kontroleru koja izračunava i sprema račun. Prvo korisno izdvajanje često je servis koji izražava poslovnu radnju, dok repozitorij upravlja pristupom bazi podataka.

final class InvoiceService
{
    public function __construct(
        private InvoiceRepository $invoices,
        private TaxCalculator $taxes,
    ) {
    }

    public function create(CreateInvoice $command): Invoice
    {
        $subtotal = $command->subtotal();
        $tax = $this->taxes->calculate($subtotal, $command->taxRate());

        $invoice = Invoice::open(
            $command->customerId(),
            $subtotal,
            $tax
        );

        $this->invoices->save($invoice);

        return $invoice;
    }
}

To ne zahtijeva usvajanje svake značajke potpunog frameworka. Kodu daje korisnu točku razdvajanja: servis se može testirati bez HTTP zahtjeva ili aktivne baze podataka, a repozitorij kasnije može promijeniti implementaciju upita bez prepisivanja poslovnog pravila.

Držite detalje frameworka i infrastrukture blizu rubova. Objekti zahtjeva, ručke baze podataka, klijenti predmemorije i maileri ne bi se trebali neprimjetno širiti kroz svaku domensku klasu. Eksplicitne je ovisnosti lakše zamijeniti, testirati i razumjeti.

Pažljivo modernizirajte ugovor s bazom podataka

Kod baze podataka često je mjesto na kojem PHP aplikacija nosi svoju najtrajniju složenost. Zamijenite SQL spojen iz nizova parametriziranim upitima, ali nemojte to bitno sigurnosno poboljšanje zamijeniti za potpuni redizajn pristupa podacima.

Kada je moguće, promjene sheme uvodite aditivno. Dodajte nullable stupac, napišite kod koji obrađuje i stare i nove podatke, popunite podatke u kontroliranom procesu, a zatim pooštrite ograničenja tek kada su aplikacija i podaci spremni. Takav pristup podržava sigurniju implementaciju i vraćanje promjena od migracije koja zahtijeva da se svaki poslužitelj prebaci u istom trenutku.

Transakcije zaslužuju jednaku pažnju. Transakcija treba obuhvatiti jednu koherentnu promjenu stanja, kao što je stvaranje računa i njegovih stavki. Ne bi trebala obuhvaćati spore mrežne pozive. Ako se vanjski API mora obavijestiti, pohranite događaj ili radnu stavku u istoj transakciji baze podataka i obradite je zasebno uz zaštite za ponovni pokušaj i idempotentnost.

Učinite putanje neuspjeha eksplicitnima

Naslijeđeni kod često tretira neuspjeh kao izniman detalj sve dok ne istekne vrijeme veze ili udaljeni servis ne vrati neočekivani odgovor. Moderni kod trebao bi razlikovati pogreške validacije, očekivane operativne neuspjehe i stvarne nedostatke.

Za integraciju koja se može ponovno pokušati zabilježite dovoljno informacija za siguran ponovni pokušaj, koristite ograničen broj pokušaja i osigurajte da ponovljeni zahtjev ne može stvoriti duplicirane nuspojave. Petlja za ponovni pokušaj bez idempotentnosti samo pretvara prolazni kvar u duplicirani rad.

Zapisujte neuspjehe s korisnim kontekstom, ali izbjegavajte stavljati tajne, tokene, lozinke ili nepotrebne osobne podatke u zapise. Jasan identifikator pogreške i ID relevantnog poslovnog zapisa obično su korisniji od potpunog ispisa zahtjeva.

Poboljšavajte cjevovod isporuke u malim koracima

Refaktoriranje je nepotpuno ako implementacija ostaje tajanstvena. Uspostavite predvidljiv slijed: instalirajte ovisnosti, pokrenite testove i statičke provjere, izgradite ili provjerite artefakt spreman za implementaciju, promišljeno primijenite migracije i provjerite zdravlje aplikacije nakon izdanja.

Konfiguracija pripada izvan izvornog koda. Vrijednosti specifične za okruženje, poput vjerodajnica, krajnjih točaka servisa i zastavica značajki, trebale bi se isporučivati putem izvršnog okruženja ili sigurnog konfiguracijskog sustava. Provjerite potrebnu konfiguraciju pri pokretanju kako bi nedostajuća vrijednost zakazala rano i jasno, umjesto tijekom zahtjeva korisnika.

Zastavice značajki mogu smanjiti rizik kada su promjene ponašanja značajne. Nisu zamjena za testiranje i trebale bi imati vlasnika i plan uklanjanja. Trajne zastavice postaju još jedna vrsta naslijeđenog koda.

Mjerite napredak troškom promjene

Zdraviji PHP sustav nije nužno onaj s najnovijom sintaksom ili najviše ovisnosti. To je onaj u kojem programer može pronaći pravilo, razumjeti njegove ulaze, promijeniti ga s pouzdanjem i promatrati rezultat.

Refaktoriranje naslijeđenog PHP-a disciplina je očuvanja vrijednosti uz smanjivanje dvosmislenosti. Dodajte test oko rizičnog ponašanja. Izdvojite jednu granicu. Učinite jedan korak implementacije ponovljivim. Uklonite jednu skrivenu ovisnost. Te se promjene nadovezuju i s vremenom baza koda prestaje djelovati kao problem nasljeđivanja te se počinje ponašati kao sustav koji tim može s pouzdanjem poboljšavati.