Ingeniería de software en Google

Hoy en día, los ingenieros de software necesitan saber no solo cómo programar eficazmente, sino también cómo desarrollar prácticas de ingeniería para que la base de código sea sostenible y funcione bien. Este libro hace hincapié en esta diferencia, entre la programación y la ingeniería de software.

¿Cómo pueden gestionar los ingenieros de software una base de código viva que evoluciona y responde a requisitos y demandas cambiantes a lo largo de su vida?

A partir de su experiencia en Google, los ingenieros de software Titus Winters y Hyrum Wright, junto con el escritor técnico Tom Manshreck, presentan una mirada sincera y perspicaz sobre cómo construyen y mantienen el software algunos de los principales profesionales del mundo. Este libro trata de la cultura, los procesos y las herramientas de ingeniería exclusivas de Google, y de cómo estos aspectos contribuyen a la eficacia de una organización de ingeniería de software.

Explorará tres principios fundamentales que las organizaciones de software deben tener en cuenta a la hora de diseñar, establecer la arquitectura, escribir y mantener el código:

Cómo afecta el tiempo a la sostenibilidad del software y cómo hacer que su código resista el paso del tiempo.

Cómo afecta la escala a la viabilidad de las prácticas de software dentro de una organización de ingeniería de software.

Qué contrapartidas debe tener en cuenta el ingeniero de software al evaluar las decisiones de diseño y los desarrollos.

Contenidos

Prólogo xix

Prefacio xxi

Parte I Tesis

1 ¿Qué es la ingeniería de software? 1

Tiempo y cambio 4

Ley de Hyrum 6

Ejemplo: ordenación hash 7

¿Por qué no aspirar a que «nada cambie»? 8

Escala y eficiencia 10

Políticas que no escalan 11

Políticas que escalan adecuadamente 12

Ejemplo: actualización del compilador 13

Desplazamiento hacia la izquierda 15

Contrapartidas y costes 16

Ejemplo: rotuladores 18

Aportaciones a la toma de decisiones 19

Ejemplo: compilaciones distribuidas 19

Ejemplo: decidir entre tiempo y escala 21

Revisar decisiones, cometer errores 22

Ingeniería de software frente a programación 22

Conclusión 23

Resumen 23

Parte II Cultura

2 Cómo trabajar bien en equipo 25

Ayúdeme a ocultar mi código 25

El mito del genio 26

La ocultación se considera perjudicial 28

Detección temprana 29

El factor autobús 29

Ritmo del progreso 30

En resumen, no se esconda 32

Todo es cuestión de equipo 32

Los tres pilares de la interacción social 33

¿Por qué importan estos pilares? 34

Humildad, respeto y confianza en la práctica 34

Cultura post mortem sin sentimiento de culpa 38

Ser Googley 40

Conclusión 41

Resumen 42

3 Compartir conocimientos 43

Desafíos para el aprendizaje 43

Filosofía 45

Preparación del escenario: seguridad psicológica 46

Tutoría 46

Seguridad psicológica en grupos grandes 47

Aumente sus conocimientos 48

Haga preguntas 48

Comprenda el contexto 49

Escalado de las preguntas: pregunte a la comunidad 50

Chats de grupo 50

Listas de correo electrónico 51

YAQS: plataforma de preguntas y respuestas 52

Escalado del conocimiento: siempre hay algo que enseñar 52

Horas de oficina 53

Charlas y clases de tecnología 53

Documentación 54

Código 56

Escalado de los conocimientos de la organización 57

Cultivar la cultura de compartir el conocimiento 57

Establecimiento de fuentes canónicas de información 59

Manténgase al día 62

Legibilidad: tutorías estandarizadas a través de la revisión del código 64

¿Qué es el proceso de legibilidad? 64

¿Por qué someterse a este proceso? 66

Conclusión 68

Resumen 69

4 Ingeniería para la equidad 71

Los prejuicios son la norma 72

Comprensión de la necesidad de la diversidad 74

Desarrollo de capacidades multiculturales 75

Hacer que se pueda procesar la diversidad 77

Rechazo de enfoques singulares 78

Desafío a los procesos establecidos 79

Valores frente a resultados 80

Mantener la curiosidad, seguir adelante 81

Conclusión 82

Resumen 82

5 Cómo liderar un equipo 83

Gerentes y líderes en tecnología (y ambos) 83

El gerente de ingeniería 84

El líder en tecnología 84

El gerente líder de tecnología 84

Pasar de la función de colaborador individual a la función de liderazgo 86

Lo único que hay que temer es…, bueno, todo 86

Liderazgo de servicio 87

El gerente de ingeniería 88

«Gerente» es una palabra de cuatro letras 88

El gerente de ingeniería en la actualidad 89

Antipatrones 91

Antipatrón: contratar a personas fáciles de manejar 91

Antipatrón: ignorar a las personas de bajo rendimiento 92

Antipatrón: ignorar los problemas de carácter personal 93

Antipatrón: ser amigo de todos 94

Antipatrón: comprometer el listón de contratación 94

Antipatrón: tratar al equipo como si fueran niños 95

Patrones positivos 96

Perder el ego 96

Ser un maestro zen 97

Ser catalizador 99

Eliminar obstáculos 99

Ser maestro y mentor 100

Establecer metas claras 100

Ser honesto 101

Rastrear la satisfacción 103

La pregunta inesperada 103

Otros consejos y trucos 104

Las personas somos como las plantas 106

Motivación intrínseca frente a motivación extrínseca 107

Conclusión 109

Resumen 109

6 Liderazgo a escala 111

Siempre hay que decidir 111

La parábola del aeroplano 112

Identificación de las orejeras 113

Señalar las contrapartidas clave 113

Decidir y, después, repetir 114

Siempre hay que dejar solo al equipo 116

Su misión: formar a un equipo «autónomo» 117

División del espacio del problema 117

Siempre hay que mantenerse escalando 120

El ciclo del éxito 121

Lo importante frente a lo urgente 122

Aprender a dejar caer pelotas al suelo 124

Proteja su energía 125

Conclusión 127

Resumen 127

7 Medición de la productividad de la ingeniería 129

¿Por qué debemos medir la productividad de la ingeniería? 129

Triaje: ¿vale la pena medirlo? 131

Selección de métricas significativas con objetivos y señales 135

Objetivos 136

Señales 138

Métricas 139

Uso de datos para validar métricas 139

Actuar y realizar un seguimiento de los resultados 143

Conclusión 144

Resumen 144

Parte III Procesos

8 Guías de estilo y normas 145

¿Por qué tenemos normas? 146

Creación de normas 147

Principios rectores 147

Guía de estilo 156

Cambio de las normas 159

El proceso 161

Árbitros de estilo 161

Excepciones 162

Orientación 163

Aplicación de las normas 164

Comprobadores de errores 166

Formateadores de código 167

Conclusión 169

Resumen 170

9 Revisión del código 171

Flujo de revisión del código 172

Cómo funciona la revisión de código en Google 173

Beneficios de la revisión de código 176

Corrección de código 177

Comprensión de código 179

Coherencia del código 180

Beneficios psicológicos y culturales 181

Compartir conocimientos 182

Mejores prácticas de la revisión de código 183

Sea cortés y profesional 183

Escriba cambios pequeños 184

Escriba descripciones de los cambios que tengan calidad 186

Mantenga al mínimo el número de revisores 186

Automatizar donde sea posible 187

Tipos de revisiones de código 187

Revisiones del código greenfield 188

Cambios de comportamiento, mejoras y optimizaciones 188

Corrección de errores y reversiones 189

Refactorizaciones y cambios a gran escala 190

Conclusión 190

Resumen 191

10 Documentación 193

¿Qué calificar como «documentación»? 193

¿Por qué es necesaria la documentación? 194

La documentación es como el código 196

Conozca a su audiencia 199

Tipos de audiencias 199

Tipos de documentación 201

Documentación de referencia 201

Documentos de diseño 204

Tutoriales 205

Documentación conceptual 207

Páginas de destino 208

Revisiones de la documentación 208

Filosofía de la documentación 210

QUIÉN, QUÉ, CUÁNDO, DÓNDE y POR QUÉ 211

El principio, la parte central y el final 212

Parámetros de la documentación de calidad 212

Documentación obsoleta 213

¿Cuándo necesita a escritores técnicos? 214

Conclusión 214

Resumen 215

11 Descripción general de las pruebas 217

¿Por qué escribimos pruebas? 218

La historia de Google Web Server 219

Pruebas al ritmo del desarrollo moderno 220

Escribir, ejecutar, reaccionar 222

Ventajas de probar el código 223

Diseño de un conjunto de pruebas 225

Tamaño de las pruebas 225

Alcance de las pruebas 230

Regla de Beyoncé 233

Nota sobre la cobertura del código 233

Pruebas a escala de Google 234

Dificultades de un gran conjunto de pruebas 235

Historial de pruebas en Google 237

Clases de orientación 238

Pruebas certificadas 239

Pruebas en los aseos 239

La cultura de pruebas actualmente 240

Límites de las pruebas automatizadas 241

Conclusión 242

Resumen 243

12 Pruebas unitarias 245

Importancia del mantenimiento 246

Prevención de pruebas frágiles 247

Esfuércese en lograr pruebas que no cambien 247

Pruebas a través de API públicas 249

Comprobar el estado, no las interacciones 252

Escriba pruebas claras 253

Haga que las pruebas sean completas y concisas 255

Pruebe los comportamientos, no los métodos 255

No ponga la lógica en las pruebas 261

Escriba mensajes de error claros 262

Pruebas y uso compartido de código: DAMP, no DRY 263

Valores compartidos 265

Configuración compartida 267

Helpers compartidos y validación 269

Definición de infraestructura de pruebas 269

Conclusión 270

Resumen 270

13 Dobles de pruebas 273

El impacto de los dobles de pruebas en el desarrollo del software 274

Dobles de pruebas en Google 275

Conceptos básicos 275

Un ejemplo de dobles de pruebas 275

Costuras 276

Marcos de trabajo de simulación 278

Técnicas para utilizar los dobles de pruebas 279

Simulación 279

Stubbing 279

Pruebas de interacción 280

Implementaciones reales 281

Preferencia de las implementaciones reales a las aisladas 281

Cómo decidir cuándo utilizar una implementación real 283

Simulación 285

¿Por qué son importantes las simulaciones? 286

¿Cuándo deben escribirse las simulaciones? 286

Fidelidad de las simulaciones 287

Las simulaciones se deben probar 288

¿Qué hacer si no hay una simulación disponible? 289

Stubbing 289

Los peligros de abusar del stubbing 290

¿Cuándo es adecuado utilizar stubbing? 292

Pruebas de interacción 292

Preferencia de las pruebas de estado a las pruebas de interacción 292

¿Cuándo son apropiadas las pruebas de interacción? 294

Mejores prácticas para las pruebas de interacción 294

Conclusión 297

Resumen 297

14 Pruebas más grandes 299

¿Qué son las «pruebas más grandes»? 299

Fidelidad 300

Brechas frecuentes en las pruebas unitarias 301

¿Por qué no realizar pruebas más grandes? 303

Pruebas de gran tamaño en Google 304

Pruebas más grandes y el tiempo 305

Pruebas más grandes a escala de Google 306

Estructura de una prueba grande 308

El sistema bajo prueba 308

Datos para la prueba 313

Verificación 314

Tipos de pruebas más grandes 315

Prueba funcional de uno o más binarios interactivos 316

Pruebas de los navegadores y dispositivos 316

Pruebas de rendimiento, carga y estrés 316

Pruebas de la configuración de implementación 317

Pruebas exploratorias 318

Pruebas de regresión de diferencias A/B 319

UAT 320

Sistemas de sondeo y análisis canario 321

Recuperación en caso de catástrofe e ingeniería del caos 322

Evaluación al usuario 323

Grandes pruebas y el flujo de trabajo del desarrollador 324

Creación de pruebas grandes 325

Ejecución de pruebas grandes 325

Propiedad de las pruebas grandes 328

Conclusión 329

Resumen 330

15 Depreciación 331

¿Por qué hacer depreciación? 332

¿Por qué es tan difícil la depreciación? 333

Depreciación durante el diseño 335

Tipos de depreciación 336

Depreciación recomendada 336

Depreciación obligatoria 337

Advertencias de depreciación 339

Gestión del proceso de depreciación 340

Propietarios de los procesos 340

Hitos 341

Depreciación de las herramientas 342

Conclusión 343

Resumen 344

Parte IV Herramientas

16 Control de versiones y gestión de ramas 345

¿Qué es el «control de versiones»? 345

¿Por qué es importante el control de versiones? 347

VCS centralizado frente a VCS distribuido 350

Fuente de verdad 353

Control de versiones frente a gestión de dependencias 355

Gestión de ramas 355

El trabajo en curso es similar a una rama 355

Ramas de desarrollo 356

Ramas de versión 368

Control de versiones en Google 359

One Version 360

Escenario: varias versiones disponibles 361

La norma «One Version» 362

Casi sin ramas longevas 362

¿Qué pasa con las ramas de versión? 364

Monorepos 365

Futuro del control de versiones 366

Conclusión 368

Resumen 369

17 Code Search 371

La interfaz de usuario de Code Search 372

¿Cómo utilizan los Googlers Code Search? 373

¿Dónde? 373

¿Qué? 374

¿Cómo? 374

¿Por qué? 374

¿Quién y cuándo? 375

¿Por qué una herramienta web independiente? 375

Escala 375

Vista global del código sin necesidad de configuración 376

Especialización 377

Integración con otras herramientas para desarrolladores 377

Presentacición de las API 379

Impacto de la escala en el diseño 379

Latencia de la consulta de búsqueda 380

Latencia del índice 381

Implementación de Google 382

Índice de búsqueda 382

Clasificación 384

Selección de contrapartidas 387

Completitud: repositorio en head 387

Completitud: todos los resultados frente a los más relevantes 388

Completitud: head versus ramas versus toda la historia versus

espacios de trabajo 389

Expresividad: token frente a subcadena frente a expresión regular 390

Conclusión 391

Resumen 392

18 Sistemas de compilación y filosofía de la compilación 393

Propósito de un sistema de compilación 393

¿Qué sucede si no existe un sistema de compilación? 395

Pero todo lo que necesito ¡es un compilador! 395

¿Scripts de shell al rescate? 396

Sistemas de compilación modernos 397

Todo se trata de dependencias 398

Sistemas de compilación basados en tareas 398

Sistemas de compilación basados en artefactos 403

Compilaciones distribuidas 410

Tiempo, escala, contrapartidas 414

Tratamiento de los módulos y las dependencias 415

La utilización de módulos detallados y la regla 1:1:1 415

Minimización de la visibilidad de los módulos 416

Gestión de dependencias 416

Conclusión 422

Resumen 423

19 Critique, herramienta de revisión del código de Google 425

Principios de las herramientas de revisión del código 425

Flujo de revisión de código 427

Notificaciones 428

Nivel 1: realización de un cambio 429

Diferenciaciones 429

Resultados del análisis 431

Integración estricta de herramientas 432

Nivel 2: revisión de la solicitud 433

Niveles 3 y 4: comprensión y comentarios del cambio 434

Comentarios 435

Comprensión del estado de un cambio 436

Nivel 5: aprobación del cambio (puntuación del cambio) 438

Nivel 6: confirmación del cambio 440

Después de la confirmación: seguimiento del historial 440

Conclusión 441

Resumen 442

20 Análisis estático 443

Características del análisis estático eficaz 444

Escalabilidad 444

Usabilidad 444

Lecciones clave para hacer que el análisis estático funcione 445

Céntrese en la satisfacción de los desarrolladores 445

Haga que el análisis estático forme parte del flujo principal

de trabajo del desarrollador 446

Permita la contribución de los usuarios 447

Tricorder: plataforma de análisis estático de Google 447

Herramientas integradas 449

Canales de retroalimentación integrados 450

Sugerencias de correcciones 451

Personalización por proyectos 451

Presubmits 453

Integración en el compilador 453

Análisis durante la edición y navegación por el código 454

Conclusión 455

Resumen 455

21 Gestión de dependencias 457

¿Por qué resulta tan difícil la gestión de dependencias? 459

Requisitos conflictivos y dependencias de diamante 459

Importación de dependencias 461

Promesas de compatibilidad 462

Consideraciones al hacer la importación 464

Cómo gestiona Google la importación de dependencias 465

Gestión de dependencias, en teoría 468

Nada cambia (también conocido como el «modelo

de dependencias estáticas») 468

Versionado semántico 469

Modelos de distribución por paquetes 471

Live at Head 471

Limitaciones de SemVer 473

SemVer puede que asegure una compatibilidad superior a la real 474

SemVer podría exagerar 474

Motivaciones 476

Minimum Version Selection 477

Entonces, ¿funciona SemVer? 478

Gestión de dependencias con recursos infinitos 479

Exportación de dependencias 482

Conclusión 486

Resumen 486

22 Cambios a gran escala 489

¿Qué es un «cambio a gran escala»? 490

¿Quién negocia con las LSC? 491

Obstáculos a los cambios atómicos 493

Limitaciones técnicas 493

Fusión de conflictos 494

Sin cementerios encantados 494

Heterogeneidad 495

Pruebas 496

Revisión de código 498

Infraestructura LSC 499

Políticas y cultura 500

Comprensión de la base de código 501

Gestión de cambios 502

Pruebas 502

Soporte del lenguaje 502

El proceso LSC 504

Autorización 504

Creación de cambios 505

Fragmentación y envío 506

Limpieza 509

Conclusión 510

Resumen 510

23 Integración continua 511

Conceptos de IC 513

Bucles de retroalimentación rápida 513

Automatización 515

Prueba continua 517

Desafíos de la IC 523

Pruebas herméticas 524

Integración continua en Google 527

Caso de estudio de IC: Google Takeout 530

Pero no puedo permitirme IC 537

Conclusión 537

Resumen 538

24 Entrega continua 539

Modismos de entrega continua en Google 540

La rapidez es un deporte de equipo: cómo dividir una implementación

en partes manejables 541

Evaluación de cambios en el aislamiento: funciones de protección

de banderas 542

La lucha por conseguir agilidad: configuración de un tren de lanzamiento 543

Ningún binario es perfecto 544

Cumpla con su fecha límite de lanzamiento 545

Calidad y enfoque en el usuario: envíe solo lo que se utilice 545

Desplazamiento a la izquierda: tomar antes decisiones basadas en los datos 546

Cambio de la cultura del equipo: creación de disciplina en el despliegue 548

Conclusión 549

Resumen 550

25 La computación como servicio 551

Dominio del entorno informático 552

Automatización del trabajo 552

Contenerización y tenencia múltiple 554

Resumen 557

Escritura de software para la computación gestionada 557

Arquitectura para el fracaso 557

Trabajos por lotes frente a trabajos de servicio 559

Gestión del estado 561

Conexión a un servicio 563

Código único 564

CaaS con el tiempo y la escala 565

Los contenedores como abstracción 565

Un servicio para gobernarlos a todos 568

Configuración enviada 570

Elección de un servicio informático 571

Centralización frente a personalización 573

Nivel de abstracción: sin servidores 575

Público versus privado 579

Conclusión 581

Resumen 582

Parte V Conclusión

Epílogo 583

Índice 585