Envíos gratis en compras superiores a $60.000

Ingeniería de software en Google

$51.596

  • Envío gratis en compras superiores a $60.000
  • Autor:

    • Titus Winters
    • Tom Manshreck
    • Hyrum Wright

    Páginas: 646

    Editorial: Alfaomega – Marcombo

    ISBN: 9788426734440 Categoría:

    Descripción

    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

    Ir a Arriba