Buenas Prácticas
En Randock valoramos el código limpio y mantenible. Para lograrlo, hemos establecido algunas "mejores prácticas". O más bien, estamos siguiendo algunas de las mejores prácticas establecidas por los grandes jugadores de la tecnología. No tiene sentido reinventar la rueda. Sin embargo, hemos mezclado varios estilos para crear el nuestro.
Somos de la idea de que el código limpio, las buenas prácticas, no deben interponerse en el camino del desarrollo. Puede ser bastante doloroso seguir todas las buenas prácticas hasta el conseguir el objetivo. Tenemos herramientas estándard en todos los lengujes de programación que utilizamos, tanto para frontend como para backend.
PHP
Todos nuestros proyectos PHP, utilizan Symfony como framework. Esto nos permite mantener una misma estructura en los diferentes proyectos, así como una fácil y rápida adaptación de cualquiera de nuestros desarrolladores a cualquier proyecto al que tenga que incorporse. Todos nuestros proyectos hacen uso de las siguientes herramientas/métodos de trabajo:
- Domain Driven Design (DDD) y CQRS.
- Herramientas de análisis estático y formateo (phpstan, php-cs-fixer).
DDD y CQRS
En los primeros días de Symfony, utilizamos Tactician como biblioteca o CQRS y nuestro propio paquete DDD para implementar Value Objects, herramientas auxiliares, etc. Actualmente, hacemos uso de Symfony Messenger para el bus de eventos, commands y querys. Todavía hacemos uso de nuestro paquete DDD, pero estamos migrando a los estándares administrados por la comunidad. Una de las mejores maneras de hacer que un proyecto sea mantenible es asegurarse de que haya lo menos posible para mantener. El uso de librerias y paquetes impulsados por la comunidad es una buena manera de lograr esto.
Una de las mejores maneras de hacer que un proyecto sea mantenible es asegurarse de que haya lo menos posible para mantener.
Nuestro proyectos siempre se basan en DDD y CQRS lo que da a nuestros proyectos una estructura clara (Dominio, Interfaz, Aplicación e Infraestructura). Aplicamos esta estructura tanto en los proyectos basado en PHP como en los que están basados en Node. Esto hace que sea relativamente fácil encontrar un fragmento de código, incluso la primera vez que uno de nuestros desarrolladores ve el proyecto.
Análisis estático y formato de código
También conocido como linters, actualmente estamos utilizando php-cs-fixer para aplicar estándares de código en todo nuestro proyecto, por lo que todos los proyectos comparten un estilo de código común.
Por otro lado, hacemos uso de la excelente biblioteca PHPstan para comprobar el código en busca de errores léxicos.
Husky, commitlint, Mensajes de commit semántico
Hay mucho movimiento en este área. Tratamos de mantenernos al día. Para cada nuevo proyecto que comenzamos, investigamos cuál es la mejor manera de garantizar la felicidad tanto del desarrollador como del CI (Jenkins, Github Actions). Actualmente, hacemos uso de los siguientes estándares:
- Semantic commit messages a través de Commitlint
- Lint-staged
- Husky, para integrar lo anterior
Node.js
Nuestros proyectos que se construyen con Node.js (la mayoría de los proyectos nuevos hoy en día) hacen uso del framework NestJS. Aplicamos los mismos métodos CQRS y DDD que con PHP. También hacemos uso de linters de código, typecheckers y, por supuesto, Typescript para facilitar nuestro desarrollo. Las herramientas que estamos utilizando actualmente, son:
- Prettier and ESLint
- Semantic commit messages a través de Commitlint
- Typescript type-checker
CI/CD
Por supuesto, implementar todo lo anterior sin ningún tipo de canalización CI/CD es tedioso. Dentro de Randock actualmente estamos utilizando nuestro propio servidor Jenkins, que sirve como una herramienta de CI. Con los nuevos proyectos, intentamos hacer uso de Github Actions (porque mantener menos herramientas nosotros mismos es más productivo).
Testing
Ah, hablemos del tema más odiado y querido en desarrollo, los tests. Todos están de acuerdo en que debes hacerlo, todos comienzan a hacerlo, pero a medida que un proyecto crece y se requiere que las características se implementen cada vez más rápido, la cobertura de pruebas disminuye y escribir pruebas se vuelve cada vez más molesto.
No somos la excepción. En los proyectos más criticos los tests se escriben. Tendemos a escribir pruebas de integración con más frecuencia que las pruebas unitarias. La implementación a menudo ayuda a mantener los errores bajos, pero sin pruebas los proyectos no se pueden mantener ni migrar.