Ingeniería de Software en Google Lecciones sobre programación aprendidas a lo largo del tiempo
Ingeniería de Software en Google Lecciones sobre programación aprendidas a lo largo del tiempo
Titus Winters; Tom Manshreck y Hyrum Wright
- 1ra Ed.
- Colombia Marcombo,S.L 2022
- 620 P. 23.8 x 16.3 cm.
INDICE
-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.
978-958-778-851-8
CALIDAD DE SOFTWARE
INDICE
-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.
978-958-778-851-8
CALIDAD DE SOFTWARE