Introdução
Muitas vezes me pedem para falar sobre como trabalhar com monólitos legados. Fala-se muito sobre arquitetura de microsserviço, mas raramente é mencionado que os projetos chegam a ela depois de anos de crescimento com um aplicativo monolítico. Para mudar a arquitetura de uma solução ativa, você precisa passar por vários estágios. O autor trabalhou com vários projetos - ambos com uma arquitetura REST orientada a serviços de multilocação completa e com um enorme monólito, em cujo repositório havia commits por dez anos. Este artigo é sobre o lado negro, código legado e soluções práticas para problemas com aplicativos PHP monolíticos.
Razões para o surgimento de legado
Existem duas razões principais para o código legado.
A primeira razão é que novas versões de sistemas operacionais, linguagens, navegadores e bibliotecas são lançadas. O problema é especialmente relevante para aplicativos móveis e linguagens de script - a cada lançamento de uma nova versão da plataforma, é necessário corrigir os problemas de compatibilidade do código antigo. Esse processo é estável e previsível nos próximos anos.
A segunda é a dívida técnica, que é criada propositalmente. O gerenciamento reduz o tempo de desenvolvimento de software evitando design, teste automatizado ou revisão de código, aprova bibliotecas de terceiros que não são suportadas e os desenvolvedores não documentam lógica complexa. Isso é comum e não depende da quantidade de dinheiro na conta da empresa. Não repreenda os maus chefes. Eles têm boas razões para fazer isso.
Os produtos têm um ciclo de vida ; o período de alta demanda por produtos populares dura de três a quatro meses. Os concorrentes irão copiar tudo de melhor e torná-lo ainda melhor, então as empresas são forçadas a lançar novos itens regularmente. Para manter a receita, novos produtos e revisões são lançados a cada poucos meses, de forma que as vendas do novo ciclo compensem a queda nas vendas de produtos no final do ciclo. Tanto a Apple quanto a Marvel fazem três ou quatro lançamentos principais por ano, e a Oracle também tem um ciclo de lançamento trimestral no mercado SAAS empresarial. No entanto, não existe receita para o sucesso. 97% das startups jogam fora seus produtos e experimentam algo novo antes de encontrar um produto do qual compram. Portanto, o custo de desenvolver MVP em startups é minimizado.
Você está com problemas com o Legacy, então está com sorte!
, , . . , , , . , , , , . , , , , legacy-. - legacy , , .
?
. , Wordpress , 38% -. -, . Wordpress , , .
, - , .
, ?
. .
. API . , .
, .
, . . . , , .
PHP .
Rector , .
Exakat PHP, , , .
Phan , PHP.
, , .
. PHP 5- 7- , .
. , . , , . , , . git- . , , .
- . , - , golang. - , , , . .
, - , , API, . , .
:
,
API , ,
composer ,
, ,
, API.
- . . . API .
, PHP, API. , . “release, control, validation” “DevOps”. . , .
, , , .
- :
- , ;
API - , ;
- , ;
, ;
; : IoC- .
, .
, , , Packeton, git-. , Private Packagist.
composer- IoC-, : , , diff.
composer Symfony Dependency Injection IoC- . . IoC-, . IoC- .
:
) ,
) , .
, .
1. , , , “ ” .
: . : , diff .
:
- , . , , , , . : , , diff.
2. .
PHP (). , , / API (, diff).
: , , diff .
, , , - .
5. .
: , Single Responsibility Principle, . - , , . .
- -, . , , , , . - IoC-.
: , , diff, .
6. .
: $model = new ($modelName . ’Class’);
switch- . , .
IoC- . , . . , .
:
, , lazy.
API Service Subscriber.
API .
- Service Subscriber. , . : , , c , . Diff.
Service-Oriented Architecture
, , , , . - ? .
API. API restful-. - , , , . http- curl.
- :
. ID , API, . .
, . : . , , .
, . - . , . , . - . , , . , .