2.6.-Evaluación de IDEs

2.6. Evaluación de los entornos de desarrollo¶

Idea principal

Evaluar un entorno de desarrollo no consiste en decidir qué herramienta es «la mejor» en términos absolutos. Consiste en comprobar qué entorno responde mejor a los requisitos de un proyecto, utilizando criterios definidos, pruebas comparables y evidencias que permitan justificar la decisión.

Un entorno de desarrollo integrado (Integrated Development Environment, IDE) reúne herramientas para editar, ejecutar, depurar, probar y gestionar software. Su utilidad depende tanto de sus funciones como del lenguaje, el tamaño del proyecto, el equipo y las herramientas externas que deba integrar.

Este tema cierra el recorrido de la unidad: después de estudiar las funciones de los IDEs, sus módulos, su personalización, las actualizaciones y la generación de ejecutables, aprenderás a comparar varios entornos de forma razonada. La referencia literal del módulo Entornos de Desarrollo se encuentra en la normativa del módulo.

El objetivo no es memorizar una lista de ventajas, sino saber seleccionar una herramienta y explicar por qué encaja en una situación profesional concreta.

Código	Descripción
RA 2	Evalúa entornos integrados de desarrollo analizando sus características para editar código fuente y generar ejecutables.
CE 2.f	Se han generado ejecutables a partir de un mismo código fuente con varios entornos de desarrollo.
CE 2.g	Se han identificado las características comunes y específicas de diversos entornos de desarrollo.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

distinguir las funciones comunes de las características específicas de un IDE;
definir criterios y evidencias para comparar varios entornos en condiciones equivalentes;
ejecutar un mismo programa en más de un entorno y documentar las diferencias observadas;
justificar la elección de PyCharm, IntelliJ IDEA o Visual Studio Code según el proyecto.

Mapa del tema

En este documento vamos a seguir esta secuencia:

entender qué significa evaluar un entorno;
identificar las funciones comunes de los IDEs;
estudiar los perfiles de PyCharm, IntelliJ IDEA y Visual Studio Code;
construir una comparación con criterios y evidencias;
aplicar el procedimiento a un programa Python y extraer una conclusión.

1. Qué significa evaluar un IDE¶

Evaluar significa recoger información y compararla con unos requisitos. Una opinión como «este IDE me gusta más» puede ser un dato sobre comodidad, pero no es suficiente para tomar una decisión técnica. Una evaluación debe responder, al menos, a estas preguntas:

¿Qué lenguaje o lenguajes se van a utilizar?
¿Qué sistema de construcción, intérprete, SDK o gestor de dependencias necesita el proyecto?
¿Qué tareas debe facilitar el entorno: depuración, pruebas, refactorización, control de versiones o despliegue?
¿Qué restricciones existen de tiempo de arranque, memoria, licencia, sistema operativo o configuración del equipo?
¿Cómo se comprobará que la herramienta cumple lo que se necesita?

Evaluación de un entorno de desarrollo

Es el análisis sistemático de las funciones, la integración, el rendimiento, la facilidad de uso y las restricciones de varios entornos para elegir el que mejor satisface los requisitos de un proyecto.

1.1. IDE, editor y cadena de herramientas¶

No conviene confundir el IDE con todas las herramientas que utiliza. Un entorno puede invocar aplicaciones instaladas aparte:

Elemento	Función	Ejemplo en un proyecto
Editor o IDE	Escribir y organizar el código	PyCharm o Visual Studio Code
Intérprete o compilador	Ejecutar o traducir el código	Python, JDK o Kotlin/JVM
Herramienta de construcción	Resolver dependencias y crear artefactos	Gradle, Maven o una tarea de `npm`
Depurador	Detener la ejecución e inspeccionar el estado	Depurador de Python o de la JVM
Control de versiones	Registrar cambios y colaborar	Git y un repositorio remoto

Por ejemplo, IntelliJ IDEA puede iniciar una compilación de Gradle, pero no significa que el IDE sea Gradle. Del mismo modo, Visual Studio Code puede lanzar python main.py, pero necesita que exista un intérprete de Python seleccionado.

Relación entre un IDE y su cadena de herramientas — El IDE coordina herramientas del proyecto, pero cada una mantiene su responsabilidad.

Una precisión importante

Una función puede estar integrada de forma nativa, llegar mediante un plugin o ejecutarse como una herramienta externa desde el IDE. En la comparación hay que registrar cuál de estas situaciones se da, porque no ofrecen el mismo nivel de integración ni la misma facilidad de mantenimiento.

Una comparación que sí aporta información

Si PyCharm y Visual Studio Code ejecutan main.py con la misma versión de Python y el mismo entorno virtual, la salida común demuestra que ambos permiten realizar esa tarea. Para comparar algo más que la salida, hay que registrar también cómo se seleccionó el intérprete, cómo se depuró el programa, qué extensiones intervinieron y qué configuración habría que compartir con el equipo.

2. Características comunes de los IDEs¶

PyCharm e IntelliJ IDEA son IDEs completos orientados a ecosistemas concretos. Visual Studio Code es un editor extensible que puede adquirir capacidades de IDE al añadir extensiones y configurar el proyecto. Esta diferencia no impide compararlos, pero sí obliga a describir qué parte de cada solución viene incluida de serie y cuál requiere configuración adicional.

2.1. Editor de código avanzado¶

Los tres entornos pueden ofrecer, con distinto nivel de profundidad:

resaltado de sintaxis para distinguir palabras reservadas, tipos y comentarios;
autocompletado y navegación hacia declaraciones, usos y archivos relacionados;
diagnóstico de errores mientras se escribe;
formateo e indentación coherentes con el lenguaje;
búsqueda y sustitución en todo el proyecto;
refactorizaciones, como renombrar un símbolo sin modificar referencias válidas por accidente.

Ejemplo: al cambiar el nombre de una función en un proyecto Python, una refactorización consciente del lenguaje debe localizar sus usos. Sustituir texto sin analizar el código puede cambiar comentarios o variables que tienen el mismo nombre, pero un significado distinto.

2.2. Depurador integrado¶

El depurador permite observar la ejecución sin llenar el programa de mensajes temporales. Sus operaciones más habituales son:

establecer puntos de interrupción;
ejecutar hasta la siguiente línea, entrar en una función o salir de ella;
consultar variables locales, expresiones y la pila de llamadas;
inspeccionar excepciones y el estado del programa;
en algunos lenguajes, evaluar expresiones o modificar valores durante la sesión.

Ejemplo: si una función devuelve una lista vacía cuando debería contener datos, se puede detener la ejecución antes del return, inspeccionar la consulta o el filtro y comprobar dónde se pierde la información.

2.3. Control de versiones integrado¶

PyCharm, IntelliJ IDEA y Visual Studio Code pueden integrarse con Git. Esta integración suele permitir consultar diferencias, preparar cambios, crear commits, cambiar de rama, resolver conflictos y sincronizar con un repositorio remoto. La interfaz del IDE no sustituye a conocer Git: una mala combinación de ramas sigue siendo un problema aunque se realice con botones.

Ejemplo: antes de aceptar un commit, el panel de control de versiones permite revisar que no se incluyen credenciales, archivos generados o cambios no relacionados con la tarea.

2.4. Soporte para extensiones o plugins¶

Los plugins y las extensiones amplían las funciones del entorno. Pueden añadir soporte para un lenguaje, un framework, un linter, un formateador, una base de datos, un sistema de pruebas o una conexión con servicios externos.

No basta con contar cuántas extensiones ofrece un catálogo. También hay que comprobar quién las mantiene, qué permisos solicitan, con qué versión son compatibles y si el equipo puede reproducir la misma configuración.

Ejemplo: Visual Studio Code puede incorporar soporte para Python, depuración y pruebas mediante extensiones. Esa flexibilidad es útil, pero el proyecto debe documentar las extensiones necesarias y la versión del intérprete para que otra persona pueda preparar el mismo entorno.

2.5. Ejecución, construcción y pruebas¶

Un IDE suele proporcionar configuraciones de ejecución y depuración, terminal integrada y acceso a herramientas de pruebas. El nivel de integración cambia:

en Python se selecciona un intérprete o un entorno virtual y se ejecuta un módulo o un script;
en Java y Kotlin se configura un JDK y se delega normalmente en Gradle, Maven u otra herramienta;
en un proyecto web pueden intervenir npm, un servidor de desarrollo, un navegador y herramientas de análisis.

La misma ventana de «Ejecutar» no significa que todos los lenguajes se ejecuten de la misma forma. Hay que identificar qué herramienta real se ha invocado y qué artefacto se ha producido.

2.6. Configuración, refactorización y accesibilidad¶

El material de apoyo de la unidad también presenta el panel de configuración, la refactorización y, en algunos entornos, los diseñadores visuales de interfaces. Son capacidades útiles para evaluar un IDE, pero no deben darse por supuestas en todos los lenguajes o productos:

Capacidad	Qué se debe comprobar	Evidencia posible
Configuración del entorno	Temas, tamaño de letra, atajos, distribución de paneles y opciones de accesibilidad	Exportación de ajustes, archivo de configuración o captura de la opción utilizada
Refactorización	Si entiende el lenguaje y actualiza referencias sin modificar texto no relacionado	Diferencia (diff) antes y después, junto con las pruebas ejecutadas
Diseñador visual	Si existe para la tecnología del proyecto y qué código o recursos genera	Interfaz creada y archivos generados

La refactorización cambia la estructura interna sin cambiar el comportamiento observable que se pretende conservar. Renombrar una función desde una herramienta con conocimiento del lenguaje no equivale a usar una sustitución literal: la primera puede actualizar sus referencias válidas y la segunda puede modificar comentarios o símbolos distintos. Por eso conviene incluir una prueba antes y después de refactorizar.

La configuración también es un criterio de equipo. Un tema o un atajo puede ser una preferencia personal, pero el formateador, el linter, el intérprete y las tareas del proyecto deberían quedar documentados y ser reproducibles.

3. Características específicas de PyCharm, IntelliJ IDEA y Visual Studio Code¶

Las funciones comunes permiten comparar los entornos, pero las diferencias de especialización son las que suelen inclinar la decisión.

3.1. PyCharm (Python)¶

PyCharm está orientado al desarrollo con Python. Sus puntos fuertes habituales son:

selección y gestión del intérprete, los entornos virtuales y los paquetes del proyecto;
análisis del código Python, navegación y refactorización sensible al lenguaje;
ejecución y depuración de scripts, aplicaciones y pruebas;
integración con herramientas como pytest y unittest;
asistencia para proyectos web con Django o Flask, según la edición y la configuración instalada;
terminal, control de versiones y herramientas para trabajar con bases de datos cuando el entorno o sus plugins las proporcionan.

Ejemplo: en una aplicación Django, PyCharm puede reconocer la estructura del proyecto, ayudar a configurar el intérprete y lanzar el servidor de desarrollo. La evaluación debe comprobar qué funciones están disponibles en la edición y versión concreta, porque no todas las capacidades tienen necesariamente el mismo alcance en todas las distribuciones.

Su posible inconveniente es que puede resultar más pesado que un editor mínimo y que ofrece más funciones de las necesarias para un script pequeño. Eso no lo convierte en peor: solo indica que hay que relacionar el coste de configuración con la complejidad del proyecto.

3.2. IntelliJ IDEA (Kotlin y Java)¶

IntelliJ IDEA está especialmente orientado al ecosistema JVM. Destaca por:

soporte profundo para Java y Kotlin;
análisis, navegación y refactorización de proyectos grandes;
integración con Gradle y Maven para dependencias, compilación y empaquetado;
configuraciones de ejecución, depuración y pruebas;
modelo de proyecto basado en módulos y diferentes SDK;
integración con Git y un amplio sistema de plugins.

Ejemplo: en una aplicación Kotlin con Gradle, el IDE puede importar el proyecto, mostrar sus módulos, sincronizar dependencias y ejecutar las tareas definidas por el sistema de construcción. La generación del artefacto la realiza el flujo de Gradle; el IDE actúa como interfaz y coordinador.

Para un proyecto principalmente Python puede ser una opción menos directa que PyCharm, aunque puede ampliarse mediante plugins. La evaluación debe distinguir entre el soporte principal del producto y el soporte añadido.

3.3. Visual Studio Code (Python y múltiples lenguajes)¶

Visual Studio Code parte de un núcleo ligero y un modelo de extensiones. Con la configuración adecuada puede ofrecer:

soporte para muchos lenguajes y tecnologías;
terminal integrada y tareas definidas en el espacio de trabajo;
depuración, pruebas y selección del intérprete mediante extensiones;
integración con Git;
personalización de atajos, temas, formato y análisis estático.

Ejemplo: para ejecutar Python, el equipo puede instalar la extensión de Python, seleccionar el intérprete del entorno virtual y utilizar la terminal, el comando de ejecución o una configuración de depuración. Si falta uno de esos pasos, el editor puede abrir el archivo correctamente y, aun así, no ejecutar el programa como se esperaba.

Su ventaja habitual es la flexibilidad y el bajo coste inicial de un proyecto pequeño. Su reto es mantener una configuración coherente: demasiadas extensiones, versiones incompatibles o tareas definidas solo en un equipo pueden dificultar la reproducción del entorno.

3.4. Otros entornos y una confusión frecuente¶

El material de apoyo también analiza NetBeans, Eclipse y Visual Studio. No es necesario instalar todos para comprender el método de evaluación, pero son alternativas útiles para ampliar la comparación:

Entorno	Perfil habitual	Qué conviene comprobar
NetBeans	IDE generalista con especial presencia en Java	Proyectos, plugins, depuración, refactorización y sistema de construcción
Eclipse	Plataforma extensible muy utilizada en proyectos Java	Plugins necesarios, configuración del espacio de trabajo y soporte del proyecto
Visual Studio	IDE orientado principalmente al ecosistema .NET y Windows	Cargas de trabajo instaladas, compiladores, depuración y herramientas del proyecto

Visual Studio y Visual Studio Code no son el mismo producto. El primero es un IDE completo con herramientas integradas para determinados ecosistemas; el segundo es un editor extensible que se adapta mediante extensiones. Confundirlos puede invalidar una comparación de consumo, instalación o funcionalidades.

Las pantallas de instalación del documento de apoyo son valiosas para reconocer los componentes de un IDE, pero corresponden a versiones antiguas. Por eso se conservan como referencia conceptual y no se presentan como instrucciones actuales: las opciones, ediciones y nombres de los menús cambian con el tiempo.

4. Comparación de rendimiento y características¶

Una tabla de características sirve para orientarse, pero no basta para evaluar. La palabra «rápido» debe concretarse: ¿se mide el arranque en frío, la indexación, el consumo de memoria, la ejecución de pruebas o el tiempo hasta que el proyecto está listo para editar?

Dimensión	PyCharm	IntelliJ IDEA	Visual Studio Code
Enfoque principal	Python y su ecosistema	Java, Kotlin y JVM	Múltiples lenguajes mediante extensiones
Análisis del lenguaje	Profundo para Python	Profundo para Java y Kotlin	Depende de las extensiones instaladas
Ejecución y depuración	Integradas para proyectos Python	Integradas para JVM y plugins compatibles	Configurables mediante extensiones y tareas
Construcción	Herramientas Python y configuración del proyecto	Gradle, Maven y otras herramientas JVM	Tareas y herramientas externas del proyecto
Extensibilidad	Plugins del ecosistema JetBrains	Plugins del ecosistema JetBrains	Catálogo amplio de extensiones
Coste de configuración	Menor cuando el proyecto es Python	Menor cuando el proyecto es JVM	Puede aumentar al ensamblar muchas extensiones
Adecuación típica	Aplicaciones y proyectos Python	Aplicaciones Java o Kotlin	Proyectos web, scripts y equipos con tecnologías variadas

La tabla no declara un ganador universal. Resume hipótesis que deben comprobarse con el proyecto real y con la versión concreta de cada herramienta.

4.1. Criterios de evaluación¶

Antes de probar los IDEs, conviene convertir las necesidades del proyecto en criterios observables:

Criterio	Evidencia que se puede recoger	Pregunta orientativa
Adecuación al lenguaje	Autocompletado, diagnóstico y refactorización sobre el código real	¿Entiende el lenguaje sin trabajo adicional excesivo?
Ejecución y construcción	Comandos, configuraciones y artefactos generados	¿Lanza la cadena de herramientas correcta y deja el resultado reproducible?
Depuración y pruebas	Puntos de interrupción, pruebas ejecutadas y resultados	¿Permite localizar fallos con rapidez?
Colaboración	Diferencias, ramas, conflictos y configuración compartida	¿Ayuda a revisar cambios sin ocultar lo que hace Git?
Productividad	Número de pasos y tareas repetitivas automatizadas	¿Reduce trabajo sin crear una configuración opaca?
Rendimiento	Tiempo de arranque, indexación y memoria en las mismas condiciones	¿Es adecuado para el hardware y el tamaño del proyecto?
Extensibilidad y mantenimiento	Plugins necesarios, versiones, permisos y documentación	¿Se puede mantener la solución dentro de seis meses?
Usabilidad y accesibilidad	Legibilidad, atajos, escalado y ayudas de la interfaz	¿Puede utilizarlo con comodidad todo el equipo?

4.2. Matriz ponderada¶

Cuando varios criterios son importantes, se puede utilizar una matriz ponderada. La siguiente distribución es un ejemplo para un proyecto Python; cada equipo debe ajustarla a sus requisitos.

Criterio	Peso de ejemplo
Soporte del lenguaje y del framework	25 %
Ejecución, depuración y pruebas	20 %
Integración con Git y trabajo en equipo	15 %
Productividad y automatización	15 %
Rendimiento y consumo de recursos	10 %
Extensiones y mantenimiento	10 %
Usabilidad y accesibilidad	5 %

Se asigna a cada entorno una puntuación de 1 a 5 y se calcula:

puntuación final = suma de (puntuación × peso expresado como decimal)

Si el peso se escribe como porcentaje, hay que dividirlo entre 100 antes de calcular. Por ejemplo, con los pesos de la tabla, unas puntuaciones hipotéticas podrían producir estos resultados:

Entorno	Puntuaciones de ejemplo	Cálculo	Resultado
PyCharm	5, 5, 4, 4, 3, 4, 4	`5×0,25 + 5×0,20 + 4×0,15 + 4×0,15 + 3×0,10 + 4×0,10 + 4×0,05`	4,35/5
Visual Studio Code	4, 4, 4, 5, 5, 3, 4	`4×0,25 + 4×0,20 + 4×0,15 + 5×0,15 + 5×0,10 + 3×0,10 + 4×0,05`	4,15/5
Nota	Datos ficticios	Solo muestran el procedimiento	No son una recomendación universal

El resultado numérico sirve para hacer explícita la decisión, no para ocultar los matices. Una diferencia pequeña puede no ser relevante y un requisito obligatorio puede funcionar como condición eliminatoria aunque la media sea alta.

Una escala sencilla puede ser la siguiente:

1: no cubre el requisito o exige una solución poco viable;
3: lo cubre con configuración adicional y resulta utilizable;
5: lo cubre de forma integrada, documentada y reproducible.

La puntuación no reemplaza al análisis. Si un criterio es obligatorio, una media alta no debería ocultar que el entorno falla en ese requisito. En ese caso se puede establecer un umbral mínimo o marcar el criterio como eliminatorio.

4.3. Procedimiento de comparación¶

Una comparación útil debe poder repetirse. El siguiente flujo evita que la decisión dependa solo de la primera impresión:

flowchart TD
  A["Requisitos del proyecto"] --> B["Criterios y pesos"]
  B --> C["Misma tarea y mismas condiciones"]
  C --> D["Evidencias: tiempos, capturas y resultados"]
  D --> E["Puntuación y análisis cualitativo"]
  E --> F{"¿Cumple los requisitos obligatorios?"}
  F -->|Sí| G["Elección justificada"]
  F -->|No| H["Revisar criterios o probar otro entorno"]

Para que la prueba sea válida:

usa el mismo código fuente y, cuando sea posible, el mismo proyecto;
utiliza la misma versión del lenguaje, dependencias y sistema operativo;
registra la versión del IDE, las extensiones o plugins y la configuración relevante;
repite las medidas de rendimiento en condiciones comparables;
conserva evidencias: configuración, salida, errores, tiempos y observaciones;
separa los hechos medidos de las preferencias personales.

Qué evidencia responde a cada criterio

Una captura de la salida solo demuestra que una ejecución terminó con ese resultado. No demuestra, por sí sola, que el entorno depure mejor, consuma menos memoria o genere un artefacto distribuible. Cada afirmación de la comparación debe acompañarse de la evidencia que realmente puede demostrarla.

5. Aplicación y conclusión: el mismo programa Python en dos entornos¶

El programa de la práctica de la unidad cuenta de 10 a 0 y muestra «¡Despegue!». Es un buen caso de comparación porque no necesita dependencias externas y permite centrarse en el entorno.

5.1. Código fuente común¶

Guarda el mismo archivo main.py en los dos proyectos:

def cuenta_atras():
    for numero in range(10, -1, -1):
        print(numero)
    print("¡Despegue!")


if __name__ == "__main__":
    cuenta_atras()

La salida esperada es:

10
9
8
7
6
5
4
3
2
1
0
¡Despegue!

Ejecutar no siempre significa generar un ejecutable

En este ejemplo Python se ejecuta normalmente mediante un intérprete. El hecho de pulsar «Run» en PyCharm o Visual Studio Code no crea por sí mismo un archivo ejecutable independiente. El IDE lanza el intérprete seleccionado. En cambio, un proyecto Java o Kotlin puede producir clases, un JAR u otro artefacto mediante su compilador y su sistema de construcción. No se deben comparar ambos procesos como si fueran idénticos.

5.2. Preparación y ejecución en PyCharm¶

Abre el proyecto que contiene main.py y selecciona un intérprete de Python válido.
Comprueba que el intérprete pertenece al entorno virtual previsto para el proyecto.
Ejecuta el archivo y, después, repite la ejecución en modo depuración con un punto de interrupción dentro del bucle.
Registra la configuración usada, el resultado y cualquier diferencia respecto a la ejecución desde la terminal.

Una comprobación independiente permite saber si el problema está en el IDE o en la instalación de Python. Usa el comando que corresponda al sistema operativo y mantén el mismo intérprete en ambos entornos:

# Linux o macOS
python3 --version
python3 main.py

# Windows (PowerShell o Símbolo del sistema)
py -3 --version
py -3 main.py

5.3. Preparación y ejecución en Visual Studio Code¶

Abre la carpeta del proyecto, no solo el archivo aislado.
Instala y habilita la extensión de Python que utilice el equipo.
Selecciona el mismo intérprete que se usó en PyCharm. La extensión de Python no instala el intérprete: conecta el editor con una instalación que debe existir en el equipo.
Ejecuta main.py desde el comando de ejecución o desde la terminal integrada.
Repite la prueba con el depurador y registra los mismos datos que en PyCharm.

5.4. Qué comparar¶

Aspecto	Evidencia que debe anotarse
Preparación	Pasos para abrir el proyecto y seleccionar el intérprete
Ejecución	Comando o configuración utilizada y salida obtenida
Depuración	Facilidad para crear el punto de interrupción e inspeccionar `numero`
Pruebas	Posibilidad de integrar `pytest` u otra herramienta si el proyecto la necesita
Git	Cómo se revisan los cambios y se prepara un commit
Rendimiento	Tiempo de apertura e indexación en el mismo equipo, sin presentarlo como una verdad universal
Reproducibilidad	Versión y ruta del intérprete, extensiones, tareas y configuración compartida
Mantenimiento	Extensiones necesarias, versiones y documentación que habría que compartir

Si ambos entornos producen la salida correcta, esa evidencia demuestra que los dos sirven para el programa, pero no que sean equivalentes. La decisión puede depender de la depuración, la gestión del proyecto, la reproducibilidad o el trabajo en equipo.

5.5. Del resultado observado al artefacto verificable¶

El caso Python permite comparar la configuración y la ejecución del mismo código, pero no demuestra por sí solo la generación de un ejecutable independiente. Para trabajar con más precisión el CE 2.f, se puede repetir la comparación con un programa Java sencillo y el mismo JDK en IntelliJ IDEA y Visual Studio Code.

public class Main {
    public static void main(String[] args) {
        for (int numero = 10; numero >= 0; numero--) {
            System.out.println(numero);
        }
        System.out.println("¡Despegue!");
    }
}

Guarda el archivo como Main.java y comprueba que ambos entornos utilizan el mismo JDK. En un JDK moderno, la cadena mínima de construcción y ejecución sería:

java --version
javac Main.java
java Main
jar --create --file cuenta-atras.jar --main-class Main Main.class
java -jar cuenta-atras.jar
sha256sum cuenta-atras.jar

En IntelliJ IDEA y Visual Studio Code se puede lanzar esta cadena desde la configuración de ejecución o desde la terminal integrada. Lo importante para la comparación no es pulsar el mismo botón, sino documentar el JDK, el comando o sistema de construcción, el artefacto generado y su salida. En Windows, puedes obtener la misma evidencia con Get-FileHash cuenta-atras.jar.

flowchart TD
  A["Mismo código fuente"] --> B{"¿Qué se quiere comparar?"}
  B -->|"Ejecución de Python"| C["Intérprete seleccionado<br/>salida del programa"]
  B -->|"Artefacto Java o JVM"| D["JDK y construcción<br/>clases o archivo JAR"]
  C --> E["Comparar configuración,<br/>salida y depuración"]
  D --> F["Comparar artefacto,<br/>hash y ejecución"]

Para demostrar que el resultado es reproducible, conserva como mínimo:

versión y ruta del JDK;
versión del IDE y extensiones o plugins utilizados;
comando o tarea exacta de construcción;
nombre, tamaño y, si procede, huella SHA-256 del artefacto;
salida obtenida y diferencias respecto a la ejecución desde terminal.

Si los dos IDEs invocan el mismo JDK y la misma tarea de construcción, cabe esperar el mismo resultado funcional. El hash solo será idéntico si la construcción es reproducible; algunos formatos incluyen fechas u otros metadatos que pueden cambiar entre ejecuciones. En ese caso compara también el contenido, el manifiesto y la salida. La diferencia evaluable está en la configuración, la asistencia del IDE, la depuración o la facilidad para repetir el proceso, no en atribuir al IDE una compilación que realmente ha realizado el JDK.

5.6. Decisiones según el escenario¶

Situación	Opción que puede encajar mejor	Motivo que debe verificarse
Proyecto Python con muchas pruebas, refactorizaciones y framework web	PyCharm	Profundidad de su soporte Python y del framework elegido
Scripts, web y varios lenguajes con una configuración flexible	Visual Studio Code	Extensiones, terminal y tareas necesarias para el equipo
Aplicación Java o Kotlin con Gradle, Maven y módulos JVM	IntelliJ IDEA	Integración con el lenguaje y el sistema de construcción
Equipo con ordenadores modestos y proyectos pequeños	El entorno que cumpla los mínimos con menor coste	Medidas reales de memoria, arranque y configuración

La tabla propone hipótesis, no respuestas automáticas. La recomendación final debe apoyarse en los criterios y en las evidencias del proyecto concreto.

6. Buenas prácticas¶

Para trabajar este contenido con criterio, conviene aplicar estas buenas prácticas:

Definir requisitos antes de probar herramientas: así no se confunde la familiaridad con la adecuación técnica.
Comparar en condiciones equivalentes: mismo código, intérprete o JDK, dependencias, hardware y operaciones.
Distinguir funciones nativas de extensiones: esta diferencia afecta a la configuración, la seguridad y el mantenimiento.
Documentar la configuración: registra versiones, plugins, intérpretes, tareas y comandos para que otra persona pueda reproducirla.
Probar el proyecto real: un IDE puede comportarse bien con un ejemplo pequeño y no responder igual ante un repositorio grande.
Medir antes de afirmar que algo es rápido: separa arranque, indexación, ejecución de pruebas y consumo de recursos.
Revisar permisos y procedencia de extensiones: instala solo las necesarias y mantenlas actualizadas.

7. Errores frecuentes¶

Error frecuente	Por qué ocurre	Cómo evitarlo
Afirmar que existe un IDE mejor para todo	Se confunde potencia con adecuación	Define primero lenguaje, proyecto y restricciones
Comparar un IDE completo con un editor sin configurar	No se comparan las mismas capacidades	Documenta extensiones, plugins e intérpretes
Llamar «ejecutable» a cualquier ejecución de Python	Se mezclan intérprete y artefacto distribuible	Identifica el intérprete y diferencia ejecución de empaquetado
Elegir por la apariencia o por una sola prueba	Una impresión no representa el flujo completo	Usa varios criterios y evidencias repetibles
Medir el arranque en equipos distintos	El hardware y la indexación alteran el resultado	Utiliza el mismo equipo y describe las condiciones
Instalar extensiones sin revisar su mantenimiento	Se prioriza la cantidad sobre la estabilidad	Comprueba compatibilidad, permisos y necesidad real
Dejar la configuración solo en el equipo de una persona	El resto del equipo no puede reproducirla	Comparte instrucciones y archivos de configuración adecuados

8. Resumen¶

En este tema has aprendido que:

evaluar un IDE significa relacionar sus funciones con los requisitos de un proyecto;
editor, intérprete, compilador, depurador, sistema de construcción y Git son piezas relacionadas, pero no equivalentes;
PyCharm destaca por su especialización en Python, IntelliJ IDEA por el ecosistema Java/Kotlin y Visual Studio Code por su flexibilidad basada en extensiones;
una comparación rigurosa necesita criterios, pesos, condiciones equivalentes y evidencias;
ejecutar un programa desde un IDE no siempre implica generar un ejecutable independiente.

Idea clave

La elección profesional no se justifica con «este IDE es el mejor», sino con una relación trazable entre requisitos, pruebas, evidencias y decisión. Esa forma de comparar permite cambiar de herramienta cuando cambian el proyecto o sus necesidades.

9. Para seguir practicando¶

Realiza el punto 2.6 de la práctica de evaluación de IDEs con el mismo programa Python en PyCharm y Visual Studio Code.
Completa una matriz ponderada con al menos cinco criterios y justifica cada puntuación con una evidencia.
Revisa la diferencia entre generar artefactos en varios lenguajes y ejecutar el mismo código en varios entornos en 2.5. Ejecutables en IDEs.

Bibliografía y fuentes¶

Python: uso de la línea de comandos.
VS Code: configuración de Python, intérpretes, ejecución y depuración.
VS Code: tareas para integrar herramientas externas.
Java: documentación de javac y jar.
Visual Studio Code: documentación oficial.
PyCharm: configuración del intérprete de Python.
PyCharm: documentación oficial.
IntelliJ IDEA: documentación oficial.
García García, Javier. Entornos de desarrollo integrados. Apuntes de apoyo disponibles en assets/IDE_Javier_Garcia.pdf. Se utiliza como referencia conceptual e histórica; las rutas y pantallas de instalación pueden haber cambiado desde su elaboración.