Nuestro enfoque para la coherencia del desarrollo de software

No documente lo que puede automatizar

Esta publicación de blog es parte de una serie en la que comparto nuestra migración de aplicaciones monolíticas (cada una con su propio repositorio de origen) implementadas en AWS a una arquitectura de servicios distribuidos (con todo el código fuente alojado en un monorepo) implementada en Google Cloud Platform.

¿Qué es la consistencia en el desarrollo de software?

Veo la consistencia como una parte integral de la entrega exitosa de software. Con demasiada frecuencia me he unido o trabajado con equipos de software que tenían poca o ninguna coherencia.

Se aplica a todos los aspectos del desarrollo: estilo del código, comentarios, herramientas, incorporación, creación de nuevos servicios. También se extiende a la gestión de productos, definición y seguimiento de tareas y, en general, procesos de la empresa.

Tomemos el caso de "la creación de nuevos paquetes y servicios" de mi proyecto actual donde migramos de aplicaciones monolíticas a servicios más pequeños, independientes y distribuidos. Así es como creamos los primeros 3 servicios:

  • Servicio 1 : 100% hecho a mano, prueba y error, muchos callejones sin salida.
  • Servicio 2 : Copie y pegue el servicio 1, modifique cuando sea necesario, reemplace la lógica comercial anterior por una nueva relevante para el servicio 2. Repita hasta que esperemos que todo funcione de alguna manera.
  • Servicio 3 : copiar y pegar … ¿qué demonios estamos haciendo?

¿Puedes ver la consistencia? Correcto, Copiar y pegar se ve bastante consistente. ¿Qué sucede cuando las personas que pasaron una semana construyendo el servicio 1 continúan? ¿Quién sabe qué debe modificarse para crear el servicio 8? Imagine la pesadilla cuando ocurre un error fundamental e impacta todos los servicios … ?.

Ahora la pregunta es, ¿cómo hacemos que esto sea más consistente? Le pregunté a algunos amigos y muchos respondieron: documenta el proceso .

  • Servicio 1 : 100% hecho a mano, prueba y error, algunas malas palabras aquí y allá.
  • Documenta el proceso
  • Servicio 2 : Copie y pegue el servicio 1, siga la lista de verificación de la documentación para actualizar el nuevo servicio.
  • Servicio 3 : siga los pasos anteriores, siempre y cuando no haya cambiado nada y la documentación esté actualizada ?.

No documente lo que puede automatizar

Como alguien que ha pasado más de la mitad de su vida en la industria del software, me di cuenta de que la forma más sencilla de mantenerse cuerda en este entorno de rápido movimiento es escribir guiones que hacen el trabajo por mí.

La documentación es excelente, siempre que sea precisa. Hay situaciones donde la documentación es necesaria, pero para el caso de uso que discutimos en esta publicación de blog (creación de nuevos paquetes y servicios), la documentación es un enfoque equivocado.

Cada nuevo paquete o servicio tiene una forma determinada que es bastante similar entre todos los demás, como que cada casa tiene algún tipo de base, algunas paredes y ventanas y un techo.

Imagine el siguiente procedimiento para crear 3 servicios:

  • Servicio 1 : ejecute el generador de servicio, proporcione valores específicos del servicio, presione Enter.
  • Servicio 2 : ejecute el generador de servicio, proporcione valores específicos del servicio, presione Enter.
  • Servicio 4 : ejecute el generador de servicio, proporcione valores específicos del servicio, presione Enter.

Automatice el proceso

Ahora no solo imaginemos el procedimiento anterior, veamos cómo logramos exactamente eso en nuestro proyecto.

Para ser transparente, obviamente teníamos algo así como el servicio 0, en el que realizamos todo a mano, probamos el servicio, implementamos, ajustamos etc. Sin embargo, sabíamos que queríamos automatizar este proceso, por lo que prestamos mucha atención a eso desde el principio.

Nuestra herramienta de elección es Plop . Una alternativa popular es Yeoman . Elegimos Plop por su simplicidad y ahora que admite AddMany , proporciona todo lo que necesitamos.

Actualmente tenemos dos generadores:

  • Paquete
  • Servicio

Todos los archivos de plantilla viven en una carpeta _templates . La estructura del directorio es:

 . 
??? _templates
? ??? paquetes
? ? AD README.md
? ? ??? iso
??? ? r
? ? ??? web
? ??? servicios
? ??? README.md
??? r svr
? ??? web
??? scripts
??? generadores
??? helpers.js
??? index.js
??? paquetes
???. Index.js
??? servicios
??? index.js

Los archivos de plantilla README.md existen una vez para paquetes y una vez para servicios. Esto garantiza que cada paquete (y cada servicio) siga la misma estructura. Un archivo README.md contiene la información necesaria para que cualquiera pueda contribuir a un paquete o servicio.

Más abajo, los generators están definidos. El punto de entrada del generador y el generador de paquetes se parecen a esto:

Los generadores de servicios son un poco más complejos ya que también se encargan de una configuración de servicio adicional, como la creación de un recurso RuntimeConfig en GCP , la creación de un canal en Slack , la adición de un nuevo componente en Jira , etc.

Conclusión

El generador se puede agrupar en una secuencia de comandos de NPM en el package.json raíz del repositorio. package.json así:

 { 
"guiones": {
"generar": "plop --plopfile ./scripts/generators/index.js"
},
"devDependencies": {
"plop": "^ 1.9.1"
}
}

Todo lo que se necesita ahora para generar un nuevo paquete es yarn generate . Una CLI interactiva luego guía a los desarrolladores a través de algunas preguntas. Una característica agradable es el hecho de que puede pasar el nombre del generador como argumento, por ejemplo, el yarn generate service lleva directamente a las preguntas relacionadas con el servicio.