Vocabulario de desarrollo de software en inglés: significado y ejemplos en español

Estructura compacta para comprobar si un elemento pertenece a un conjunto. Puede indicar que un elemento ausente está presente, pero un filtro estándar bien usado no pasa por alto los elementos insertados.

Estructura que lleva el seguimiento de grupos que no se solapan y permite averiguar el grupo de un elemento y unir grupos eficientemente.

Estudio del coste total de una secuencia de operaciones para obtener un coste por operación, incluso cuando algunas operaciones individuales varían mucho.

Método de ordenación que conserva el orden relativo original de los elementos cuyas claves de ordenación son iguales.

Situación en la que dos entradas distintas producen el mismo valor hash.

Búfer de capacidad fija cuya posición de lectura o escritura vuelve al principio al alcanzar el final.

Una solicitud para integrar cambios de una rama en otra, de modo que el equipo pueda revisarlos y comentarlos antes.

Una instantánea guardada de los cambios de un repositorio, acompañada de un mensaje breve que explica qué se cambió y por qué. También se usa como verbo: guardar cambios en un commit.

Una línea separada de desarrollo dentro de un repositorio, donde se trabaja sin afectar al código principal hasta integrar los cambios.

Combinar los cambios de una rama con los de otra para que ambos trabajos queden en el mismo código.

Lugar donde se almacenan el código de un proyecto y todo su historial de cambios, normalmente gestionado con Git y alojado en línea.

Enviar las confirmaciones locales al repositorio remoto compartido para que otras personas y sistemas puedan verlas.

Situación en la que Git no puede combinar dos ramas automáticamente porque ambas modificaron las mismas líneas y alguien debe elegir la versión correcta.

En Git, cambiar los archivos de trabajo a una rama o commit concreto para ver o modificar esa versión del código.

Descargar al equipo local una copia completa de un repositorio remoto, incluido su historial, para trabajar en él.

En Git, mover los commits de una rama para que partan de un punto más reciente, normalmente la última versión de main, y así obtener un historial lineal.

Sistema que registra los cambios de un conjunto de archivos a lo largo del tiempo para que un equipo pueda compartir el trabajo, ver quién cambió qué y recuperar versiones anteriores.

Sistema de control de versiones gratuito y de código abierto, muy extendido, que registra cambios en el código y permite que varios desarrolladores trabajen en un mismo proyecto.

Descargar los cambios más recientes de un repositorio remoto e integrarlos en la copia local para mantener el código sincronizado con el equipo.

Vista o archivo que muestra las líneas añadidas, eliminadas o modificadas entre dos versiones de código, normalmente en verde y rojo.

Texto breve que describe qué cambia un commit y por qué. El equipo puede consultarlo después para entender el historial del código.

Rama central de un repositorio que contiene la versión oficial y actualizada del código. De ella salen otras ramas y en ella se integran de nuevo.

Rama independiente creada para desarrollar una función o corrección, de modo que el trabajo pueda implementarse y revisarse sin afectar a la rama principal.

Deshacer un cambio creando un commit nuevo que aplica exactamente el efecto contrario, de modo que se recupera el estado anterior y se conserva el historial.

Crear en una plataforma como GitHub una copia propia del repositorio de otra persona, para modificarla libremente y proponer después los cambios al proyecto original.

En Git, guardar temporalmente cambios sin terminar y dejar limpia la copia de trabajo, para cambiar de tarea y recuperarlos después.

En Git, copiar un commit específico de una rama a otra sin integrar la rama entera. En inglés general, elegir solo los elementos más convenientes.

Modelo de colaboración con Git en el que cada colaborador trabaja en una bifurcación propia y luego propone integrar sus cambios en el repositorio principal.

Modo de rebase de Git que permite reordenar, combinar, editar o eliminar commits mientras se reescribe el historial de una rama.

Ancestro común más adecuado de dos commits que Git usa para calcular una fusión de tres vías.

Fusión de Git que adelanta el puntero de la rama destino porque esta no tiene commits propios nuevos desde que se creó la otra rama.

Unir varios commits en uno, normalmente para limpiar el historial de una rama antes de fusionarla o revisarla.

Estado de una copia de trabajo en el que HEAD apunta directamente a un commit en vez de apuntar al nombre de una rama.

Historial local de cambios en referencias, como las posiciones anteriores de HEAD o de una rama.

Checkout que coloca solo rutas seleccionadas del repositorio en el árbol de trabajo y deja fuera las demás.

Copia de un repositorio que incluye una parte limitada del historial de commits en lugar del historial completo del origen.

Fusión que compara dos versiones con un ancestro común para identificar y combinar los cambios hechos a cada lado.

Localizar un cambio en una serie ordenada de revisiones probando un punto medio y reduciendo repetidamente el intervalo.

La práctica de que otras personas del equipo lean y comenten los cambios de código antes de integrarlos, para detectar problemas y compartir conocimientos.

Reorganizar código existente para que sea más claro o fácil de modificar sin cambiar lo que hace para el usuario.

Coste futuro de los atajos que se toman hoy en el código: ahorran tiempo ahora, pero vuelven más lentos y arriesgados los cambios posteriores.

Sigla de looks good to me, un comentario breve de revisión que indica que un cambio de código está aprobado y puede fusionarse.

Comentario opcional y muy pequeño de una revisión sobre nombres, espacios o redacción, que no debería impedir aceptar el cambio; a menudo se abrevia nit.

Ocuparse de los comentarios recibidos, aplicando los cambios solicitados o explicando por qué se elige otra solución.

Herramienta que examina código sin ejecutarlo y señala problemas de estilo, patrones sospechosos y errores sencillos, como variables sin usar.

Escrito directamente en el código fuente en vez de obtenerse de la configuración, una base de datos o la entrada del usuario; cambiarlo exige editar el código.

Señal de que el código podría tener un problema de diseño más profundo, como una función larguísima, lógica duplicada o demasiados parámetros, aunque funcione.

Compañero que lee y comprueba los cambios de código de otra persona, normalmente en una pull request, antes de permitir que se integren.

Aceptar oficialmente que un cambio, plan o solicitud es válido. En una revisión de código, aprobar una pull request permite integrarla.

Que otra persona puede leer y entender rápidamente gracias a nombres claros, una estructura sencilla y funciones breves.

Forma de trabajar que profesionales con experiencia consideran ampliamente eficaz, como probar el código, revisarlo y no guardar contraseñas en texto sin cifrar.

Código sencillo, con nombres claros y buena organización, que otras personas pueden leer, probar y modificar con facilidad, no solo código que funciona.

Que se puede entender, corregir y ampliar con facilidad a lo largo del tiempo, incluso por desarrolladores que no escribieron el código original.

Conjunto acordado de reglas para nombrar elementos del código, como variables, archivos y ramas, de modo que los nombres sean coherentes en todo el proyecto.

Código que nunca se ejecuta o cuyo resultado no se utiliza, como una función antigua que nadie llama; solo dificulta la lectura del proyecto.

Sigla de «Don’t Repeat Yourself» («no te repitas»): principio según el cual cada conocimiento o lógica debe estar en un solo lugar del código, en vez de copiarse.

Nota añadida durante una revisión para preguntar, sugerir o explicar algo sobre una parte concreta de código, texto o cambio.

Conjunto compartido de reglas sobre estilo, estructura, nombres y otras prácticas para mantener la coherencia del código.

Proceso de compilación que genera exactamente el mismo resultado cada vez si se mantienen el código fuente, las herramientas y las entradas.

Medida del código basada en la cantidad de rutas independientes que atraviesan el flujo de control de un programa.

Comprobación temprana que sale de una función o bloque para tratar un caso especial antes de ejecutar la lógica principal.

Antipatrón en el que un cambio conceptual exige muchas modificaciones pequeñas en distintas partes de la base de código.

Antipatrón en que un método depende mucho de los datos de otro objeto, lo que puede indicar que su responsabilidad está mal ubicada.

Examen del código sin ejecutarlo para encontrar posibles errores o comprobar propiedades del programa.

Prueba automatizada pequeña que comprueba una función o clase de forma aislada, separada de la base de datos, la red y el resto del sistema.

Situación concreta que se comprueba con entradas, pasos y un resultado esperado definidos; por ejemplo, que una contraseña incorrecta produzca un mensaje de error.

Situación poco habitual en el límite de lo que espera un programa, como una lista vacía, un nombre muy largo o el 29 de febrero.

Abreviatura de quality assurance: trabajo de comprobar que el software cumple los requisitos y funciona bien; también nombra al equipo responsable.

Error por el que algo que funcionaba deja de hacerlo después de un cambio, como cuando una función nueva rompe otra anterior.

Prueba que comprueba cómo funcionan juntas varias partes de un sistema, por ejemplo el código y una base de datos real.

Medida, a menudo expresada como porcentaje, de cuánto código ejecutan las pruebas automatizadas.

Versión ficticia de un objeto o servicio real que permite controlar su comportamiento y comprobar cómo lo usa el código; también se usa como verbo: simular un servicio.

Prueba que recorre una experiencia completa del usuario por el sistema real, por ejemplo abrir el sitio, iniciar sesión y hacer un pedido, para comprobar que todo funciona en conjunto.

Describe una prueba que a veces pasa y a veces falla sin cambios en el código, a menudo por tiempos, la red o datos compartidos.

Grupo de pruebas que se ejecutan juntas, por ejemplo todas las pruebas unitarias del proyecto o las del módulo de pagos.

Comprobación del software hecha por una persona que recorre pantallas y prueba acciones, en vez de usar guiones que se ejecutan automáticamente.

Uso de código y herramientas para ejecutar pruebas y comparar automáticamente los resultados con lo esperado, de modo que puedan repetirse rápidamente tras cada cambio.

Instrucción de una prueba que comprueba si un resultado coincide con el valor esperado. Si la condición no se cumple, la prueba falla.

Prueba rápida y básica que comprueba que las funciones esenciales operan, por ejemplo que la aplicación arranca y permite iniciar sesión, antes de hacer pruebas más profundas.

Escenario habitual en el que todo ocurre como se espera: la persona introduce datos válidos, nada falla y la tarea termina correctamente.

Sigla de «test-driven development»: escribir primero una prueba que falla, luego el código que la hace pasar y, por último, refactorizarlo, repitiendo ciclos breves.

Copia separada de un sistema, con servidores, datos y configuración propios, donde se prueba el software sin afectar a usuarios reales.

Sigla de «user acceptance testing»: etapa final de pruebas en la que usuarios reales o el cliente comprueban que el software satisface sus necesidades antes de entrar en funcionamiento.

Registro que se genera cuando una aplicación falla e incluye error, traza de pila, dispositivo, versión del sistema y otros datos útiles para hallar la causa.

Datos sobre cómo se usa una aplicación —pantallas visitadas y puntos de abandono— recogidos como eventos para entender el comportamiento y medir funciones.

Porcentaje de usuarios o sesiones que no sufrieron un cierre inesperado durante un periodo; es una medida clave de estabilidad.

Gran variedad de dispositivos, tamaños de pantalla, hardware y versiones del sistema que una aplicación debe admitir, lo que complica las pruebas, sobre todo en Android.

Prueba automatizada que usa la aplicación como una persona: pulsa botones, escribe texto y comprueba lo que aparece en pantalla.

Consumo de batería más rápido de lo normal causado por una aplicación, por ejemplo al rastrear la ubicación continuamente o seguir trabajando en segundo plano.

Espacio que ocupa una aplicación al descargarse y después de instalarse, incluidos su código, imágenes y bibliotecas.

Error de Android, Application Not Responding, que aparece cuando el hilo principal queda bloqueado demasiado tiempo, por ejemplo varios segundos sin responder a un toque.

Versión rápida y rudimentaria de un juego o una función, creada para comprobar si una idea es divertida o funciona antes de invertir tiempo en el arte y el acabado finales.

Sesión en la que varias personas juegan una versión inacabada mientras el equipo observa y recoge comentarios sobre la diversión, la dificultad y los momentos confusos.

Punto acordado del desarrollo en el que se debe entregar y revisar un resultado específico, como una demo jugable, alfa o beta.

Etapa en que están implementadas las funciones principales y se puede jugar de principio a fin, aunque quedan errores, elementos provisionales y falta pulido.

Etapa posterior a alfa en que el contenido está completo y el equipo se concentra en corregir errores y pulir; también puede ser la prueba pública o cerrada de esa versión.

Sección breve pero terminada de un juego, como un nivel, que presenta calidad final en arte, sonido y jugabilidad para mostrar cómo será el producto completo.

Facilidad, rapidez y eficacia con que las personas usan un producto para completar una tarea, y satisfacción que sienten durante el proceso.

Método de investigación en el que usuarios reales intentan completar tareas con un producto o prototipo mientras una persona investigadora observa dónde tienen dificultades.

Revisión en que especialistas comparan una interfaz con principios aceptados de usabilidad para hallar problemas sin probarla con usuarios.