000			17041nam a22001937a 4500
003			OSt
005			20250403140417.0
008			230418b |||||||| |||| 00| 0 eng d
020			_a978-958-778-851-8
040			_aB-ISTTENA
041			_aEsp
245			_aIngeniería de Software en Google _bLecciones sobre programación aprendidas a lo largo del tiempo _cTitus Winters; Tom Manshreck y Hyrum Wright
250			_a1ra Ed.
260			_aColombia _bMarcombo,S.L _c2022
300			_a620 P. _c23.8 x 16.3 cm.
505			_aINDICE -Prólogo -Prefacio. -Parte I. Tesis 1. ¿Qué es la ingenieria de software? -Tiempo y cambio -Ley de Hyrum.. -Ejemplo: ordenación hash -¿Por qué no aspirar a que «nada cambie»?. -Escala y eficiencia.. -Políticas que no escalan. -Políticas que escalan adecuadamente. -Ejemplo: actualización del compilador. Desplazamiento hacia la izquierda Contrapartidas y costes. -Ejemplo: rotuladores. -Aportaciones a la toma de decisiones -Ejemplo: compilaciones distribuidas -Ejemplo: decidir entre tiempo y escala Revisar decisiones, cometer errores Ingeniería de software frente a programación Conclusión -Resumen 2. Cómo trabajar bien en equipo -Ayúdeme a ocultar mi código -El mito del genio -La ocultación se considera perjudicial.... -Detección temprana -El factor autobús... -Ritmo del progreso -En resumen, no se esconda. -Todo es cuestión de equipo. -Los tres pilares de la interacción social -¿Por qué importan estos pilares?... -Humildad, respeto y confianza en la práctica. -Cultura post mortem sin sentimiento de culpa Ser Googley -Conclusión -Resumen. -3. Compartir conocimientos. -Desafios para el aprendizaje. -Filosofia. -Preparación del escenario: seguridad psicológica -Tutoria. -Seguridad psicológica en grupos grandes. -Aumente sus conocimientos -Haga preguntas -Comprenda el contexto. -Escalado de las preguntas: pregunte a la comunidad. -Chats de grupo -Listas de correo electrónico -YAQS: plataforma de preguntas y respuestas -Escalado del conocimiento: siempre hay algo que enseñar -Horas de oficina -Charlas y clases de tecnologia -Documentación.. -Código -Escalado de los conocimientos de la organización. -Cultivar la cultura de compartir el conocimiento. -Establecimiento de fuentes canónicas de información. -Manténgase al día. -Legibilidad: tutorías estandarizadas a través de la revisión del código ¿Qué es el proceso de legibilidad?. -¿Por qué someterse a este proceso? -Conclusión. -Resumen. 4. Ingenieria para la equidad -Los prejuicios son la norma. -Comprensión de la necesidad de la diversidad. -Desarrollo de capacidades multiculturales. -Hacer que se pueda procesar la diversidad -Rechazo de enfoques singulares. -Desafio a los procesos establecidos Valores frente a resultados Mantener la curiosidad, seguir adelante. -Conclusión -Resumen. 5. Cómo liderar un equipo -Gerentes y líderes en tecnologia (y ambos) -El gerente de ingenieria. -El líder en tecnología. -El gerente lider de tecnología -Pasar de la función de colaborador individual a la función de liderazgo..... -Lo único que hay que temer es..., bueno, todo -Liderazgo de servicio -El gerente de ingenieria. -«Gerente» es una palabra de cuatro letras -El gerente de ingeniería en la actualidad -Antipatrones. -Antipatrón: contratar a personas fáciles de manejar -Antipatrón: ignorar a las personas de bajo rendimiento. -Antipatrón: ignorar los problemas de carácter personal. -Antipatrón: ser amigo de todos -Antipatrón: comprometer el listón de contratación -Antipatrón: tratar al equipo como si fueran niños. -Patrones positivos. -Perder el ego -Ser un maestro zen. -Ser catalizador -Eliminar obstáculos -Ser maestro y mentor. -Establecer metas claras -Ser honesto. -Rastrear la satisfacción -La pregunta inesperada. -Otros consejos y trucos -Las personas somos como las plantas -Motivación intrínseca frente a motivación extrínseca. -Conclusión -Resumen. -6. Liderazgo a escala -Siempre hay que decidir. -La parábola del aeroplano. -Identificación de las orejeras. -Señalar las contrapartidas clave Decidir y, después, repetir Siempre hay que dejar solo al equipo. -Su misión: formar a un equipo «autónomo>>> División del espacio del problema.. -Siempre hay que mantenerse escalando El ciclo del éxito -Lo importante frente a lo urgente. -Aprender a dejar caer pelotas al suelo. -Proteja su energia. -Conclusión. -Resumen. 7. Medición de la productividad de la ingenieria. -¿Por qué debemos medir la productividad de la ingeniería? -Triaje: ¿vale la pena medirlo?. -Selección de métricas significativas con objetivos y señales. -Objetivos -Señales -Métricas. -Uso de datos para validar métricas. -Actuar y realizar un seguimiento de los resultados.. -Conclusión. -Resumen. 8. Guias de estilo y normas. -¿Por qué tenemos normas?. -Creación de normas -Principios rectores. -Guía de estilo -Cambio de las normas -El proceso. -Árbitros de estilo -Excepciones -Orientación. -Aplicación de las normas. -Comprobadores de errores. -Formateadores de código. -Conclusión -Resumen. 9. Revisión del código -Flujo de revisión del código. -Cómo funciona la revisión de código en Google. -Beneficios de la revisión de código. -Corrección de código -Comprensión de código. -Coherencia del código. -Beneficios psicológicos y culturales. -Compartir conocimientos -Mejores prácticas de la revisión de código. -Sea cortés y profesional -Escriba cambios pequeños. -Escriba descripciones de los cambios que tengan calidad. -Mantenga al mínimo el número de revisores -Automatizar donde sea posible. -Tipos de revisiones de código... -Revisiones del código greenfield.. -Cambios de comportamiento, mejoras y optimizaciones. -Corrección de errores y reversiones. -Conclusión. -Refactorizaciones y cambios a gran escala -Resumen 10. Documentación -¿Qué calificar como «documentación»? -¿Por qué es necesaria la documentación? -La documentación es como el código -Conozca a su audiencia. -Tipos de audiencias -Tipos de documentación -Documentación de referencia -Documentos de diseño -Tutoriales -Documentación conceptual. -Páginas de destino -Revisiones de la documentación. -Filosofia de la documentación -QUIÊN, QUẾ, CUÁNDO, DÓNDE Y POR QUÉ. -El principio, la parte central y el final -Parámetros de la documentación de calidad. -Documentación obsoleta -¿Cuándo necesita a escritores técnicos?. -Conclusión. -Resumen.. 11. Descripción general de las pruebas -¿Por qué escribimos pruebas? -La historia de Google Web Server -Pruebas al ritmo del desarrollo moderno -Escribir, ejecutar, reaccionar. -Ventajas de probar el código. -Diseño de un conjunto de pruebas. -Tamaño de las pruebas.. -Alcance de las pruebas -Regla de Beyoncé -Nota sobre la cobertura del código. -Pruebas a escala de Google... -Dificultades de un gran conjunto de pruebas -Historial de pruebas en Google.. -Clases de orientación. -Pruebas certificadas -Pruebas en los aseos. -La cultura de pruebas actualmente. -Límites de las pruebas automatizadas -Conclusión. -Resumen. 12. Pruebas unitarias -Importancia del mantenimiento. -Prevención de pruebas frágiles -Esfuércese en lograr pruebas que no cambien. -Pruebas a través de API públicas. -Comprobar el estado, no las interacciones.. -Escriba pruebas claras -Haga que las pruebas sean completas y concisas. -Pruebe los comportamientos, no los métodos. -No ponga la lógica en las pruebas. -Escriba mensajes de error claros. -Pruebas y uso compartido de código: DAMP, no DRY -Valores compartidos. -Configuración compartida -Helpers compartidos y validación. -Definición de infraestructura de pruebas -Conclusión. -Resumen. 13. Dobles de pruebas. -El impacto de los dobles de pruebas en el desarrollo del software. Dobles de pruebas en Google -Conceptos básicos.. -Un ejemplo de dobles de pruebas. -Costuras.. -Marcos de trabajo de simulación -Técnicas para utilizar los dobles de pruebas. -Simulación -Stubbing.. -Pruebas de interacción -Implementaciones reales -Preferencia de las implementaciones reales a las aisladas. -Cómo decidir cuándo utilizar una implementación real -Simulación -¿Por qué son importantes las simulaciones?. -¿Cuándo deben escribirse las simulaciones?. -Fidelidad de las simulaciones. -Las simulaciones se deben probar -Qué hacer si no hay una simulación disponible?. -Stubbing. -Los peligros de abusar del stubbing. -¿Cuándo es adecuado utilizar stubbing? -Pruebas de interacción. -Preferencia de las pruebas de estado a las pruebas de interacción. -¿Cuándo son apropiadas las pruebas de interacción?. -Mejores prácticas para las pruebas de interacción -Conclusión. -Resumen. 14. Pruebas más grandes. -¿Qué son las pruebas más grandes»?. -Fidelidad.. -Brechas frecuentes en las pruebas unitarias -¿Por qué no realizar pruebas más grandes?. -Pruebas de gran tamaño en Google.. -Pruebas más grandes y el tiempo. -Pruebas más grandes a escala de Google. -Estructura de una prueba grande -El sistema bajo prueba. -Datos para la prueba.. -Verificación -Tipos de pruebas más grandes. -Prueba funcional de uno o más binarios interactivos. -Pruebas de los navegadores y dispositivos -Pruebas de rendimiento, carga y estrés. -Pruebas de la configuración de implementación -Pruebas exploratorias. -Pruebas de regresión de diferencias A/B -UAT -Sistemas de sondeo y análisis canario -Recuperación en caso de catástrofe e ingeniería del caos -Evaluación al usuario -Grandes pruebas y el flujo de trabajo del desarrollador. -Creación de pruebas grandes -Ejecución de pruebas grandes. -Propiedad de las pruebas grandes -Conclusión. -Resumen. 15. Depreciación. -¿Por qué hacer depreciación?. -¿Por qué es tan dificil la depreciación? -Depreciación durante el diseño -Tipos de depreciación Depreciación recomendada. -Depreciación obligatoria. -Advertencias de depreciación -Gestión del proceso de depreciación. -Propietarios de los procesos. -Hitos -Depreciación de las herramientas.. -Conclusión -Resumen. -Parte IV. Herramientas 16. Control de versiones y gestión de ramas. -¿Qué es el «control de versiones»?. -¿Por qué es importante el control de versiones?. -VCS centralizado frente a VCS distribuido -Fuente de verdad. -Control de versiones frente a gestión de dependencias. -Gestión de ramas -El trabajo en curso es similar a una rama -Ramas de desarrollo. -Ramas de versión -Control de versiones en Google. -One-Version -Escenario: varias versiones disponibles -La norma «One-Version" Casi sin ramas longevas -¿Qué pasa con las ramas de versión?. -Monorepos -Futuro del control de versiones -Conclusión.. -Resumen -17. Code Search -La interfaz de usuario de Code Search. -¿Cómo utilizan los Googlers Code Search?. -¿Dónde?. -¿Qué? -¿Cómo? -¿Por qué? -¿Quién y cuándo? -¿Por qué una herramienta web independiente? -Escala. -Vista global del código sin necesidad de configuración. -Especialización -Integración con otras herramientas para desarrolladores. -Presentacición de las API. -Impacto de la escala en el diseño. -Latencia de la consulta de búsqueda -Latencia del indice -Implementación de Google -Indice de búsqueda. -Clasificación -Selección de contrapartidas. -Completitud: repositorio en head. -Completitud: todos los resultados frente a los más relevantes. -Completitud: head versus ramas versus toda la historia versus espacios de trabajo. -Expresividad: token frente a subcadena frente a expresión regular. -Conclusión. -Resumen. 18. Sistemas de compilación y filosofia de la compilación Propósito de un sistema de compilación. -¿Qué sucede si no existe un sistema de compilación? -Pero todo lo que necesito jes un compilador! -¿Scripts de shell al rescate? -Sistemas de compilación modernos. -Todo se trata de dependencias. -Sistemas de compilación basados en tareas. -Sistemas de compilación basados en artefactos. -Compilaciones distribuidas. -Tiempo, escala, contrapartidas -Tratamiento de los módulos y las dependencias.. -La utilización de módulos detallados y la regla -Minimización de la visibilidad de los módulos -Gestión de dependencias -Conclusión -Resumen 19. Critique, herramienta de revisión del código de Google. -Principios de las herramientas de revisión del código. -Flujo de revisión de código.... -Notificaciones. -Nivel 1: realización de un cambio. -Diferenciaciones. -Resultados del análisis. -Integración estricta de herramientas. -Nivel 2: revisión de la solicitud. -Niveles 3 y 4: comprensión y comentarios del cambio. -Comentarios -Comprensión del estado de un cambio -Nivel 5: aprobación del cambio (puntuación del cambio). -Nivel 6: confirmación del cambio. -Después de la confirmación: seguimiento del historial. -Conclusión -Resumen 20. Análisis estático -Características del análisis estático eficaz -Escalabilidad. -Usabilidad -Lecciones clave para hacer que el análisis estático funcione. -Céntrese en la satisfacción de los desarrolladores. -Haga que el análisis estático forme parte del flujo principal de trabajo del desarrollador. -Permita la contribución de los usuarios -Tricorder: plataforma de análisis estático de Google. -Herramientas integradas. -Canales de retroalimentación integrados -Sugerencias de correcciones. -Personalización por proyectos -Presubmits.. -Integración en el compilador -Análisis durante la edición y navegación por el código. -Conclusión. -Resumen 21. Gestión de dependencias. -¿Por qué resulta tan dificil la gestión de dependencias?. -Requisitos conflictivos y dependencias de diamante. -Importación de dependencias.... -Promesas de compatibilidad Consideraciones al hacer la importación. -Cómo gestiona Google la importación de dependencias. -Gestión de dependencias, en teoría. -Nada cambia (también conocido como el «modelo de dependencias estáticas»). -Versionado semántico.. -Modelos de distribución por paquetes. -Live at Head.. -Limitaciones de SemVer.. -SemVer puede que asegure una compatibilidad superior a la real SemVer podría exagerar.. -Motivaciones -Minimum Version Selection. -Entonces, ¿funciona Sem Ver?. -Gestión de dependencias con recursos infinitos -Exportación de dependencias -Conclusión. -Resumen. 22. Cambios a gran escala -¿Qué es un «cambio a gran escala»? -¿Quién negocia con las LSC? -Obstáculos a los cambios atómicos -Limitaciones técnicas -Fusión de conflictos. -Sin cementerios encantados -Heterogeneidad. -Pruebas -Revisión de código -Infraestructura LSC. -Políticas y cultura.. -Comprensión de la base de código -Gestión de cambios.. -Pruebas -Soporte del lenguaje. -El proceso LSC. -Autorización. -Creación de cambios -Fragmentación y envío. -Limpieza -Conclusión. -Resumen. 23. Integración continua. -Conceptos de I. -Bucles de retroalimentación rápida. -Automatización. -Prueba continua -Desafios de la IC.. -Pruebas herméticas. -Integración continua en Google -Caso de estudio de IC: Google Takeout. -Pero no puedo permitirme IC..... -Conclusión -Resumen. 24. Entrega continua. -Modismos de entrega continua en Google. -La rapidez es un deporte de equipo: cómo dividir una implementación en partes manejables -Evaluación de cambios en el aislamiento: funciones de protección de banderas -La lucha por conseguir agilidad: configuración de un tren de lanzamiento.. -Ningún binario es perfecto. -Cumpla con su fecha límite de lanzamiento -Calidad y enfoque en el usuario: envie solo lo que se utilice. -Desplazamiento a la izquierda: tomar antes decisiones basadas en los datos. -Cambio de la cultura del equipo: creación de disciplina en el despliegue -Conclusión -Resumen. 25. La computación como servicio -Dominio del entorno informático -Automatización del trabajo -Contenerización y tenencia múltiple -Resumen -Escritura de software para la computación gestionada -Arquitectura para el fracaso. -Trabajos por lotes frente a trabajos de servicio. -Gestión del estado. -Conexión a un servicio. -Código único -CaaS con el tiempo y la escala. -Los contenedores como abstracción -Un servicio para gobernarlos a todos.. -Configuración enviada. -Elección de un servicio informático. -Centralización frente a personalización -Nivel de abstracción: sin servidores -Público versus privado -Conclusión -Resumen. -Parte V. Conclusión -Epílogo -Índice.
650			_bCALIDAD DE SOFTWARE
942			_aB-ISTTENA _cBOOK _p18/04/2023 _qErika Calapucha _n14/04/2023
999			_c1004 _d1004