Show Menu
TEMAS×

Prácticas de desarrollo

Trabajo según una definición de terminado

Cada equipo tiene una definición diferente de lo que significa "hecho", pero es importante tener una y asegurarse de que una historia cumpla los criterios definidos antes de ser aceptada.
Algunos de los criterios que suelen especificar los equipos son:
  • Código revisado para dar formato
  • Comentarios/Javadoc añadidos
  • Cumple los niveles de cobertura de prueba requeridos
  • Pasa 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á realmente completo.

Definir y cumplir las convenciones de codificación y formato

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

Objetivo para una cobertura de prueba alta

A medida que la implementación de un proyecto crece en tamaño, también lo hará la cantidad de tiempo necesaria para probarlo. Sin una buena cobertura de pruebas, el equipo de pruebas no podrá escalar y los desarrolladores terminarán enterrados en errores.
Los desarrolladores deben practicar TDD, escribiendo pruebas unitarias fallidas antes del código de producción que cumplirá con 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 nivel elevado.
Existen marcos de trabajo personalizados disponibles, como Jackalope y Prosper, para simplificar la burla de las API de JCR a fin de garantizar la productividad de los desarrolladores mientras escriben pruebas unitarias.

Esté listo para la demostración

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

Implementar un entorno de integración continua y utilizarlo

La implementación de un entorno de integración continua le permitirá ejecutar de forma fácil y repetida pruebas de unidad y de integración. También desacoplará los despliegues del equipo de desarrollo, lo que permitirá a las demás partes del equipo ser más eficientes y lograr despliegues más estables y predecibles.

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

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

Afinar Sonar y otras herramientas de análisis de código estático y actuar en sus informes

Las herramientas de análisis de código pueden ser valiosas, pero sólo si sus informes llevan a la acción por parte del equipo de desarrollo. Sin perfeccionar el análisis que proporcionan estas herramientas, las recomendaciones que generan no serán relevantes y perderán su valor.

Siga la regla de boy scout

Los Boy Scouts 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 desastre, el código mejorará constantemente.

Evite implementar características YAGNI

Las características de YAGNI (o Usted no lo va a necesitar) son cosas que se implementan cuando esperamos que necesitaremos algo en el futuro, aunque no lo necesitamos ahora. Idealmente, deberíamos implementar lo más sencillo que funcione hoy en día y utilizar la refactorización continua para garantizar que la arquitectura del sistema evolucione con los requisitos a lo largo del tiempo. Esto nos permitirá centrarnos en lo que importa y evitar que el código se expanda y las funciones se propaguen.