¿Cómo es la Ingeniería de Software en un gigante como Google?. ¿Cuáles son las mejores prácticas a seguir cuando se desarrolla código utilizando un único repositorio con miles de millones de líneas de código?

Ya hemos hablado anteriormente de las mejores prácticas de Google en la gestión de equipos. Hoy nos centramos en la parte más “ingenieril” de Google. Y nadie mejor que ellos mismos para explicárnoslo. De hecho, hasta han escrito un libro donde dan todos los detalles. Es más, el libro es gratuito. O sea que no hay excusa para no leérselo. Aquí lo tenéis: Software Engineering in Google, también conocido como el libro del flamenco (por razones obvias). Como complemento ideal os recomiendo este podcast entrevistando a Titus Winters  o este otro podcast entrevistando a Hyrum Wright, dos de sus autores.

No es un libro sobre programación sino sobre las estrategias y métodos que utiliza Google para desarrollar sus productos manteniendo un código mantenible y “saludable”.  Como dicen los propios autores, el libro cubre la cultura ingenieril de Google, sus procesos y herramientas y como esta combinación contribuye a su eficiencia como organización.

El libro explora los pilares que toda organización software (y ya sabemos que a día de hoy esta definición cubre la gran mayoría de organizaciones ya que todas dependen en gran medida del software para sus operaciones diarias) debería tener en cuenta al diseñar, planificar la arquitectura o escribir y evolucionar código. Entre otros temas veréis:

  • Como el tiempo afecta la sostenibilidad del software y como conseguir que el código sea más resiliente. No tiene nada que ver un código que se va a reemplazar en 6 meses con uno que tiene que durar veinte años. No tendría sentido que la manera de gestionar el código fuera el mismo en los dos casos.
  • Como tienes que cambiar tus prácticas de Ingeniería de Software a medida que el equipo o el código crece
  • Y qué decisiones y equilibrios tendrás que sopesar al evaluar decisiones de diseño y desarrollo. Ejemplo: la velocidad de desarrollo vs asegura que el producto sigue siendo usable para los usuarios.

El libro cubre una gran diversidad de temas. Desde una definición de conceptos clave como Ingeniería de Software, a como gestionar y liderar equipos a  como medir la productividad, guías de estilo, y buenas prácticas para las revisiones de código, documentación y el testing. La parte final se centra en las herramientas que nos permiten realizar todas estas tareas de una forma eficiente. Ahí discuten aspectos como el control de versiones, los analizadores estáticos de código y los sistemas de integración continua.

600 páginas de sabiduría pero con un resumen de las lecciones aprendidas más importantes al final de cada capítulo. ¡No hay excusa para no descubrir como es la Ingeniería de Software en Google!.

Para los que no queráis leer el libro entero os dejo también algunas frases o conceptos que me han parecido especialmente interesantes, sacadas de los dos podcasts que he enlazado anteriormente.

1. La Ingeniería de Software es Programación con una visión temporal. La ingeniería de software abarca mucho más que simplemente escribir código. Wright compara la programación con la carpintería: esencial pero insuficiente para construir sistemas completos. Los equipos deben planificar para el cambio y el mantenimiento. Los ingenieros son solucionadores de problemas, no escritores de código: “tu trabajo no es sentarte y escribir un montón de código. Tu trabajo es resolver problemas”. Esto es importante sobretodo hoy en día cuando vemos estás impresionantes estadísticas sobre el incremento de productividad en la escritura de código gracias a los agentes inteligentes. Es cierto que escribes más código y más rápido con su ayuda pero su impacto global es menor de lo que parece ya que mucho de lo que hacemos como ingenieros NO es escribir código.

2. La Ley de Hyrum. “Con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato. Todos los comportamientos observables de tu sistema serán utilizados por alguien”. Incluso cambiar líneas de comentarios o números de línea puede romper tests en algún lugar del código base de Google. Link a la web de la ley.

3. Planifica para el Cambio – Nada Dura Para Siempre. El código puede vivir desde “segundos hasta décadas”. Incluso el código teóricamente óptimo enfrentará cambios en hardware, lenguajes y dependencias.

4. El Mito del Genio y el Éxito del Equipo. La industria tecnológica a menudo idealiza a los programadores como genios solitarios, pero los sistemas se construyen gracias a muchas iteraciones donde colaboran múltiples personas. Los equipos superan consistentemente a los contribuidores individuales con el tiempo.

5. Legibilidad del Código sobre Facilidad de Escritura. El código se escribe una vez pero se lee muchas veces. Google optimiza para la legibilidad, implementando guías de estilo y herramientas que pueden requerir más esfuerzo inicial pero hacen el código más fácil de entender para futuros lectores.

6. Escribe Tests – La Práctica Más Importante. Cuando se les pregunta sobre gestión de dependencias, el consejo principal de Winters es simple: “Tests. Solo escribe tests. Escribe buenos tests. Eso es, con diferencia, la parte más importante”. Los tests deben ser pequeños, enfocados primero en escenarios comunes, con tests separados para casos límite.

7. Testing a Escala – De Binario a Procesamiento de Señales Google separa tests pre-submit y post-submit, viendo cada vez más “CI como un problema de procesamiento de señales” en lugar de una señal binaria verde/roja. Los tests inestables son costosos tanto computacionalmente (requiriendo repeticiones) como en costo humano (depurando fallos).

8. Cambios a Gran Escala y Refactorización Con 12.000 desarrolladores y un cuarto de billón de líneas de código, no puedes usar herramientas de refactorización del IDE. Google usa herramientas automatizadas.

9. La Ventaja del Repositorio único. Los beneficios clave son: sin elección de versiones de dependencias, dónde hacer commit, o qué sincronizar. Los cambios centralizados son costosos para un equipo pero baratos para Google en conjunto.

10. La Revisión de Código es un tema de Educación, No de búsqueda de Bugs La investigación muestra que “los beneficios principales de la revisión de código no están generalmente en encontrar bugs” sino más bien “en educación y compartir conocimiento, y es una actividad de comunicación con tu equipo”. La comunicación profesional y educada es crucial.

11. Midiendo la Productividad. Google usa un marco de objetivos (resultados deseados), señales (lo que te gustaría medir) y métricas (proxies concretos). Tienen cuidado de evitar métricas que puedan ser manipuladas y a veces miden sin decir a los equipos exactamente cómo para prevenir cambios de comportamiento.

12. La Importancia del Tiempo El tema más importante es el tiempo: considerar cuánto tiempo necesita durar el software informa todas las demás decisiones de ingeniería. Google construye software para durar años, requiriendo prácticas diferentes a las de una startup construyendo para la próxima ronda de financiación.