Ingeniería de software en Google

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Este libro se titula Ingeniería de software en Google. ¿Qué entendemos exactamente por ingeniería de software? ¿Qué distingue la "ingeniería de software" de la "programación" o la "informática"? ¿Y por qué tendría Google una perspectiva única que añadir al corpus de literatura anterior sobre ingeniería de software escrita en los últimos 50 años?

Los términos "programación" e "ingeniería de software" se han utilizado indistintamente durante bastante tiempo en nuestra industria, aunque cada término tiene un énfasis diferente y distintas implicaciones. Los universitarios suelen estudiar informática y consiguen trabajo escribiendo código como "programadores".

"Ingeniería de software", sin embargo, suena más serio, como si implicara la aplicación de unos conocimientos teóricos para construir algo real y preciso. Los ingenieros mecánicos, los ingenieros civiles, los ingenieros aeronáuticos y los de otras disciplinas de la ingeniería practican todos la ingeniería. Todos ellos trabajan en el mundo real y utilizan la aplicación de sus conocimientos teóricos para crear algo real. Los ingenieros de software también crean "algo real", aunque sea menos tangible que las cosas que crean otros ingenieros.

A diferencia de esas profesiones de ingeniería más establecidas, la teoría o práctica actual de la ingeniería de software no es tan rigurosa. Los ingenieros aeronáuticos deben seguir directrices y prácticas rígidas, porque los errores en sus cálculos pueden causar daños reales; la programación, en general, no ha seguido tradicionalmente prácticas tan rigurosas. Pero, a medida que el software se integra más en nuestras vidas, debemos adoptar y confiar en métodos de ingeniería más rigurosos. Esperamos que este libro ayude a otros a ver el camino hacia prácticas de software más fiables.

Programación a lo largo del tiempo

Proponemos que la "ingeniería de software" abarque no sólo el acto de escribir código, sino todas las herramientas y procesos que una organización utiliza para construir y mantener ese código a lo largo del tiempo. ¿Qué prácticas puede introducir una organización de software para que su código siga siendo valioso a largo plazo? ¿Cómo pueden los ingenieros hacer más sostenible una base de código y más rigurosa la propia disciplina de ingeniería de software? No tenemos respuestas fundamentales a estas preguntas, pero esperamos que la experiencia colectiva de Google en las dos últimas décadas ilumine posibles caminos hacia la búsqueda de esas respuestas.

Una idea clave que compartimos en este libro es que la ingeniería de software puede concebirse como "programación integrada en el tiempo". ¿Qué prácticas podemos introducir en nuestro código para hacerlo sostenible -capazde reaccionar ante los cambios necesarios- a lo largo de su ciclo de vida, desde la concepción hasta la introducción, el mantenimiento y la eliminación?

El libro hace hincapié en tres principios fundamentales que, en nuestra opinión, las organizaciones de software deben tener en cuenta a la hora de diseñar, crear la arquitectura y escribir su código:

Tiempo y cambio

Cómo deberá adaptarse el código a lo largo de su vida útil

Escala y crecimiento

Cómo deberá adaptarse una organización a medida que evoluciona

Contrapartidas y costes

Cómo toma decisiones una organización, basándose en las lecciones de Tiempo y Cambio y Escala y Crecimiento

A lo largo de los capítulos, hemos intentado enlazar con estos temas y señalar las formas en que tales principios afectan a las prácticas de ingeniería y permiten que sean sostenibles. (Véase el Capítulo 1 para un análisis completo).

La perspectiva de Google

Google tiene una perspectiva única sobre el crecimiento y la evolución de un ecosistema de software sostenible, derivada de nuestra escala y longevidad. Esperamos que las lecciones que hemos aprendido sean útiles a medida que tu organización evoluciona y adopta prácticas más sostenibles.

Hemos dividido los temas de este libro en tres aspectos principales del panorama de la ingeniería de software de Google:

• Cultura

• Procesos

• Herramientas

La cultura de Google es única, pero las lecciones que hemos aprendido al desarrollar nuestra cultura de ingeniería son ampliamente aplicables. Nuestros capítulos sobre Cultura(Parte II) hacen hincapié en la naturaleza colectiva de una empresa de desarrollo de software, en que el desarrollo de software es un esfuerzo de equipo y en que unos principios culturales adecuados son esenciales para que una organización crezca y se mantenga saludable.

Las técnicas esbozadas en nuestros capítulos sobre Procesos(Parte III) son familiares para la mayoría de los ingenieros de software, pero el gran tamaño y la larga vida del código base de Google proporcionan una prueba de esfuerzo más completa para el desarrollo de buenas prácticas. En esos capítulos, hemos intentado destacar lo que hemos comprobado que funciona a lo largo del tiempo y a escala, así como identificar las áreas en las que aún no tenemos respuestas satisfactorias.

Por último, nuestros capítulos sobre Herramientas(Parte IV) ilustran cómo aprovechamos nuestras inversiones en infraestructura de herramientas para proporcionar beneficios a nuestra base de código a medida que crece y envejece. En algunos casos, estas herramientas son específicas de Google, aunque indicamos alternativas de código abierto o de terceros cuando procede. Esperamos que estas ideas básicas se apliquen a la mayoría de las organizaciones de ingeniería.

La cultura, los procesos y las herramientas descritas en este libro describen las lecciones que un ingeniero de software típico aprende en el trabajo. Desde luego, Google no tiene el monopolio de los buenos consejos, y nuestras experiencias aquí presentadas no pretenden dictar lo que debe hacer tu organización. Este libro es nuestra perspectiva, pero esperamos que te resulte útil, ya sea adoptando estas lecciones directamente o utilizándolas como punto de partida al considerar tus propias prácticas, especializadas para tu propio dominio del problema.

Este libro tampoco pretende ser un sermón. El propio Google sigue aplicando imperfectamente muchos de los conceptos contenidos en estas páginas. Las lecciones que hemos aprendido, las hemos aprendido a través de nuestros fracasos: todavía cometemos errores, aplicamos soluciones imperfectas y necesitamos iterar para mejorar. Sin embargo, el gran tamaño de la organización de ingeniería de Google garantiza que haya una diversidad de soluciones para cada problema. Esperamos que este libro contenga lo mejor de ese grupo.

Lo que este libro no es

Este libro no pretende abarcar el diseño de software, una disciplina que requiere su propio libro (y para la que ya existe mucho contenido). Aunque hay algo de código en este libro con fines ilustrativos, los principios son neutrales en cuanto al lenguaje, y hay pocos consejos reales de "programación" en estos capítulos. Como resultado, este texto no cubre muchas cuestiones importantes en el desarrollo de software: gestión de proyectos, diseño de API, refuerzo de la seguridad, internacionalización, marcos de interfaz de usuario u otras preocupaciones específicas del lenguaje. Su omisión en este libro no implica su falta de importancia. Al contrario, hemos optado por no tratarlos aquí sabiendo que no podríamos darles el tratamiento que merecen. Hemos intentado que los debates de este libro versen más sobre ingeniería y menos sobre programación.

Comentarios de despedida

Este texto ha sido una labor de amor por parte de todos los que han contribuido, y esperamos que lo recibas como se da: como una ventana a cómo una gran organización de ingeniería de software construye sus productos. También esperamos que sea una de las muchas voces que contribuyan a que nuestra industria adopte prácticas más progresistas y sostenibles. Y lo que es más importante, esperamos además que disfrutes leyéndolo y puedas adoptar algunas de sus lecciones a tus propias preocupaciones.

Tom Manshreck

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Constant width bold

Muestra comandos u otros textos que deben ser tecleados literalmente por el usuario.

Constant width italic

Muestra el texto que debe sustituirse por valores proporcionados por el usuario o por valores determinados por el contexto.

Nota

Este elemento significa una nota general.

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Para más información, visita http://oreilly.com.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-998-9938 (en Estados Unidos o Canadá)
• 707-829-0515 (internacional o local)
• 707-829-0104 (fax)

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en https://oreil.ly/software-engineering-at-google.

Envía un correo electrónico a [e-mail] para comentar o hacer preguntas técnicas sobre este libro.

Para obtener noticias y más información sobre nuestros libros y cursos, consulta nuestro sitio web en http://www.oreilly.com.

Encuéntranos en Facebook: http://facebook.com/oreilly

Síguenos en Twitter: http://twitter.com/oreillymedia

Míranos en YouTube: http://www.youtube.com/oreillymedia

Agradecimientos

Un libro como éste no sería posible sin el trabajo de innumerables personas. Todo el conocimiento que contiene este libro ha llegado a todos nosotros a través de la experiencia de tantos otros en Google a lo largo de nuestras carreras. Nosotros somos los mensajeros; otros vinieron antes que nosotros, en Google y en otros lugares, y nos enseñaron lo que ahora te presentamos. No podemos enumerarlos a todos aquí, pero queremos darles las gracias.

También nos gustaría dar las gracias a Melody Meckfessel por apoyar este proyecto en sus inicios, así como a Daniel Jasper y Danny Berlin por apoyarlo hasta su finalización.

Este libro no habría sido posible sin el enorme esfuerzo de colaboración de nuestros conservadores, autores y editores. Aunque a los autores y editores se les reconoce específicamente en cada capítulo o llamada de atención, nos gustaría dedicar tiempo a reconocer a quienes contribuyeron a cada capítulo con sus reflexivas aportaciones, debates y revisiones.

• ¿Qué es la ingeniería de software? Sanjay Ghemawat, Andrew Hyatt

• Trabajar bien en equipo: Sibley Bacon, Joshua Morton

• Intercambio de conocimientos: Dimitri Glazkov, Kyle Lemons, John Reese, David Symonds, Andrew Trenk, James Tucker, David Kohlbrenner, Rodrigo Damazio Bovendorp

• Ingeniería para la Equidad: Kamau Bobb, Bruce Lee

• Cómo dirigir un equipo: Jon Wiley, Laurent Le Brun

• Liderar a escala: Bryan O'Sullivan, Bharat Mediratta, Daniel Jasper, Shaindel Schwartz

• Medición de la productividad en ingeniería: Andrea Knight, Collin Green, Caitlin Sadowski, Max-Kanat Alexander, Yilei Yang

• Guías y normas de estilo: Max Kanat-Alexander, Titus Winters, Matt Austern, James Dennett

• Revisión del Código: Max Kanat-Alexander, Brian Ledger, Mark Barolak

• Documentación: Jonas Wagner, Smit Hinsu, Geoffrey Romer

• Resumen de las pruebas: Erik Kuefler, Andrew Trenk, Dillon Bly, Joseph Graves, Neal Norwitz, Jay Corbett, Mark Striebeck, Brad Green, Miško Hevery, Antoine Picard, Sarah Storck

• Pruebas unitarias: Andrew Trenk, Adam Bender, Dillon Bly, Joseph Graves, Titus Winters, Hyrum Wright, Augie Fackler

• Probando dobles: Joseph Graves, Gennadiy Civil

• Pruebas más amplias: Adam Bender, Andrew Trenk, Erik Kuefler, Matthew Beaumont-Gay

• Depreciación: Greg Miller, Andy Shulman

• Control de versiones y gestión de ramas: Rachel Potvin, Victoria Clarke

• Búsqueda de código: Jenny Wang

• Construir sistemas y construir filosofía: Hyrum Wright, Titus Winters, Adam Bender, Jeff Cox, Jacques Pienaar

• Crítica: La herramienta de revisión de código de Google: Mikołaj Dądela, Hermann Loose, Eva May, Alice Kober-Sotzek, Edwin Kempin, Patrick Hiesel, Ole Rehmsen, Jan Macek

• Análisis estático: Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, Edward Aftandilian, Collin Winter, Eric Haugh

• Gestión de la Dependencia: Russ Cox, Nicholas Dunn

• Cambios a gran escala: Matthew Fowles Kulukundis, Adam Zarek

• Integración continua: Jeff Listfield, John Penix, Kaushik Sridharan, Sanjeev Dhanda

• Entrega Continua: Dave Owens, Sheri Shipe, Bobbi Jones, Matt Duftler, Brian Szuter

• Servicios informáticos: Tim Hockin, Collin Winter, Jarek Kuśmierek

Además, nos gustaría dar las gracias a Betsy Beyer por compartir sus conocimientos y experiencia al haber publicado el libro original de Ingeniería de la Fiabilidad de los Sitios Web, lo que hizo que nuestra experiencia fuera mucho más fluida. Christopher Guzikowski y Alicia Young, de O'Reilly, hicieron un magnífico trabajo lanzando y guiando este proyecto hasta su publicación.

Los comisarios también desean dar las gracias personalmente a las siguientes personas:

Tom Manshreck A mi madre y a mi padre por hacerme creer en mí mismo y por trabajar conmigo en la mesa de la cocina para hacer mis deberes.

Tito Winters: A papá, por mi camino. A mamá, por mi voz. A Victoria, por mi corazón. A Raf, por cubrirme las espaldas. También al Sr. Snyder, Ranwa, Z, Mike, Zach, Tom (y a todos los Paynes), mec, Toby, cgd y Melody por las lecciones, la tutoría y la confianza.

Hyrum Wright: A mamá y papá por sus ánimos. A Bryan y a los habitantes de Bakerland, por mi primera incursión en el software. A Dewayne, por continuar ese viaje. A Hannah, Jonathan, Charlotte, Spencer y Ben por su amor e interés. A Heather, por estar ahí en todo momento.