Je travaille donc sur mes recherches sur les difficultés de supporter Legacy, et j'ai remarqué un point évident que j'ai complètement perdu de vue.
Les utilisateurs et développeurs IDE ont du mal à comprendre leurs outils. Utilisé intuitivement et de toute façon. Étonnamment (agréable), une telle utilisation n'entre presque pas en conflit avec l'ignorance, bien qu'elle donne lieu à des holivars correspondants sur les forums.
Nous allons maintenant analyser comment les choses évoluent avec les outils, ce qui ne va pas avec le concept de "IDE", et quels outils auraient dû apparaître, mais n'ont pas encore été développés.
E
Ce ne sera pas une découverte que l'environnement est différent pour différents projets. Même s'ils fonctionnent sur une seule pile. Peut être utilisé:
- Différentes façons d'interagir avec l'utilisateur, ce qui donne une grande différence sur la façon dont le projet démarre et comment il est testé. (CLI, TUI, museau web, GUI au sens de Qt, GTK, etc.)
- Différents frameworks de test (unittest dans un projet, pytest dans un projet adjacent, dans le contexte de Python). Les liaisons des tests à plusieurs niveaux (par exemple, combinant les conclusions des tests autonomes et l'intégration via TAP) tombent également ici.
- VCS différent, mais quelque part il peut y avoir des hybrides (Git, en tant que client de Subversion dans un cas particulier).
- Dans le même projet peut être utilisé, y compris divers éditeurs. Par exemple, Vim ou nano pour éditer un script de rebase interactif dans Git, pour éditer des morceaux avec enregistrement partiel des modifications. Ou pour éditer les configs sous la racine.
Et ce sont loin de toutes les options, je pense que tout développeur ayant une expérience de 2 projets ou plus peut lancer des exemples plus similaires. Souvent, je les entends sous la forme de l'histoire "Comment j'ai passé deux jours à monter un projet pour un nouvel emploi."
De cela, nous pouvons conclure que la disposition et la configuration de l'environnement de développement incombent en tout cas à l'utilisateur.
Intégré?
Compte tenu de ce qui précède, il est logique de considérer non pas les environnements "intégrés", mais "intégrables" .
Ensuite, du point de vue de l'utilisateur, un bon outil d'intégration est lorsque:
- L'environnement s'installe rapidement.
- Sa configuration peut être stockée et transférée.
- Possibilité de rehausser l'environnement de travail "un bouton".
Par exemple, les Unixoids expérimentés réduisent souvent la «transition vers le mode de travail» à une seule équipe.
«Rapide» ici ne signifie pas «facile pour un débutant» . Personnellement, ma position sur cette question est la suivante: la dépendance de la complexité de la solution du problème de la complexité de la tâche elle-même doit être au moins linéaire.
Autre point non évident: l'interface peut ne pas être uniforme.
L'exemple le plus courant utilise à la fois l'interface graphique et l'interface CLI dans un projet.
J'ai parlé de l'utilisation de plusieurs éditeurs lorsque l'on travaille dans le même environnement sur un même projet.
Développement
Nous pouvons maintenant passer directement aux outils eux-mêmes.
Navigateurs de réacteurs
Il est impossible de créer un refactoriseur de navigateur puissant et universel simplement parce que le refactoring n'existe pas actuellement, comme, conditionnellement, une discipline académique.
Le livre de Fowler , après tout, est construit autour de Java avec un minimum de pas sur le côté. De plus, les techniques de refactoring sont si attachées au contexte "style-langage-bibliothèque" qu'elles sont générées directement par chaque programmeur.
Je crois que les principes de base de la refactorisation peuvent être décrits du point de vue de la traversée de l'arbre de données dans des sections de code, et des techniques spécifiques peuvent déjà en être tirées . Pour ce faire, l'implémentation du refactoriseur de navigateur doit avoir:
- Interface facilement extensible (pour afficher les techniques créées par le développeur pour ses besoins spécifiques)
- Les analyseurs, la base (les principes susmentionnés) et le schéma d'édition doivent être cachés afin de laisser au développeur la possibilité d'élargir l'ensemble des techniques sans avoir à entrer dans les tripes de son éditeur. C'est-à-dire DSL pour décrire les techniques de refactoring.
- Étant donné que l'extensibilité sera suivie d'une forte augmentation du nombre de réceptions, pour l'affichage, il est nécessaire de prendre en compte la portée du contexte afin d'afficher dans le menu de sélection uniquement les opérations applicables dans une situation particulière.
Analyse de l'arbre de données d'exécution.
Cet aspect consiste à combiner le débogage et l'édition de texte. En fait, pour la grande majorité des langues, afin de vérifier comment les changements affectent le programme, un redémarrage explicite du programme est nécessaire. Beaucoup plus facile et plus visuel (et, par conséquent, avec moins d'erreurs possibles), il sera possible de voir dans un seul espace comment l'ensemble du tableau de données dans la section déboguée du code change à mesure que le code est modifié .
Le développement d'un tel outil pour différentes langues varie considérablement en complexité, et ce n'est pas seulement une question de syntaxe, de système de type et de performances, mais dans l'essence de chaque langue individuelle. Pour un langage basé sur les données, la construction est beaucoup plus facile. Exemple: constructeurs d'expressions régulières, où dans le processus, vous pouvez immédiatement voir quelles parties du texte le texte régulier couvre.
Le plus, à mon avis, l'élément le plus important de cette liste incomplète.
Nous divisons toutes les informations dont le développeur a besoin pour, directement, la programmation en deux grands groupes
- La documentation
- Réceptions \ heuristique de développement.
Tout d'abord, pour simplifier le travail du programmeur, l'accès à la documentation doit se faire directement depuis la fenêtre de l'éditeur.
Divers IDE et éditeurs résolvent bien ce problème: les IDE spécifiques à la langue de Microsoft, Emacs avec son Info-mode, Frescobaldi, Sunny Builder; à la fois pour intégré dans la source, et pour externe. Cependant, de nombreuses bibliothèques et frameworks téléchargent désormais leur documentation uniquement sur le réseau et / ou utilisent différents formats pour la stocker, ce qui complique l'intégration possible dans une seule interface.
Le deuxième groupe est beaucoup plus intéressant.
Il couvre les connaissances, à la fois la programmation et le développement dans leur ensemble, et les méthodes spécifiques à un langage / pile particulier. Pour l'instant, ce créneau est presque entièrement capturé par Stack Overflow, et il y a même son intégration dans l'IDE, mais la qualité de l'expertise y est souvent faible . Pour de bon, il sera beaucoup plus efficace de sélectionner les bonnes décisions, les erreurs, les astuces et de les réduire à une certaine base que l'utilisateur peut contacter lorsqu'il a besoin de résoudre son propre problème.
De plus, les analyseurs modernes vous permettent d'avertir d' éventuelles erreurs non encore validées . En fait, nous avons, d'un point de vue technique, tout ce dont nous avons besoin pour créer des systèmes experts pour les développeurs offrant des solutions pendant que nous écrivons / éditons du code. Ce qui manque, ce ne sont que les bases de décision / méthodes / erreurs elles-mêmes.
Conclusion
Donc, le résumé:
- Le développement de navigateurs de refactorisation doit être basé sur des opérations sur l'arborescence de données et être réduit à une description de scripts de type DSL pour l'édition automatisée de code.
- Les analyseurs d'exécution devraient arriver à un affichage instantané des changements de données pendant l'édition et l'écriture d'un programme. Autrement dit, l'approche JAI peut être appliquée à d'autres langages de programmation.
- Supprimez le navigateur Web des cas d'utilisation pour rechercher et lire la documentation.
- Nous devons développer des plug-in (en raison de la diversité de l'environnement) des systèmes experts qui aideront le développeur à prendre des décisions dans le processus.