Por lo tanto, trabajo en mi investigación sobre las dificultades de apoyar a Legacy, y noté un punto obvio que perdí completamente de vista.
Los usuarios de IDE y los desarrolladores de IDE tienen problemas para comprender sus herramientas. Utilizado intuitivamente y de todos modos. Sorprendentemente (agradable), tal uso casi no entra en conflicto con la ignorancia, aunque da lugar a los holivars correspondientes en los foros.
Ahora analizaremos cómo están las cosas en desarrollo con las herramientas, qué tiene de malo el concepto de "IDE" y qué herramientas deberían haber aparecido, pero aún no se han desarrollado.
E
No será un descubrimiento que el entorno es diferente para diferentes proyectos. Incluso si trabajan en una pila. Puede ser utilizado:
- Diferentes formas de interactuar con el usuario, lo que da una gran discrepancia sobre cómo comienza el proyecto y cómo se prueba. (CLI, TUI, bozal web, GUI en el sentido de Qt, GTK, etc.)
- Diferentes marcos de prueba (unittest en un proyecto, pytest en uno adyacente, en el contexto de Python). Los enlaces de las pruebas multinivel (por ejemplo, combinando las conclusiones de las pruebas independientes y la integración a través de TAP) también se encuentran aquí.
- VCS diferente, pero en algún lugar puede haber híbridos (Git, como cliente para Subversion en un caso especial).
- Dentro del mismo proyecto se puede utilizar, incluidos varios editores. Por ejemplo, Vim o nano para editar un script de rebase interactivo en Git, para editar fragmentos con registro parcial de cambios. O para editar configuraciones desde debajo de la raíz.
Y estas están lejos de todas las opciones, creo que cualquier desarrollador con experiencia en 2 o más proyectos puede lanzar ejemplos más similares. A menudo los escucho en la forma de la historia "Cómo pasé dos días para configurar un proyecto para un nuevo trabajo".
De esto podemos concluir que el diseño y la configuración del entorno de desarrollo en cualquier caso recae en el usuario.
Integrado?
Dado lo anterior, tiene sentido considerar entornos no "integrados", sino "integrables" .
Entonces, desde el punto de vista del usuario, una buena herramienta de integración es cuando:
- El entorno se configura rápidamente.
- Su configuración se puede almacenar y transferir.
- Capacidad para volver a aumentar el entorno de trabajo "un botón".
Por ejemplo, los Unixoids experimentados a menudo reducen la "transición al modo de trabajo" a un equipo.
Aquí "rápido" no significa "fácil para un principiante" . Personalmente, mi posición sobre este tema es: la dependencia de la complejidad de la solución del problema de la complejidad de la tarea en sí misma debe ser al menos lineal.
Otro punto no obvio: la interfaz puede no ser uniforme.
El ejemplo más común es usar la GUI y la CLI en un proyecto.
Hablé sobre el uso de varios editores al trabajar en el mismo entorno en un proyecto.
Desarrollo
Ahora podemos pasar directamente a las herramientas mismas.
Navegadores de reactores
Es imposible crear un refactorizador de navegador potente y universal simplemente porque la refactorización no existe ahora, como, condicionalmente, una disciplina académica.
El libro de Fowler , después de todo, está construido alrededor de Java con pasos mínimos a un lado. Además, las técnicas de refactorización están tan unidas al contexto de "biblioteca de lenguaje de estilos" que cada programador las genera en el acto.
Creo que los principios básicos de la refactorización pueden describirse desde el punto de vista de atravesar el árbol de datos en secciones de código, y ya se pueden extraer técnicas específicas de ellos . Para hacer esto, la implementación del refactorizador del navegador debe tener:
- Interfaz fácilmente extensible (para mostrar las técnicas creadas por el desarrollador para sus necesidades específicas)
- Los analizadores, la base (los principios antes mencionados) y el esquema de edición deben ocultarse para que el desarrollador tenga la oportunidad de ampliar el conjunto de técnicas sin tener que meterse en las entrañas de su editor. Es decir, DSL para describir técnicas de refactorización.
- Como la extensibilidad irá seguida de un fuerte aumento en el número de recepciones, para la visualización es necesario tener en cuenta el alcance del contexto para mostrar en el menú de selección solo las operaciones aplicables en una situación particular.
Análisis de árbol de datos en tiempo de ejecución.
Este aspecto se trata de combinar la depuración y la edición de texto. De hecho, para la gran mayoría de los idiomas, para comprobar cómo afectan los cambios al programa, es necesario reiniciarlo explícitamente. Mucho más fácil y más visual (y, como resultado, con menos errores posibles), será posible ver en un solo espacio cómo cambia toda la matriz de datos en la sección depurada del código justo cuando se edita el código.
El desarrollo de una herramienta de este tipo para diferentes idiomas difiere mucho en complejidad, y esto no es solo una cuestión de sintaxis, sistema de tipos y características de rendimiento, sino también en la esencia de cada idioma individual. Para un lenguaje basado en datos, construir esto es mucho más fácil. Ejemplo: constructores de expresiones regulares, donde en el proceso puede ver inmediatamente qué partes del texto cubre el texto regular.
El más, en mi opinión, el elemento más importante en esta lista incompleta.
Dividimos toda la información que el desarrollador necesita, directamente, para programar en dos grandes grupos.
- Documentación
- Recepciones \ heurística de desarrollo.
En primer lugar, para simplificar el trabajo del programador, el acceso a la documentación debe ser directamente desde la ventana del editor.
Varios IDE y editores resuelven bien este problema: IDEs específicos de idioma de Microsoft, Emacs con su modo de información, Frescobaldi, Sunny Builder; tanto para integrarse en la fuente, como para externa. Sin embargo, muchas bibliotecas y marcos ahora cargan su documentación solo en la red y / o usan diferentes formatos para almacenarla, lo que complica la posible integración en una sola interfaz.
El segundo grupo es mucho más interesante.
Cubre el conocimiento, tanto la programación como el desarrollo en su conjunto, y los métodos específicos de un idioma / pila en particular. Por el momento, Stack Overflow captura este nicho casi por completo, e incluso existe su integración en el IDE, pero la calidad de la experiencia a menudo es baja . Para bien, será mucho más eficiente seleccionar buenas decisiones, errores, trucos y reducirlo a una determinada base con la que el usuario pueda contactar cuando necesite resolver su propio problema.
Además, los analizadores modernos le permiten advertir sobre posibles errores, aún no comprometidos . Es decir, de hecho, tenemos, desde un punto de vista técnico, todo lo que necesitamos para crear sistemas expertos para desarrolladores que ofrezcan soluciones a medida que escribimos / editamos código. Lo que falta son solo las bases de decisión / métodos / errores en sí mismos.
Conclusión
Entonces, el resumen:
- El desarrollo de los navegadores refactorizados debe basarse en las operaciones en el árbol de datos y reducirse a una descripción similar a DSL de los scripts para la edición automática de código.
- Los analizadores de tiempo de ejecución deben mostrar instantáneamente los cambios de datos durante la edición y escritura de un programa. Es decir, el enfoque JAI se puede aplicar a otros lenguajes de programación.
- Elimine el navegador web de los casos de usuario como una forma de buscar y leer la documentación.
- Necesitamos desarrollar sistemas expertos de complementos (debido al hecho de que el entorno es diverso) que ayudarán al desarrollador a tomar decisiones en el proceso.