Manutenção de um projeto em PHP: 5 erros a evitar

PHP, como outras linguagens, tem algumas desvantagens que não valem nada quando se trata de gerir um TI projeto onde PHP é a língua principal.

Abaixo, apresentamos uma lista dessas situações, juntamente com dicas para as evitar.

1. Não seguir as recomendações das normas PHP

PHP é considerada uma "linguagem fácil" porque tem uma barreira muito baixa à entrada. O resultado é uma grande disparidade nas normas de codificação e na forma como as interfaces globais são implementadas em várias bibliotecas externas. Num esforço para pôr ordem, foi introduzido um conjunto de normas. Estas descrevem um conjunto de formas através das quais o programador da implementação pode satisfazer qualquer conjunto de restrições exigidas pela norma. Um exemplo simples para Despachante de eventos:

Ouvinte - Um ouvinte é qualquer PHP que espera que lhe seja passado um evento. Pode ser passado o mesmo evento a zero ou mais Listeners. Um Listener PODE enfileirar algum outro comportamento assíncrono se assim o desejar.

Utilizando esta norma, qualquer programador que utilize a nomenclatura de um concorrente PSR pode facilmente não só comunicar com, mas também código com outros programadores.
Colocar estas normas em prática, por exemplo, utilizando PHP A forma correta orientações e bibliotecas que suportam interfaces PSR globais, permite Desenvolvedores PHP para se adaptar mais rapidamente às mudanças nos requisitos funcionais, arquitectónicos e de infraestrutura.

Como é que o posso evitar?

Como responsável pela manutenção da base de código, lembre-se sempre de usar versões comprovadas e estáveis de bibliotecas externas e, se for forçado a usar uma solução personalizada, implemente-a usando PSRs PHP.
Uma lista de todas as normas disponíveis está disponível no sítio Web principal PHP-FIG. As normas alargadas com descrições práticas estão disponíveis numa variedade de formatos a partir do PHP A forma correta página inicial.
As melhores bibliotecas que estão em conformidade com os padrões PHP-FIG estão listadas no Liga PHP sítio Web.

2. Não bloquear as versões das dependências do composer.json

Em projectos que utilizam o gestor de dependências Compositor é frequente verificar-se uma situação em que, após um longo período de apoio e manutenção do produto no ambiente de produção, é necessário implementar alterações funcionais sem reconstruir toda a arquitetura. Na maioria das vezes, o projeto é então assumido por um programador, cuja tarefa é lançar o ambiente de desenvolvimento local e começar a trabalhar nos bilhetes. Com base nos compositor.lock o programador pode restaurar o projeto para o estado em que se encontrava no ambiente de produção, mas qualquer alteração ao ficheiro compositor.json por exemplo, adicionando a biblioteca, causará uma cascata de erros que aumentará o tempo real de implementação de um novo ficheiro equipa para a organização, bem como o tempo de desenvolvimento da solução.

Como é que o posso evitar?

Quando a aplicação estiver estável, o responsável pela manutenção do código deve bloquear as versões das bibliotecas na pasta compositor.json e criar um procedimento claro que descreva a forma de atualizar as suas versões, se necessário, no futuro.

Considere também a possibilidade de executar um mecanismo para verificar o estado de segurança das bibliotecas utilizadas e automatizar o processo de fornecimento de actualizações de segurança.
Utilizar ferramentas gratuitas como Dependabotpodemos manter uma infraestrutura de versionamento consistente e gerenciável para bibliotecas dependentes e fornecer uma garantia de segurança para nossa aplicação.

3. Recolha deficiente de requisitos

> É apenas um CRUD, porquê incomodar-se?

> Existe uma biblioteca que faz exatamente isso!

No PHP é fácil cair no vórtice do esquecimento ao implementar a lógica comercial do produto. Ao longo dos anos, houve centenas de projectos que [criam painéis administrativos para gerir modelos de dados](https://backpackforlaravel.com/), [geram vistas semelhantes às do Google Analytics](https://github.com/Kunstmaan/KunstmaanDashboardBundle) ou [resolvem os problemas assíncronos do PHP](https://laravel.com/docs/9.x/octane) com o toque de uma varinha mágica (OK, com uma única consulta de linha de comandos).
O mundo PHP está cheio de implementações prontas que funcionam 99,9% do tempo.
É nesse 0.1% que a lógica empresarial colide com as limitações funcionais das bibliotecas utilizadas.
São os chamados "throw-ins" que são mais difíceis de implementar no final do projeto.

Como é que o posso evitar?

Não há hipótese de encontrar o meio-termo entre a sobreengenharia e a subengenharia sem uma compreensão adequada do domínio comercial do produto.
Ao iniciar equipa de desenvolvimento Os membros que se encontram na fase inicial do produto e que são proactivos ao trabalharem com o proprietário do produto podem minimizar o risco do problema de utilizar uma solução que não funcionará como um investimento a longo prazo.

4. Reduzir os custos evitando escrever testes

PHP não é perfeito, isso é certo. As suas deficiências em termos de tipagem estática, a falta de suporte para genéricos e o suporte contínuo para métodos arcaicos ainda são motivo de piadas entre os programadores. No entanto, durante algum tempo Desenvolvedores PHP foram dotados de ferramentas cada vez mais poderosas como PHPStan, Xdebug, PHP-CS-Fixador que lhes permitem manter a consistência e a tipagem estática - evitando assim muitos bugs. Ainda assim, é dada muito pouca atenção aos testes e estes, quando implementados corretamente, resultam num rápido retorno do investimento sob a forma de
- redução dos erros de regressão
- maior conhecimento das capacidades dos produtos
- aumentar o sentido de propriedade do código por parte do programador

Como é que o posso evitar?

Não corte custos nos testes. Escrever scripts Behat simples não é assim tão difícil, não é preciso escrever testes complexos de ponta a ponta imediatamente ou entrar em detalhes de implementação e testar cada método unitariamente.
Um simples teste Behat descrito em linguagem natural do domínio vale muitas vezes mais do que o teste de ponta a ponta mais meticulosamente escrito.

5. Não ter em conta os padrões de arquitetura modernos

O Língua PHP e as suas duas estruturas mais poderosas Laravel e Symfony são totalmente adequados para criar uma arquitetura moderna, funcional e, sobretudo, de elevado desempenho. O suporte para vários sistemas de filas de mensagens e a cada vez mais rápida PHP as melhorias de desempenho de versão para versão permitem nós para criar facilmente microsserviços baseados em microframeworks. No entanto, na maior parte dos casos, continuamos a confiar em sistemas monolíticos. Não há nada de errado nisso, mas ao considerar o desenvolvimento de tais sistemas, precisamos de prestar muita atenção aos limites do domínio e determinar o ponto de interface entre as novas soluções e as partes mais antigas do sistema.

Como é que o posso evitar?

Ao desenvolver qualquer PHP vale a pena analisar atentamente as soluções actuais, criar interfaces globais para a comunicação de dados e implementar novas funcionalidades utilizando as técnicas e práticas mais recentes. Uma das soluções mais populares utilizadas na prática é Padrão Strangler.