book

Ingeniería de software en Google

by Titus Winters, Tom Manshreck, Hyrum Wright

September 2024

Intermediate to advanced

602 pages

21h 5m

Spanish

O'Reilly Media, Inc.

Audiobook available

Read now

Unlock full access

Programación a lo largo del tiempoLa perspectiva de GoogleLo que este libro no esComentarios de despedidaConvenciones utilizadas en este libroAprendizaje en línea O'ReillyCómo contactar con nosotrosAgradecimientos
Tiempo y cambioLey de HyrumEjemplo: Ordenación Hash¿Por qué no aspirar simplemente a que "nada cambie"?Escala y eficaciaPolíticas que no se adaptanPolíticas que se adaptan bienEjemplo: Actualización del compiladorCambiar a la izquierdaContrapartidas y costesEjemplo: MarcadoresAportaciones a la toma de decisionesEjemplo: Construcciones distribuidasEjemplo: Decidir entre tiempo y escalaRevisar decisiones, cometer erroresIngeniería de software frente a programaciónConclusiónTL;DRs
Ayúdame a ocultar mi códigoEl mito del genioLa ocultación se considera perjudicialDetección precozEl factor autobúsRitmo de progresoEn resumen, no te escondasTodo es cuestión de equipoLos tres pilares de la interacción social¿Por qué son importantes estos pilares?Humildad, respeto y confianza en la prácticaCultura post mortem sin culpaSer GoogleyConclusiónTL;DRs
Retos para el aprendizajeFilosofíaPreparando el escenario: Seguridad psicológicaTutoríaSeguridad psicológica en grandes gruposAumenta tus conocimientosHaz preguntasComprender el contextoEscala tus preguntas: Pregunta a la ComunidadChats de grupoListas de correoYAQS: Plataforma de Preguntas y RespuestasAmpliar tus conocimientos: Siempre tienes algo que enseñarHorario de oficinaClases y charlas técnicasDocumentaciónCódigoAmpliar los conocimientos de tu organizaciónCultivar una cultura de intercambio de conocimientosEstablecer fuentes canónicas de informaciónMantente informadoLegibilidad: Tutoría estandarizada mediante la revisión del código¿Qué es el proceso de legibilidad?¿Por qué tener este proceso?ConclusiónTL;DRs
La parcialidad es la normaComprender la necesidad de diversidadCrear capacidad multiculturalHacer que la Diversidad sea AccionableRechazar los Enfoques SingularesDesafiar los procesos establecidosValores frente a resultadosMantén la curiosidad, avanzaConclusiónTL;DRs
Directores y Jefes Técnicos (y ambos)El Director de IngenieríaEl jefe técnicoEl Director TécnicoPasar de un papel de colaborador individual a un papel de liderazgoLo único que hay que temer es... bueno, todoLiderazgo de servicioEl Director de IngenieríaGerente es una palabra de cuatro letrasEl Director de Ingeniería de hoyAntipatronesAntipatrón: Contratar empujadoresAntipatrón: Ignora a los de bajo rendimientoAntipatrón: Ignorar los problemas humanosAntipatrón: Sé amigo de todosAntipatrón: Comprometer el Baremo de ContrataciónAntipatrón: Trata a tu equipo como a niñosPatrones positivosPierde el egoSé un Maestro ZenSé un catalizadorElimina los obstáculosSé un maestro y un mentorEstablece objetivos clarosSé sinceroRastrear la felicidadLa pregunta inesperadaOtros consejos y trucosLas personas son como las plantasMotivación intrínseca frente a motivación extrínsecaConclusiónTL;DRs
Decide siempreLa parábola del aviónIdentifica los BlindersIdentificar las ventajas y desventajas claveDecide, luego iteraSiempre te vasTu misión: Construir un equipo "autoconducidoDividir el espacio del problemaEscala siempreEl ciclo del éxitoImportante frente a urgenteAprende a lanzar pelotasProteger tu energíaConclusiónTL;DRs

¿Por qué debemos medir la productividad de la ingeniería?Triaje: ¿Merece la pena medirlo?Seleccionar métricas significativas con objetivos y señalesObjetivosSeñalesMétricasUtilizar los datos para validar las métricasActuar y controlar los resultadosConclusiónTL;DRs
¿Por qué tener normas?Crear las normasPrincipios rectoresLa Guía de EstiloCambiar las normasEl procesoLos árbitros del estiloExcepcionesOrientaciónAplicación de las normasComprobadores de erroresFormateadores de códigoConclusiónTL;DRs
Flujo de revisión del códigoCómo funciona la revisión del código en GoogleBeneficios de la revisión del códigoCorrección del códigoComprensión del códigoCoherencia del códigoBeneficios psicológicos y culturalesCompartir conocimientosBuenas prácticas en la revisión del códigoSé educado y profesionalEscribe pequeños cambiosEscribe buenas descripciones de los cambiosReduce al mínimo los revisoresAutomatiza cuando sea posibleTipos de revisiones del códigoComentarios sobre el Código GreenfieldCambios de comportamiento, mejoras y optimizacionesCorrección de errores y retrocesosRefactorizaciones y cambios a gran escalaConclusiónTL;DRs
¿Qué se considera documentación?¿Por qué es necesaria la documentación?La documentación es como el códigoConoce a tu públicoTipos de públicoTipos de documentaciónDocumentación de referenciaDocumentos de diseñoTutorialesDocumentación conceptualPáginas de destinoRevisiones de la documentaciónFilosofía de la documentaciónQUIÉN, QUÉ, CUÁNDO, DÓNDE y POR QUÉEl principio, el medio y el finalLos parámetros de una buena documentaciónDocumentos obsoletos¿Cuándo necesitas redactores técnicos?ConclusiónTL;DRs
¿Por qué hacemos pruebas?La historia del servidor web de GooglePruebas a la velocidad del desarrollo modernoEscribir, Ejecutar, ReaccionarVentajas de probar el códigoDiseñar un conjunto de pruebasTamaño de la pruebaAlcance de la pruebaLa regla BeyoncéNota sobre la cobertura del códigoPruebas a escala de GoogleLas trampas de un gran conjunto de pruebasHistoria de las pruebas en GoogleClases de OrientaciónPrueba certificadaPruebas en el retreteProbar la cultura hoyLos límites de las pruebas automatizadasConclusiónTL;DRs
La importancia de la mantenibilidadPrevenir las pruebas de fragilidadEsfuérzate por realizar pruebas sin cambiosPrueba mediante API públicasEstado de prueba, no interaccionesRedactar pruebas clarasHaz que tus pruebas sean completas y concisasProbar comportamientos, no métodosNo pongas lógica en los testsEscribir mensajes de fallo clarosPruebas y código compartido: DAMP, no DRYValores compartidosConfiguración compartidaAyudantes compartidos y validaciónDefinición de la infraestructura de pruebasConclusiónTL;DRs
El impacto de las pruebas dobles en el desarrollo de softwarePrueba de dobles en GoogleConceptos básicosUn ejemplo de prueba dobleCosturasMarcos de imitaciónTécnicas para utilizar dobles de pruebaFingiendoPincharPruebas de interacciónImplementaciones realesPrefiere el realismo al aislamientoCómo decidir cuándo utilizar una aplicación realFingiendo¿Por qué son importantes las falsificaciones?¿Cuándo deben escribirse las falsificaciones?La fidelidad de las falsificacionesLas falsificaciones deben comprobarseQué hacer si no hay una falsificación disponiblePincharLos peligros de abusar de los tacos¿Cuándo es apropiado el "stubbing"?Pruebas de interacciónPrefiere las Pruebas de Estado a las Pruebas de Interacción¿Cuándo son adecuadas las Pruebas de Interacción?Buenas prácticas para las pruebas de interacciónConclusiónTL;DRs
¿Qué son las pruebas de mayor tamaño?FidelidadLagunas comunes en las pruebas unitarias¿Por qué no hacer pruebas más grandes?Pruebas más grandes en GooglePruebas más largas y tiempoPruebas más grandes a escala de GoogleEstructura de un gran testEl sistema a pruebaDatos de pruebaVerificaciónTipos de pruebas más grandesPruebas funcionales de uno o más binarios interactuantesPruebas de navegadores y dispositivosPruebas de rendimiento, carga y estrésPruebas de configuración de la ImplementaciónPruebas exploratoriasPruebas de Regresión A/BUATAnálisis de probers y canariosRecuperación de catástrofes e ingeniería del caosEvaluación del usuarioGrandes pruebas y el flujo de trabajo del desarrolladorCreación de pruebas de gran tamañoEjecutar pruebas grandesPoseer grandes pruebasConclusiónTL;DRs
¿Por qué desaprobar?¿Por qué es tan difícil la desaprobación?Depreciación durante el diseñoTipos de amortizaciónDesaprobación consultivaAmortización obligatoriaAdvertencias de desaprobaciónGestionar el proceso de amortizaciónPropietarios de procesosHitosHerramientas de eliminaciónConclusiónTL;DRs
¿Qué es el control de versiones?¿Por qué es importante el control de versiones?VCS centralizado frente a VCS distribuidoFuente de la VerdadControl de versiones frente a gestión de dependenciasGestión de SucursalesEl trabajo en curso es similar a una ramaRamas de desarrolloLiberar ramasControl de versiones en GoogleUna versiónEscenario: Varias versiones disponiblesLa regla de la "versión única(Casi) sin sucursales de larga duración¿Qué pasa con las ramas de liberación?MonoreposEl futuro del control de versionesConclusiónTL;DRs
La interfaz de búsqueda de código¿Cómo utilizan los Googlers la Búsqueda por Código?¿Dónde?¿Cómo?¿Cómo?¿Por qué?¿Quién y cuándo?¿Por qué una herramienta web independiente?EscalaConfiguración Cero Vista Global del CódigoEspecializaciónIntegración con otras herramientas de desarrolloExposición al APIImpacto de la escala en el diseñoLatencia de la consulta de búsquedaÍndice LatenciaAplicación de GoogleÍndice de búsquedaClasificaciónContrapartidas seleccionadasIntegridad: Repositorio en la cabeceraIntegridad: Todos los resultados frente a los más relevantesIntegridad: Cabeza Versus Ramas Versus Todo el Historial Versus Espacios de TrabajoExpresividad: Token frente a subcadena frente a RegexConclusiónTL;DRs
Finalidad de un sistema de construcción¿Qué ocurre sin un sistema de construcción?¡Pero lo único que necesito es un compilador!¿Scripts Shell al rescate?Sistemas de construcción modernosTodo es cuestión de dependenciasSistemas de construcción basados en tareasSistemas de construcción basados en artefactosConstrucciones distribuidasTiempo, escala, compensacionesTratar con módulos y dependenciasUtilizar módulos de grano fino y la regla 1:1:1Minimizar la visibilidad del móduloGestionar las dependenciasConclusiónTL;DRs
Principios de las herramientas de revisión de códigoFlujo de revisión del códigoNotificacionesFase 1: Crear un cambioDifusiónResultados del análisisEstrecha integración de herramientasFase 2: Solicitud de revisiónEtapas 3 y 4: Comprender y comentar un cambioComentandoComprender el estado de un cambioEtapa 5: Aprobación de cambios (Puntuación de un cambio)Etapa 6: Comprometerse a cambiarDespués del Compromiso: Seguimiento del historialConclusiónTL;DRs
Características de un análisis estático eficazEscalabilidadUsabilidadLecciones clave para que funcione el análisis estáticoCentrarse en la felicidad de los desarrolladoresHaz que el análisis estático forme parte del flujo de trabajo básico del desarrolladorCapacita a los usuarios para contribuirTricorder: La plataforma de análisis estático de GoogleHerramientas integradasCanales de retroalimentación integradosArreglos sugeridosPersonalización por proyectoPresubmiteIntegración del compiladorAnálisis mientras se edita y navega por el códigoConclusiónTL;DRs
¿Por qué es tan difícil gestionar la dependencia?Requisitos contradictorios y dependencias diamanteImportar relacionesPromesas de compatibilidadConsideraciones al importarCómo gestiona Google la importación de dependenciasLa gestión de la dependencia, en teoríaNada cambia (también conocido como modelo de dependencia estática)Versionado semánticoModelos de distribución combinadaEn directo en HeadLas limitaciones de SemVerSemVer podría sobrecargarseSemVer podría prometer más de la cuentaMotivacionesSelección de la versión mínimaEntonces, ¿Funciona SemVer?Gestión de la dependencia con recursos infinitosExportar relacionesConclusiónTL;DRs
¿Qué es un cambio a gran escala?¿Quién trata con las LSC?Barreras a los cambios atómicosLimitaciones técnicasFusionar conflictosNo hay cementerios embrujadosHeterogeneidadPruebaRevisión del CódigoInfraestructura LSCPolíticas y culturaConocimiento del código baseGestión del cambioPruebaApoyo lingüísticoEl proceso LSCAutorizaciónCreación de cambiosSeparación y envíoLimpiezaConclusiónTL;DRs
Conceptos de ICBucles de realimentación rápidaAutomatizaciónPruebas continuasDesafíos de la ICPruebas herméticasIC en GoogleEstudio de caso de CI: Google TakeoutPero no puedo permitirme la ICConclusiónTL;DRs
Modismos de Entrega Continua en GoogleLa velocidad es un deporte de equipo: Cómo dividir una Implementación en Piezas ManejablesEvaluación de los cambios en el aislamiento: Funciones de protección de banderasEsforzarse por la agilidad: Configurar un tren de liberaciónNingún binario es perfectoCumple el plazo de publicaciónCalidad y orientación al usuario: Enviar sólo lo que se utilizaCambiar a la izquierda: tomar antes decisiones basadas en datosCambiar la cultura de equipo: Crear Disciplina en la ImplementaciónConclusiónTL;DRs
Domar el entorno informáticoAutomatización del trabajoContainerización y MultitenancyResumenEscribir software para la informática gestionadaArquitectura para el fracasoLote frente a raciónGestionar el EstadoConectarse a un servicioCódigo únicoCaaS en el tiempo y a escalaLos contenedores como abstracciónUn servicio para gobernarlos a todosConfiguración enviadaElegir un servicio informáticoCentralización frente a personalizaciónNivel de abstracción: Sin servidorPúblico frente a privadoConclusiónTL;DRs

Content preview from Ingeniería de software en Google

Capítulo 4. Ingeniería para la equidad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Escrito por Demma Rodriguez

Editado por Riona MacNamara

En capítulos anteriores, hemos explorado el contraste entre la programación como la producción de código que aborda el problema del momento, y la ingeniería de software como la aplicación más amplia de código, herramientas, políticas y procesos a un problema dinámico y ambiguo que puede abarcar décadas o incluso toda la vida. En este capítulo, hablaremos de las responsabilidades únicas de un ingeniero cuando diseña productos para una amplia base de usuarios. Además, evaluaremos cómo una organización, al adoptar la diversidad, puede diseñar sistemas que funcionen para todos, y evitar perpetuar el daño contra nuestros usuarios.

A pesar de lo nuevo que es el campo de la ingeniería de software, aún somos más nuevos a la hora de comprender el impacto que tiene sobre las personas infrarrepresentadas y las sociedades diversas. No hemos escrito este capítulo porque sepamos todas las respuestas. No las conocemos. De hecho, entender cómo diseñar productos que empoderen y respeten a todos nuestros usuarios es algo que Google todavía está aprendiendo a hacer. Hemos tenido muchos fracasos públicos a la hora de proteger a nuestros usuarios más vulnerables, y por eso escribimos este capítulo, porque el camino hacia productos más equitativos empieza por evaluar nuestros propios fracasos ...