Ich arbeite daher an meinen Nachforschungen über die Schwierigkeiten bei der Unterstützung von Legacy und habe einen offensichtlichen Punkt bemerkt, den ich völlig aus den Augen verloren habe.
IDE-Benutzer und IDE-Entwickler haben Probleme, ihre Tools zu verstehen. Intuitiv und trotzdem verwendet. Überraschenderweise (angenehm) widerspricht eine solche Verwendung fast nicht der Unwissenheit, obwohl sie zu entsprechenden Holivars in den Foren führt.
Jetzt werden wir analysieren, wie sich die Dinge mit Tools entwickeln, was mit dem Konzept der "IDE" nicht stimmt und welche Tools hätten erscheinen sollen, aber noch nicht entwickelt wurden.
E.
Es wird keine Entdeckung sein, dass die Umgebung für verschiedene Projekte unterschiedlich ist. Auch wenn sie auf einem Stapel arbeiten. Kann verwendet werden:
- Verschiedene Arten der Interaktion mit dem Benutzer, was zu einer großen Diskrepanz hinsichtlich des Starts und des Testens des Projekts führt. (CLI, TUI, Web-Maulkorb, GUI im Sinne von Qt, GTK usw.)
- Verschiedene Test-Frameworks (unittest in einem Projekt, pytest in einem benachbarten, im Kontext von Python). Hier fallen auch die Bindungen von Mehrebenentests (z. B. die Kombination der Schlussfolgerungen von eigenständigen Tests und die Integration durch TAP).
- Unterschiedliches VCS, aber irgendwo kann es Hybride geben (Git, in einem speziellen Fall als Client für Subversion).
- Innerhalb desselben Projekts können verschiedene Editoren verwendet werden. Zum Beispiel Vim oder Nano zum Bearbeiten eines interaktiven Rebase-Skripts in Git, zum Bearbeiten von Chunks mit teilweiser Registrierung von Änderungen. Oder um Konfigurationen unter dem Stamm zu bearbeiten.
Und dies sind bei weitem nicht alle Optionen. Ich denke, dass jeder Entwickler mit Erfahrung in zwei oder mehr Projekten ähnlichere Beispiele liefern kann. Oft höre ich sie in Form der Geschichte "Wie ich zwei Tage damit verbracht habe, ein Projekt für einen neuen Job einzurichten".
Daraus können wir schließen, dass das Layout und die Konfiguration der Entwicklungsumgebung in jedem Fall beim Benutzer liegt.
Integriert?
Vor diesem Hintergrund ist es sinnvoll, nicht "integrierte", sondern "integrierbare" Umgebungen zu berücksichtigen.
Aus Sicht des Benutzers ist ein gutes Integrationswerkzeug dann, wenn:
- Die Umgebung ist schnell eingerichtet.
- Seine Konfiguration kann gespeichert und übertragen werden.
- Möglichkeit, die Arbeitsumgebung mit einem Knopfdruck wiederherzustellen.
Beispielsweise reduzieren erfahrene Unixoide häufig den "Übergang in den Arbeitsmodus" auf ein Team.
"Schnell" bedeutet hier nicht "einfach für einen Anfänger". Persönlich ist meine Position zu diesem Thema: Die Abhängigkeit der Komplexität der Lösung des Problems von der Komplexität der Aufgabe selbst sollte mindestens linear sein.
Ein weiterer nicht offensichtlicher Punkt: Die Schnittstelle ist möglicherweise nicht einheitlich.
Das häufigste Beispiel ist die Verwendung der GUI und der CLI in einem Projekt.
Ich habe über die Verwendung mehrerer Editoren gesprochen, wenn an einem Projekt in derselben Umgebung gearbeitet wird.
Entwicklung
Jetzt können wir direkt zu den Werkzeugen selbst übergehen.
Reaktorbrowser
Es ist unmöglich, einen leistungsstarken und universellen Browser-Refactor zu erstellen, nur weil Refactoring derzeit nicht als akademische Disziplin existiert.
Immerhin basiert Fowlers Buch auf Java mit minimalen Schritten zur Seite. Außerdem sind Refactoring-Techniken so an den Kontext der "Stil-Sprachbibliothek" gebunden, dass sie von jedem einzelnen Programmierer direkt vor Ort generiert werden .
Ich glaube, dass die Grundprinzipien des Refactorings unter dem Gesichtspunkt des Durchlaufens des Datenbaums in Codeabschnitten beschrieben werden können und dass daraus bereits spezifische Techniken abgeleitet werden können . Zu diesem Zweck sollte die Browser-Refactor-Implementierung Folgendes enthalten:
- Leicht erweiterbare Benutzeroberfläche (um die vom Entwickler für seine spezifischen Anforderungen erstellten Techniken anzuzeigen)
- Die Analysatoren, die Basis (die oben genannten Prinzipien) und das Bearbeitungsschema müssen ausgeblendet werden, damit der Entwickler die Möglichkeit hat, die Techniken zu erweitern, ohne sich auf die Eingeweide seines Editors einlassen zu müssen. Das heißt, DSL zur Beschreibung von Refactoring-Techniken.
- Da auf die Erweiterbarkeit eine starke Zunahme der Anzahl der Empfänge folgt, muss für die Anzeige der Kontextbereich berücksichtigt werden, um im Auswahlmenü nur die in einer bestimmten Situation anwendbaren Vorgänge anzuzeigen.
Analyse des Laufzeitdatenbaums.
Bei diesem Aspekt geht es darum, Debugging und Textbearbeitung zu kombinieren. Tatsächlich ist für die überwiegende Mehrheit der Sprachen ein expliziter Neustart des Programms erforderlich, um zu überprüfen, wie sich Änderungen auf das Programm auswirken. Viel einfacher und visueller (und infolgedessen mit weniger möglichen Fehlern) ist es möglich, in einem einzigen Bereich zu sehen, wie sich das gesamte Datenarray im debuggten Abschnitt des Codes beim Bearbeiten des Codes ändert .
Die Entwicklung eines solchen Tools für verschiedene Sprachen unterscheidet sich stark in der Komplexität, und dies ist nicht nur eine Frage der Syntax, des Typsystems und der Leistungsmerkmale, sondern im Wesentlichen jeder einzelnen Sprache. Für eine datengesteuerte Sprache ist das Erstellen viel einfacher. Beispiel: Konstruktoren für reguläre Ausdrücke, bei denen Sie sofort sehen können, welche Textteile der reguläre Text abdeckt.
Der meiner Meinung nach wichtigste Punkt in dieser unvollständigen Liste.
Wir teilen alle Informationen, die der Entwickler für die direkte Programmierung benötigt, in zwei große Gruppen auf
- Dokumentation
- Empfänge \ Entwicklungsheuristik.
Um die Arbeit des Programmierers zu vereinfachen, sollte der Zugriff auf die Dokumentation zunächst direkt über das Editorfenster erfolgen.
Verschiedene IDEs und Editoren lösen dieses Problem gut: sprachspezifische IDEs von Microsoft, Emacs mit seinem Info-Modus, Frescobaldi, Sunny Builder; sowohl für in die Quelle integriert als auch für extern. Viele Bibliotheken und Frameworks laden ihre Dokumentation jetzt jedoch nur noch im Netzwerk hoch und / oder verwenden unterschiedliche Formate , um sie zu speichern, was die mögliche Integration in eine einzige Schnittstelle erschwert.
Die zweite Gruppe ist viel interessanter.
Es umfasst sowohl Programmier- als auch Entwicklungskenntnisse sowie Methoden, die für eine bestimmte Sprache / einen bestimmten Stapel spezifisch sind. Im Moment wird diese Nische fast vollständig von Stack Overflow erfasst, und es gibt sogar eine Integration in die IDE, aber die Qualität des Fachwissens dort ist oft gering . Für immer wird es viel effizienter sein, gute Entscheidungen, Fehler, Tricks auszuwählen und auf eine bestimmte Basis zu reduzieren, an die sich der Benutzer wenden kann, wenn er sein eigenes Problem lösen muss.
Darüber hinaus können Sie mit modernen Analysegeräten vor möglichen, noch nicht festgeschriebenen Fehlern warnen. Das heißt, wir haben aus technischer Sicht alles , was wir brauchen, um Expertensysteme für Entwickler zu erstellen, die Lösungen anbieten, während wir Code schreiben / bearbeiten. Was fehlt, sind nur die Entscheidungsgrundlagen / Methoden / Fehler selbst.
Fazit
Also die Zusammenfassung:
- Die Entwicklung von Refactor-Browsern sollte auf Operationen im Datenbaum basieren und auf eine DSL-ähnliche Beschreibung von Skripten für die automatisierte Codebearbeitung reduziert werden.
- Laufzeitanalysatoren sollten während der Bearbeitung und des Schreibens eines Programms eine sofortige Anzeige von Datenänderungen erhalten. Das heißt, der JAI-Ansatz kann auf andere Programmiersprachen angewendet werden.
- Entfernen Sie den Webbrowser aus den Benutzerfällen, um die Dokumentation zu suchen und zu lesen.
- Wir müssen Plug-in-Expertensysteme entwickeln (aufgrund der unterschiedlichen Umgebung), die dem Entwickler helfen, Entscheidungen in diesem Prozess zu treffen.