Prioridades de desarrollo

El código de producción se prueba siempre, sin excepciones. Los tests corren en Integración Continua (CI). No todo el código necesita todos los tipos de test (unitarios, de integración, e2e, aceptación, etc.).

No somos puristas ni estrictos con la aplicación de Test Driven Development (TDD), pero el desarrollo de pruebas automatizadas es una habilidad de nuestros desarrolladores, y la automatización de pruebas es algo que consideramos importante en los code reviews. Partimos del principio de que todos en el equipo somos responsables de la calidad del software.

Todos los servicios deben hacer lo mejor posible para atrapar y reportar errores. El manejo de errores y su alerta es clave en los code reviews.

El despliegue en producción es automatizado. Consideramos que si un feature no se puede desplegar de manera continua y automatizada, entonces ese feature no está terminado. Hacemos push a producción tan pronto como sea posible; el riesgo lo mitigamos realizando cambios pequeños e incrementales.

Todos los desarrolladores escriben documentación. La documentación es parte de los code reviews. Siempre debemos preguntarnos: "¿Se generó o actualizó la documentación respectiva para este cambio?".

La documentación debe estar bien organizada en la base de conocimiento. Aun teniendo buena documentación, si un compañero no sabe dónde localizarla, es como si no existiera.

Documentamos el código. Los comentarios son buenos y críticos para entender por qué un bloque de código hace lo que hace. Siempre es importante comentar lo que hace el código cuando no es completamente obvio (y también cuando lo es). En conclusión, abrazamos las buenas prácticas de documentar cualquier pieza de código y los problemas que esta práctica ayuda a evitar.

Referencias

• Valores técnicos
• OKRs del equipo de Ingeniería (documento interno — pendiente de enlazar)