1.6.-Herramientas y funcionalidades

1.6. Funcionalidades de las herramientas usadas durante el desarrollo de software

Idea principal

Una aplicación no se construye con una única herramienta. Editores, traductores, depuradores, sistemas de control de versiones, herramientas de prueba y de calidad resuelven necesidades distintas y complementarias. Evaluarlas por su función y su contexto permite formar un flujo de trabajo fiable.

En los apartados anteriores has estudiado el código fuente, los traductores y los lenguajes de programación. Ahora se completa esa visión: para convertir una necesidad en software que se pueda usar y mantener, un equipo combina herramientas especializadas durante todo el ciclo de desarrollo. Un entorno integrado de desarrollo (IDE) reúne muchas de ellas, pero su instalación y configuración se tratarán en la unidad siguiente; aquí se estudian sus funciones de forma independiente.

El objetivo de este tema no es memorizar marcas comerciales, sino identificar qué problema resuelve cada clase de herramienta, comparar sus funcionalidades y justificar una elección en una situación de desarrollo real.

Según la normativa del módulo Entornos de Desarrollo, este contenido contribuye al siguiente resultado de aprendizaje y criterios de evaluación:

Código	Descripción
RA 1	Reconoce los elementos y herramientas que intervienen en el desarrollo de un programa informático, analizando sus características y las fases en las que actúan hasta llegar a su puesta en funcionamiento.
CE 1.b	Se han identificado las fases de desarrollo de una aplicación informática.
CE 1.f	Se ha evaluado la funcionalidad ofrecida por las herramientas utilizadas en el desarrollo de software.

Qué deberías saber al terminar

Al acabar este apartado deberías poder:

• relacionar las herramientas con las fases de desarrollo y prueba de una aplicación;
• diferenciar la finalidad de un editor, compilador, intérprete, enlazador, depurador, sistema de control de versiones y framework;
• seleccionar herramientas de documentación, pruebas, análisis de calidad y automatización para un caso sencillo;
• explicar por qué herramientas como Git, Maven, SonarQube y un depurador se complementan, pero no se sustituyen entre sí;
• justificar una elección considerando el lenguaje, el proyecto, el equipo y el entorno de ejecución.

Mapa del tema

En este documento seguiremos esta secuencia:

1. dónde encajan las herramientas en la ingeniería del software;
2. cómo se pasa del código fuente a un programa probado;
3. qué funciones cubren las herramientas habituales;
4. cómo combinarlas en un flujo de trabajo;
5. qué criterios ayudan a elegirlas con sentido profesional.

1. Herramientas e ingeniería del software

El software es la parte lógica de un sistema informático: programas, datos y configuraciones que indican al hardware qué debe hacer. Cuando se ejecuta, sus instrucciones y datos se cargan en memoria; el procesador las procesa y los periféricos permiten la entrada, salida o comunicación con otros sistemas.

Ingeniería del software

La ingeniería del software aplica de forma organizada conocimientos, métodos, procesos y herramientas para obtener software útil, fiable, mantenible y rentable que cumpla unas especificaciones acordadas.

Desarrollar no equivale solo a escribir código. Un producto suele pasar por análisis, diseño, codificación, pruebas, documentación, despliegue, explotación y mantenimiento. El modelo clásico en cascada ordena estas fases de forma secuencial; los enfoques ágiles, como Scrum, trabajan de manera iterativa e incremental, repitiendo ciclos cortos para entregar pronto funcionalidad que aporte valor. En ambos casos se necesitan herramientas, aunque se usen con distinta frecuencia y organización.

El desarrollo de software incluye actividades que se retroalimentan: las incidencias detectadas en pruebas o producción pueden requerir volver a modificar, compilar y probar el código.

Una incidencia recorre varias herramientas

Un equipo detecta que el cálculo del total de un pedido es incorrecto. Una persona revisa y modifica el código con un editor; ejecuta las pruebas para reproducir y verificar la corrección; usa un depurador para inspeccionar valores si el fallo no es evidente; analiza la calidad para detectar problemas relacionados y registra el cambio en Git. No existe una herramienta «mejor» para todas esas acciones: cada una aporta una función concreta.

2. Del código fuente al programa verificado

Durante la codificación se crea código fuente con un editor. El código se guarda en archivos con extensiones propias del lenguaje, por ejemplo, .c, .java, .py o .kt. Después, un traductor lo procesa para que pueda ejecutarse en una plataforma determinada: puede ser un ensamblador, un compilador o un intérprete.

En un proceso tradicional de compilación, el compilador genera código objeto y el enlazador (linker) combina ese código con otros objetos y bibliotecas para producir un ejecutable o una biblioteca. El enlazado puede ser:

• Estático: incorpora en el resultado las bibliotecas necesarias. El archivo suele ser más grande, pero depende de menos ficheros externos en tiempo de ejecución.
• Dinámico: el ejecutable referencia bibliotecas separadas que se cargan al ejecutarlo. Reduce duplicación de código, pero exige disponer de versiones compatibles de esas bibliotecas.

En plataformas con máquina virtual, como Java y Kotlin en la JVM, el compilador genera normalmente bytecode. La máquina virtual lo interpreta y/o lo compila justo a tiempo (JIT) para ejecutarlo. Por ello, el resultado no es un ejecutable nativo convencional, sino un artefacto que necesita un entorno de ejecución compatible.

flowchart LR
    A["Código fuente<br/>Editor"] --> B{"¿Cómo se ejecuta?"}
    B -->|"Compilación nativa"| C["Compilador<br/>Código objeto"]
    C --> D["Enlazador<br/>Ejecutable o biblioteca"]
    B -->|"Máquina virtual"| E["Compilador<br/>Bytecode"]
    E --> F["Máquina virtual<br/>Interpretación o JIT"]
    B -->|"Intérprete"| G["Intérprete o runtime"]
    D --> H["Pruebas, depuración<br/>y monitorización"]
    F --> H
    G --> H
    H -->|"Incidencia"| A

Interpretar no siempre significa ejecutar literalmente línea a línea

La explicación «un intérprete ejecuta línea a línea» es útil como primera aproximación, pero simplifica el proceso. Por ejemplo, CPython suele convertir primero el fuente a bytecode y después su máquina virtual lo procesa. Lo importante en este tema es identificar el entorno que transforma o ejecuta el programa y las herramientas que lo acompañan.

Las herramientas cubren desde la edición y construcción del programa hasta la colaboración, las pruebas y el mantenimiento.

3. Herramientas habituales y su función

La siguiente tabla ofrece una visión de conjunto. Una misma aplicación puede usar varias herramientas de cada tipo; conocer la función es más importante que memorizar un producto concreto.

Tipo de herramienta	Para qué sirve	Ejemplos	Situación de uso
Editor de texto o código	Crear y modificar archivos de código y configuración.	Sublime Text, Notepad++, Visual Studio Code.	Corregir un script o editar un archivo config.yml.
Compilador e intérprete	Traducir o ejecutar código según el lenguaje y su implementación.	GCC, Clang, python, Node.js.	Generar un binario C o ejecutar un programa Python.
Documentación	Generar referencias técnicas a partir de comentarios y anotaciones.	Javadoc, Doxygen, JSDoc.	Publicar la API de una biblioteca.
Depurador	Pausar un programa y observar su estado mientras se ejecuta.	GDB, PDB, LLDB.	Investigar una excepción o un valor inesperado.
Control de versiones	Registrar cambios y facilitar el trabajo simultáneo.	Git, Mercurial.	Desarrollar una funcionalidad en una rama y revisarla antes de integrarla.
Framework	Aportar estructura y componentes reutilizables a una aplicación.	Django, Spring.	Crear una aplicación web con rutas, autenticación y acceso a datos.
Pruebas y calidad	Verificar comportamiento, rendimiento, estilo y riesgos del código.	JUnit, JMeter, SonarQube, ESLint.	Ejecutar pruebas unitarias, de carga o análisis estático.
Automatización	Repetir de forma fiable la construcción, las dependencias o transformaciones.	Make, Maven, Ant, Gradle.	Compilar, probar y empaquetar un proyecto con un comando.

3.1. Edición, compilación e interpretación

Un editor de texto permite escribir y modificar código fuente. Los editores orientados a programación suelen ofrecer resaltado de sintaxis, indentación automática, búsqueda, comparación de archivos y extensiones. Son ligeros y útiles para cambios rápidos, para scripts o para trabajar en equipos donde no resulta práctico instalar un IDE completo.

# config.yml: un editor permite modificar con rapidez este archivo de configuración
servidor:
    puerto: 8080
    modoDepuracion: false

Un compilador traduce código fuente a código objeto o código máquina. GCC (GNU Compiler Collection) y Clang son opciones frecuentes para C y C++. El resultado de una compilación nativa suele estar pensado para un sistema operativo y una arquitectura concretos; esto ayuda a obtener rendimiento, pero obliga a generar o distribuir versiones adecuadas para cada plataforma.

gcc -Wall -g suma.c -o suma
./suma

En este ejemplo, gcc compila suma.c; -Wall activa advertencias habituales y -g incluye información para depurar. El enlazado se realiza en el mismo comando porque solo hay un archivo fuente. En proyectos con varios archivos se pueden compilar por separado a objetos y enlazarlos después.

Un intérprete o runtime procesa el programa durante su ejecución. Python es adecuado para scripts de automatización y prototipos porque permite editar y ejecutar con un ciclo corto. Node.js permite ejecutar JavaScript fuera del navegador, por ejemplo, en servicios de servidor. Esta agilidad no elimina la necesidad de probar, versionar y documentar el código.

python3 informe_ventas.py
node servidor.js

3.2. Documentación y depuración

La documentación técnica permite que otras personas entiendan cómo utilizar y mantener un componente. Herramientas como Doxygen, Javadoc y JSDoc generan documentación navegable a partir de comentarios estructurados en el código. Esto reduce trabajo manual y mantiene la referencia próxima a la implementación, aunque no sustituye la revisión: un comentario incorrecto también puede generar documentación incorrecta.

/**
 * Calcula el importe final con el IVA indicado.
 *
 * @param base importe sin impuestos; debe ser mayor o igual que cero
 * @param iva porcentaje de IVA expresado como decimal, por ejemplo 0.21
 * @return importe final redondeado a dos decimales
 */
public double calcularTotal(double base, double iva) {
    return Math.round(base * (1 + iva) * 100.0) / 100.0;
}

Un depurador ejecuta el programa bajo control: permite establecer puntos de interrupción, avanzar paso a paso, inspeccionar variables, revisar la pila de llamadas y, en algunos casos, modificar valores temporalmente. GDB se usa habitualmente con C y C++; PDB es el depurador incluido en Python. Son especialmente útiles para errores lógicos, excepciones y fallos que dependen de los datos de ejecución.

pedido = {"unidades": 3, "precio": 12.5}
breakpoint()  # Pausa aquí para inspeccionar pedido antes de calcular el total
total = pedido["unidades"] * pedido["precio"]
print(total)

Un depurador investiga; no corrige por sí solo

Pausar el programa ayuda a localizar el origen de un problema, pero la corrección debe entender la causa y validarse con pruebas. Cambiar una variable durante la sesión puede servir para formular una hipótesis, no para arreglar el código fuente de forma permanente.

3.3. Colaboración y reutilización

Los sistemas de control de versiones registran la evolución de los archivos. Git permite crear ramas, realizar commits, comparar cambios, revertir una versión y colaborar mediante repositorios remotos como GitHub o GitLab. Así, varias personas pueden trabajar en paralelo sin enviarse copias de archivos por correo o sincronizarlas con una carpeta compartida.

git switch -c feature/calculo-total
git add src/calculos.py tests/test_calculos.py
git commit -m "Añade cálculo del total del pedido"
git push -u origin feature/calculo-total

Un framework ofrece una estructura de trabajo y componentes reutilizables. Django proporciona, entre otras capacidades, rutas, modelos, autenticación y un panel de administración; Spring se utiliza ampliamente en aplicaciones empresariales Java. Su ventaja no consiste solo en «tener mucho código», sino en definir convenciones y controlar parte del flujo de la aplicación.

Framework y biblioteca no son sinónimos

Con una biblioteca, el programa llama a sus funciones cuando las necesita; por ejemplo, requests.get(url). Con un framework, el framework define el ciclo principal y llama al código que se ha incorporado a su estructura, por ejemplo, a una vista de Django cuando llega una petición HTTP. Esta inversión de control es una diferencia esencial.

3.4. Pruebas, análisis de calidad y automatización

Las herramientas de pruebas y calidad no persiguen exactamente el mismo objetivo. Combinarlas proporciona información más completa sobre el producto.

Herramienta o categoría	Qué comprueba	Ejemplo de uso	Limitación que conviene conocer
Framework de pruebas unitarias, como JUnit	Que una clase o función cumple casos concretos.	Verificar el cálculo del IVA.	No garantiza por sí solo que toda la aplicación funcione integrada.
Herramienta de carga, como JMeter	Respuesta del sistema ante usuarios o peticiones concurrentes.	Simular solicitudes HTTP a una API.	Requiere un escenario y una carga representativos.
Analizador estático, como SonarQube o ESLint	Patrones problemáticos, duplicación, estilo, vulnerabilidades potenciales o complejidad.	Revisar un repositorio en cada integración.	No ejecuta todos los caminos del programa ni demuestra que no existan errores.
Monitorización y seguimiento	Métricas y comportamiento de la aplicación desplegada.	Observar latencia, consumo o tasa de errores.	Detecta síntomas; es necesario investigar la causa.

Herramientas como Make automatizan comandos de compilación en muchos proyectos de C y C++. Maven y Ant ayudan a automatizar la construcción de proyectos Java; Maven también gestiona dependencias declaradas en pom.xml. Estas herramientas hacen reproducible el proceso: cualquier integrante del equipo puede ejecutar las mismas tareas sin reconstruir manualmente la secuencia de comandos.

Las herramientas de refactorización modifican la estructura interna del código sin cambiar su comportamiento esperado. Por ejemplo, un editor avanzado o un IDE puede renombrar una clase y actualizar sus referencias. Esta capacidad es más segura que un reemplazo global de texto, pero debe ir acompañada de revisión y pruebas.

4. Aplicar las herramientas en un flujo de trabajo

Imagina una pequeña API para gestionar préstamos de una biblioteca. Un flujo de trabajo razonable podría ser el siguiente:

1. Planificar y editar: el equipo concreta una tarea, crea una rama en Git y modifica el código y la configuración con el editor o el IDE.
2. Construir el proyecto: Maven, Make u otra herramienta descarga las dependencias necesarias, compila o prepara el artefacto ejecutable de manera repetible.
3. Probar y depurar: se ejecutan las pruebas automatizadas. Si una falla, se reproduce el problema y se usa el depurador para inspeccionar el estado en lugar de adivinarlo.
4. Analizar y documentar: un linter o SonarQube detecta problemas potenciales; Javadoc, JSDoc o una herramienta equivalente genera la documentación de la API cuando corresponde.
5. Revisar e integrar: otra persona revisa los cambios mediante una solicitud de incorporación; después se integran en la rama principal y se monitoriza el comportamiento al desplegar.

Elegir para una tarea concreta

Para cambiar un valor de config.yml en un servidor puede bastar un editor ligero. Para compilar una aplicación C formada por muchos archivos, conviene usar GCC o Clang junto con Make. Para una aplicación web Java con dependencias y pruebas, Maven puede construir el proyecto y JUnit verificar la lógica. Si aparece un fallo solo con determinados datos, un depurador aporta información que un analizador estático no puede observar en ejecución.

5. Criterios para evaluar una herramienta

No se elige una herramienta solo porque sea popular o porque se haya usado antes. Antes de adoptarla, conviene responder a estas preguntas:

1. ¿Qué necesidad cubre?: identifica si hace falta editar, traducir, depurar, probar, documentar, versionar o automatizar. Evita sustituir una función por otra: Git no es un analizador de calidad y SonarQube no es un depurador.
2. ¿Es compatible con el proyecto?: comprueba el lenguaje, el sistema operativo, las versiones, el tipo de despliegue y las dependencias que necesita.
3. ¿Qué aporta al equipo?: valora aprendizaje, documentación, integración con el flujo de trabajo, accesibilidad y posibilidad de colaboración.
4. ¿Cómo contribuye a la calidad?: revisa si permite automatizar pruebas, detectar problemas antes del despliegue, obtener trazabilidad o repetir una construcción.
5. ¿Qué coste y riesgos introduce?: considera licencia, mantenimiento, seguridad de extensiones y dependencias, consumo de recursos y riesgo de dependencia de un proveedor.

6. Buenas prácticas

• Usa una herramienta para la función que resuelve: combina control de versiones, pruebas, análisis y depuración; no esperes que una sola herramienta cubra todo el ciclo.
• Automatiza las tareas repetibles: guarda en el proyecto la configuración de construcción, dependencias, pruebas y análisis para poder repetir el resultado en otro equipo.
• Activa advertencias y conserva la información de depuración: por ejemplo, compila con advertencias y símbolos de depuración en desarrollo; atiende los avisos antes de que se conviertan en incidencias.
• Versiona código y configuración, no secretos: utiliza .gitignore y mecanismos seguros para credenciales, claves o ficheros locales de configuración.
• Verifica las herramientas con evidencias: antes de adoptarlas en un equipo, prueba un caso pequeño y revisa compatibilidad, documentación, mantenimiento y licencia.
• Mantén actualizadas las dependencias con criterio: revisa avisos de seguridad y cambios incompatibles; actualizar sin ejecutar pruebas también puede introducir errores.

7. Errores frecuentes

Error frecuente	Por qué ocurre	Cómo evitarlo
Confundir compilador, intérprete y máquina virtual.	Se simplifica demasiado el modo de ejecución de un lenguaje.	Indica qué artefacto se genera y qué entorno lo procesa: ejecutable nativo, bytecode, intérprete o JIT.
Usar una carpeta compartida o el correo como sistema de colaboración.	Parecen soluciones rápidas para compartir archivos.	Usa Git, ramas, commits pequeños y revisión antes de integrar cambios.
Creer que el análisis estático sustituye a las pruebas o al depurador.	Todas estas herramientas informan de problemas, pero observan aspectos diferentes.	Combina pruebas automatizadas, análisis estático, depuración y monitorización según el riesgo.
Aplicar un reemplazo global para refactorizar.	Cambiar texto parece más rápido que analizar referencias.	Utiliza refactorizaciones semánticas y ejecuta las pruebas después de cada cambio relevante.
Añadir dependencias o extensiones sin revisar su origen.	Se prioriza la rapidez sobre la seguridad y el mantenimiento.	Consulta documentación, licencia, actividad del proyecto y avisos de seguridad; limita los permisos de las extensiones.
Confundir una biblioteca con un framework.	Ambos aportan código reutilizable.	Observa quién controla el flujo: en una biblioteca llama la aplicación; en un framework, el framework llama al código de la aplicación.

8. Resumen

En este tema has aprendido que:

• la ingeniería del software organiza procesos, métodos y herramientas para obtener productos fiables y mantenibles;
• el código fuente se edita, se traduce o ejecuta y se prueba; las incidencias pueden hacer necesario repetir el ciclo;
• editores, compiladores, intérpretes, enlazadores, depuradores, sistemas de control de versiones y frameworks tienen funciones distintas;
• las pruebas, el análisis de calidad, la automatización y la monitorización son complementarios;
• una elección técnica debe justificarse por las necesidades del proyecto, el equipo, la compatibilidad, la calidad y los riesgos.

Idea clave

Evaluar una herramienta no consiste en saber su nombre: consiste en explicar qué tarea resuelve, qué límites tiene y cómo se integra con las demás para entregar software de calidad.

9. Para seguir practicando

• Para cada situación de la tabla del apartado 3, elige una herramienta y justifica por qué las demás categorías no resuelven exactamente la misma necesidad.
• Crea un programa breve que contenga un error lógico, ejecútalo con un depurador y anota el punto de interrupción, los valores observados y la corrección aplicada.
• Configura una tarea de construcción y prueba en un proyecto de clase; ejecuta la misma tarea desde una copia limpia del repositorio para comprobar que es reproducible.

Bibliografía y fuentes

• GNU Project, GCC online documentation.
• Git, Pro Git Book.
• Apache Maven, Maven in 5 Minutes.
• Python Software Foundation, documentación de breakpoint().
• SonarSource, documentación de SonarQube.
• Django Software Foundation, documentación de Django.

Presentación

ED-U1.6 - Funcionalidades de las herramientas de desarrollo