PHP Desarrollo. Symfony Console Component - Trucos y consejos
Este artículo fue creado con el objetivo de mostrarte los consejos y trucos más útiles y recuperables sobre el desarrollo de la consola Symfony.
Se ha escrito más de un artículo sobre los errores cometidos durante el proceso de ejecución de un proyecto, pero rara vez se examinan los requisitos del proyecto y se gestionan los riesgos en función de la tecnología elegida.
PHPal igual que otros lenguajes, tiene algunos inconvenientes que no valen nada cuando se trata de gestionar un TI proyecto donde PHP es la lengua principal.
A continuación hemos elaborado una lista de ellos, junto con consejos para evitarlos.
PHP se considera un "lenguaje fácil" porque tiene una barrera de entrada muy baja. El resultado es una gran disparidad en los estándares de codificación y en cómo se implementan las interfaces globales en las distintas bibliotecas externas. En un esfuerzo por poner orden, se introdujo un conjunto de normas. Éstas describen un conjunto de formas en las que el desarrollador de la implementación puede satisfacer cualquier conjunto de restricciones exigidas por la norma. Un ejemplo sencillo para Despachador de eventos:
Listener - Un Listener es cualquier PHP que espera recibir un evento. Cero o más Escuchadores pueden recibir el mismo Evento. Un Listener PUEDE poner en cola algún otro comportamiento asíncrono si así lo desea.
Gracias a esta norma, todos los desarrolladores que utilicen la nomenclatura de los candidatos a PSR no sólo podrán comunicarse fácilmente con ellos, sino también código con otros desarrolladores.
Poner en práctica estas normas, por ejemplo utilizando PHP El camino correcto y bibliotecas que admiten interfaces PSR globales, permite Desarrolladores PHP adaptarse más rápidamente a los cambios en los requisitos funcionales, arquitectónicos y de infraestructura.
Como mantenedor de la base de código, recuerde siempre utilizar versiones probadas y estables de las bibliotecas externas y, si se ve obligado a utilizar una solución personalizada, impleméntela utilizando PSR PHP.
En el sitio web principal encontrará una lista de todas las normas disponibles PHP-FIG. Las normas ampliadas con descripciones prácticas están disponibles en diversos formatos en la PHP El camino correcto página web.
Las mejores bibliotecas que se ajustan a las normas PHP-FIG se enumeran en la página Liga PHP sitio web.
En los proyectos que utilizan el gestor de dependencias Compositor a menudo se produce una situación en la que, tras un largo período de apoyo y mantenimiento de la producto en el entorno de producción, es necesario aplicar cambios funcionales sin reconstruir toda la arquitectura. Lo más frecuente es que el proyecto pase a manos de un programador, cuya tarea consiste en poner en marcha el entorno de desarrollo local y empezar a trabajar en las entradas. Basándose en la composer.lock
el desarrollador puede restaurar el proyecto al estado en que se encontraba en el entorno de producción, pero cualquier cambio en el archivo composer.json
por ejemplo, añadiendo la biblioteca, provocará una cascada de errores que aumentará el tiempo real de implementación de un nuevo archivo equipo miembro a la organización, así como el tiempo de desarrollo de la solución.
Una vez que la aplicación es estable, el responsable del mantenimiento del código debe bloquear las versiones de las bibliotecas en el directorio composer.json
y crear un procedimiento claro que describa cómo actualizar sus versiones si fuera necesario en el futuro.
Considere también la posibilidad de poner en marcha un mecanismo para comprobar el estado de seguridad de las bibliotecas utilizadas y automatizar el proceso de suministro de actualizaciones de seguridad.
Utilizando herramientas gratuitas como Dependabotpodemos mantener una infraestructura de versiones coherente y manejable para las bibliotecas dependientes y proporcionar una garantía de seguridad para nuestra aplicación.
> Es sólo un CRUD, ¿para qué molestarse?
> ¡Hay una biblioteca que hace exactamente eso!
En el PHP es fácil caer en la vorágine del olvido cuando se implementa la lógica de negocio del producto. A lo largo de los años ha habido cientos de proyectos que [crean paneles administrativos para gestionar modelos de datos](https://backpackforlaravel.com/), [generan vistas similares a las de Google Analytics](https://github.com/Kunstmaan/KunstmaanDashboardBundle) o [resuelven los problemas asíncronos de PHP](https://laravel.com/docs/9.x/octane) con el toque de una varita mágica (vale, con una sola consulta en la línea de comandos).
El mundo PHP está lleno de implementaciones ya hechas que funcionan el 99,9% de las veces.
Ahí es donde la lógica empresarial choca con las limitaciones funcionales de las bibliotecas utilizadas.
Son los llamados "lanzamientos" los más difíciles de aplicar al final del proyecto.
No hay posibilidad de encontrar el justo medio entre la sobreingeniería y la infraingeniería sin una comprensión adecuada del ámbito de negocio del producto.
Al empezar equipo de desarrollo miembros al principio de la fase del producto y ser proactivo mientras se trabaja con el propietario del producto, se puede minimizar el riesgo del problema de utilizar una solución que no funcionará como inversión a largo plazo.
PHP no es perfecto, eso está claro. Sus carencias en cuanto a tipado estático, falta de soporte para genéricos y soporte continuado para métodos arcaicos siguen siendo fuente de bromas entre los programadores. Sin embargo, desde hace algún tiempo Desarrolladores PHP han recibido herramientas cada vez más potentes como PHPStan, Xdebug, PHP-CS-Fijador que les permiten mantener la coherencia y el tipado estático, evitando así muchos errores. Aún así, se presta muy poca atención a las pruebas y éstas, cuando se implementan correctamente, dan como resultado un rápido retorno de la inversión en forma de
- reducción de los errores de regresión
- mayor conocimiento de las capacidades de los productos
- aumentar el sentido de propiedad del código por parte de los desarrolladores
No recortes gastos en pruebas. Escribir scripts Behat simples realmente no es tan difícil, no tienes que escribir complejas pruebas de extremo a extremo de inmediato o entrar en detalles de implementación y pruebas unitarias de cada método.
Una simple prueba Behat descrita en lenguaje de dominio natural suele valer más que la prueba de extremo a extremo más meticulosamente escrita.
En Idioma PHP y sus dos marcos más potentes Laravel y Symfony son totalmente adecuados para crear una arquitectura moderna, funcional y, lo que es más importante, de alto rendimiento. La compatibilidad con varios sistemas de colas de mensajes y la cada vez más rápida PHP mejoras de rendimiento de una versión a otra nos permite crear fácilmente microservicios basados en microframeworks. Sin embargo, en su mayor parte, seguimos confiando en sistemas monolíticos. No hay nada malo en ello, pero al plantearnos el desarrollo de tales sistemas debemos prestar mucha atención a los límites del dominio y determinar el punto de interfaz entre las nuevas soluciones y las partes más antiguas del sistema.
Al desarrollar cualquier PHP merece la pena examinar de cerca las soluciones actuales, crear interfaces globales para la comunicación de datos e implantar nuevas funcionalidades utilizando las técnicas y prácticas más recientes. Una de las soluciones más utilizadas en la práctica es Patrón estrangulador.