Prácticas de desarrollo

Trabajar según una definición de Listo (DoD)

Cada equipo tiene una definición diferente de lo que significa "hecho", pero es importante tener una y asegurarse de que una historia cumpla con los criterios definidos antes de ser aceptada.

Algunos criterios que suelen especificar los equipos son:

• Código revisado para el formato
• Comentarios/Javadoc añadido
• Cumple los niveles de cobertura de prueba requeridos
• Supera las pruebas de unidad e integración
• Validado en el entorno de control de calidad
• Localización implementada

Sin un DoD bien definido, es fácil terminar en una situación en la que muchas cosas están a medio camino y nada está verdaderamente completo.

Definir y cumplir las convenciones de codificación y formato

Las cosas como los niveles de sangría y el espacio en blanco pueden no parecer importantes, pero tener un código con el formato correcto contribuye en gran medida a la legibilidad y la capacidad de mantenimiento. Las convenciones deben debatirse y acordarse como un equipo y luego seguirse en el código.

Objetivo para una alta cobertura de pruebas

A medida que aumenta el tamaño de la implementación de un proyecto, también lo hace el tiempo necesario para probarlo. Sin una buena cobertura de las pruebas, el equipo de pruebas no puede escalar y los desarrolladores terminan enterrados en errores.

Los desarrolladores deben practicar el desarrollo impulsado por pruebas (TDD) y escribir pruebas unitarias que produzcan errores antes del código de producción que cumpla sus requisitos. El control de calidad debe crear un conjunto automatizado de pruebas de aceptación para garantizar que el sistema funcione según lo esperado desde un alto nivel.

Hay marcos personalizados disponibles, como Jackalope y Prosper, para hacer que burlarse de las API de JCR sea más fácil para garantizar la productividad de los desarrolladores mientras escriben pruebas unitarias.

Mantén la demostración lista

El sistema debe estar disponible para la demostración a la empresa al final de cada iteración. Al mantener el sistema en un estado listo para la demostración, el equipo siempre estará dentro de una iteración de estar listo para la producción y la deuda técnica se puede mantener a un nivel mantenible.

Implementar un entorno de integración continua y utilizarlo

La implementación de un entorno de integración continua permite ejecutar de forma fácil y repetida pruebas unitarias y de integración. También desvincula las implementaciones del equipo de desarrollo, lo que permite que las demás partes del equipo sean más eficientes y lograr implementaciones más estables y predecibles.

Mantenga el ciclo de desarrollo rápido al mantener los tiempos de compilación bajos

Si las pruebas unitarias tardan mucho tiempo en ejecutarse, los desarrolladores evitarán ejecutarlas y perderán su valor. Si se tarda mucho tiempo en crear el código e implementarlo, las personas lo harán con menos frecuencia. Hacer que los tiempos de compilación cortos sean una prioridad garantiza que el tiempo que ha invertido en la cobertura de pruebas y en la infraestructura de CI siga haciendo que el equipo sea más productivo.

Ajuste de Sonar y otras herramientas de análisis de código estático y actúe en función de sus informes

Las herramientas de análisis de código pueden ser valiosas, pero solo si sus informes conducen a la acción por parte del equipo de desarrollo. Sin afinar el análisis que proporcionan estas herramientas, las recomendaciones que generan se vuelven irrelevantes y pierden su valor.

Sigue la regla del Scout

Los Boy Scout tienen una regla: "Déjalo mejor de lo que lo encontraste". Mientras todos los miembros del equipo de desarrollo se adhieran a esta regla y limpien algo cuando se encuentren con un lío, el código mejorará constantemente.

Evitar la implementación de funciones YAGNI

Las funciones de YAGNI (No lo vas a necesitar) son cosas que se implementan cuando esperamos que necesitemos algo en el futuro, aunque no lo necesitemos ahora. Idealmente, deberíamos implementar lo más simple que funcione hoy en día y utilizar una refactorización continua para garantizar que la arquitectura del sistema evolucione con los requisitos a lo largo del tiempo. Esto nos permite centrarnos en lo que importa y evitar la hinchazón del código y la fluidez de las funciones.