Editor oder IDE? Ein weiterer Analyseversuch

    Ich möchte dieses eher kontroverse Thema noch einmal ansprechen.

    Seit ich mich mit Programmierung beschäftige, beschäftigt mich diese Frage, und zahlreiche Themen in Foren und in Habré sind noch nicht geklärt. Außerdem scheinen mir einige Argumente für die eine oder andere Seite nicht gegeben worden zu sein. Und die angegebenen sind falsch priorisiert und der Kontext fehlt.

    In dem Artikel werde ich versuchen, diese Auslassung zu korrigieren und weitere Punkte auf das "ё" zu setzen.

    Ich lade alle ein, sich an der Suche nach dem perfekten Werkzeug zu beteiligen.

    Über meine Erfahrung


    Ich fing an, wieder in DOS zu programmieren. bei Turbo Pascal. Außerdem haben wir die IDE dann aus irgendeinem Grund nur zum Debuggen verwendet, und das ist ziemlich selten. Für das Schreiben von Code bevorzugten sie einige namenlose edit.exe ohne Syntaxhervorhebung in Verbindung mit Volkov Commander. Und das war genug. Auf die gleiche Weise beschäftigte ich mich später mit Assembler und teilweise mit C ++.

    Ich lernte weiterhin C ++ und wechselte zu Windows und dementsprechend zu Visual Studio - wo würde ich ohne es hingehen. Ich fand Versionen, wenn ich mich nicht irre, von 5 bis 7. Nach einem einfachen Editor war es etwas - Codegenerierung und automatische Vervollständigung waren eine Freude. Es war zwar fast unmöglich, all das Gute auszusortieren, aber es schien unwichtig.

    Nach einiger Zeit wechselte ich zu Linux und begann mit der Webentwicklung in PHP. Hier habe ich parallel vim studiert und ZendStudio für die Entwicklung verwendet. Irgendwann habe ich angefangen, nur Vim für alles zu verwenden - ich habe es in Übereinstimmung mit zahlreichen Handbüchern in eine kleine Idee verwandelt. Darin schrieb er sein erstes Fahrrad-CMS in PHP.

    Ich stelle fest, dass das Programmieren vorher nicht der Haupttyp meiner Tätigkeit war. Ja, ich habe verschiedene kleine Hilfsprogramme für die Arbeit geschrieben, Themen für WordPress erstellt, aber die Hauptaktivität war die Verwaltung.

    Sobald ich anfing, mich professionell zu entwickeln, reichten mir die vim-Fähigkeiten nicht mehr aus. Es gab zuerst eine Sonnenfinsternis, dann Netbeans, jetzt Phpstorm.

    Seit einem halben Jahr versuche ich heldenhaft, Emacs zu meistern, einschließlich als Hauptarbeitsumgebung.

    Ich habe also etwas zu vergleichen und hoffe, dass meine Meinung einigermaßen begründet ist.

    IDE? IDE ...


    Ich habe lange darüber nachgedacht, in welcher Form die Vor- und Nachteile der Parteien zu vergleichen sind. Die Liste hierfür ist nicht sehr gut geeignet, weil Eine einfache Auflistung spiegelt den Kern der Sache nicht vollständig wider. Der Editor und die IDE sind keine Gegensätze, sondern Werkzeuge, deren Umfang sich in einem bestimmten Bereich überschneidet. Vorteile des Editors sind keineswegs immer Nachteile der Umwelt und umgekehrt. Aus diesem Grund finden mehr oder weniger strukturierte Diskussionen zum Thema statt.

    Ich beginne vielleicht mit einem der unbestreitbaren Vorteile des Editors - seinen umfangreichen Möglichkeiten, mit Text zu arbeiten, und der Möglichkeit, alles zu tun, ohne die Hände von der Tastatur zu nehmen. Die meisten Umgebungen wissen nicht wie. Aber gibt es eine solche Notwendigkeit beim Schreiben von Code? Wenn Sie einen Artikel oder einen Brief schreiben, ist es meines Erachtens bequem, zwei Wörter mit einem Klick auf die Taste zu tauschen oder den Absatz auf der Seite nach oben zu verschieben. Im Programmtext ist dies jedoch in den meisten Fällen sinnlos und erfordert ein Refactoring. Und Sie müssen dafür entweder mit fingersensitiven Tastaturkürzeln und Emacs oder nicht weniger kniffligen Befehlen in vim bezahlen. Aber all das muss in Erinnerung bleiben! Was einfach durch eine einzige Mausbewegung wie das Verschieben eines Fensters oder das Ändern der Größe gelöst wird, wird zu einer ganzen Aufgabe. Ja, sogar das Auswählen von Text ist mit der Maus einfacher - genauer, schneller, und es ist zu überlegen, wie viele wörter sich an der gewünschten stelle im text befinden. Nein, der Programmierer auchDiese Funktionen können nützlich sein, aber die Zeit, die für die eigentliche Bearbeitung des Codes aufgewendet wird, ist vernachlässigbar, sodass praktisch keine Zeitvorteile entstehen. Eine signifikante Komplikation des Instruments ist jedoch offensichtlich.

    Ein Programmierer verbringt 80% seiner Zeit damit, Code zu verstehen und zu schreiben. Darüber hinaus ist die Bewegung per Code und nicht per Text! Und hier kann ihm der Redakteur mit absolut nichts helfen. Die Liste der Methodenparameter im Tooltip wird nicht angezeigt, die Definition der Methode wird nicht zugelassen, die Syntax wird nicht gesteuert. Und IDEs, auch die einfachsten, gehen einfach und elegant damit um. Ich habe vor kurzem ungefähr 10 Minuten damit verbracht, in einem Projekt mit dem Silversearcher von Emacs nach einer Definition einer Methode zu suchen. Es stellte sich heraus, dass die Klasse in einem anderen Modul usw. definiert wurde. 10 Minuten statt eines Mausklicks! Ich bin Emacs, natürlich nicht erfahren genug, also lass es 5 Minuten sein, sogar eine Minute. Trotzdem ist das Verhältnis beeindruckend.

    Und hier zeigt die IDE ihr vielleicht einziges, aber sehr kühnes Plus - das Vorhandensein einer Parser-Programmiersprache. Die Umgebung "versteht", dass sie den Code bearbeitet. Der Herausgeber ist nicht. Dabei handelt es sich um automatische Vervollständigung, Navigation, Hervorhebung der Syntax und manchmal um semantische Fehler. Es scheint übertrieben, eine angenehme Kleinigkeit, verwöhnen. Dies wird jedoch erst dann erforderlich, wenn der Umfang des Projekts eine bestimmte Grenze überschreitet. Und unter Berücksichtigung der voluminösen modernen Rahmenbedingungen kommt diese Grenze fast sofort.

    Ja, bei einem Projekt mit einem Dutzend Dateien und ein paar tausend Zeilen zeigt sich dieses Plus nicht in seiner ganzen Pracht. Ein Editor kann die gleiche automatische Vervollständigung durchführen, aber sinnlose Optionen werden niemals ausgeschlossen. Und wenn die Projektgröße sich 100.000 Zeilen nähert und aus Tausenden von Dateien außer Bibliotheken besteht, wird es schwierig, den richtigen Namen aus dem Hash aus den Namen von Variablen, Methoden anderer Klassen und nur Wörtern aus Kommentaren zu wählen (ich hatte dies in vim Ich weiß nicht, vielleicht haben sie es behoben. Intelligente Eingabeaufforderungen machen es überflüssig, sich die Namen der erforderlichen Funktionen und deren Parameter zu merken. Oft ist dies physikalisch einfach unmöglich.

    Apropos Projekte. Alle IDEs haben dieses Konzept. Einstellungen, Ressourcen sind daran angehängt, Sie können suchen, etc. In Editoren ist dies bestenfalls ein offenes Dateisystemverzeichnis. Manchmal ein bisschen mehr.

    Die Integration mit dem Debugger in Editoren lässt ebenfalls zu wünschen übrig. Unit-Tests und Protokollierungen retten die Situation in gewissem Maße, manchmal jedoch auch ohne Debugger.

    Jemand könnte einwenden, dass in modernen Editoren viele dieser Funktionen bereits implementiert sind und den anspruchsvollsten IDEs in nichts nachstehen. Ich stimme nicht zu. Erstens gibt es keine vollwertigen Implementierungen. Sie arbeiten nicht so, wie sie sollten. Zweitens ist die Installation bereits eine recht komplizierte Aufgabe. Ja, auch die Konfiguration der internen Funktionen des Editors ist bereits nicht trivial. Versuchen Sie beispielsweise, die Zeilennummerierung in denselben Emacs zu aktivieren! Außerdem wird die gewünschte Funktionalität oft von einem Dutzend Plug-Ins implementiert, und es ist unklar, wie sie miteinander interagieren. Und oft haben sie auch ein Dutzend Versionen und Zweige, die nicht immer kompatibel sind, komisch abgestimmt sind usw. Sie können natürlich einen Monat damit verbringen, alles zu konfigurieren und zu installieren (was auch die meisten Enthusiasten sind), aber dies bringt den Editor nur näher an die IDE-Ebene. Z.B, Kehren wir zu denselben Projekten zurück - ich habe Project unter vim und Projectile unter emacs und einigen weiteren Plugins ausprobiert. Wenn Project meine Anforderungen noch mehr oder weniger erfüllt (obwohl ich in der neuesten Version aufgrund von Fehlern überhaupt kein Projekt erstellen konnte), hat Projectile einen äußerst negativen Eindruck hinterlassen.

    Dennoch haben Redakteure mehrere Anwendungsbereiche, in denen sie zumindest eine Konkurrenz zu Entwicklungsumgebungen verdienen.

    Zum einen zeigen sie sich bei kleinen Projekten besser. Es macht keinen Sinn, einen IDE-Prozessor für die Arbeit mit einem Projekt in 10-20 Dateien zu laden. Es ist einfacher, 3-4 Zeilen im Editor zu korrigieren.

    Zweitens werden in einigen spezifischen Bereichen alle Vorteile der IDE gebündelt. Zum Beispiel Low-Level-Entwicklung für Linux. Ich habe das nicht getan, aber gemessen an der Codestruktur und den Vorlieben der Entwickler (etwa 70% sind Emacs und Klone, 25% sind Vim, 5% sind so etwas wie exotisch wie jedermann), hat das nichts mit der IDE zu tun. Der gesamte Code, mit dem die Arbeit ausgeführt wird, wird in der Regel in ein oder zwei Dateien gesammelt, und es ist nicht erforderlich, innerhalb des gesamten Projekts zu springen. Die automatische Vervollständigung hilft nicht viel, wenn Sie aus einem Dutzend oder zwei Funktionen mit fast denselben Namen auswählen.

    Drittens können Redakteure nicht nur mit Code arbeiten. Ihre gesamte Leistung kann beim Arbeiten mit CSV- oder XML-Dateien genutzt werden. Oder etwas anderes, was manchmal notwendig ist, wie ein Artikel oder ein Brief. Und Sie müssen nicht umlernen, nach einem praktischen Programm suchen oder sich an Tastenkürzel erinnern - alles ist zur Hand, alles ist gleich.

    Viertens die Fähigkeit, mit Sprachen zu arbeiten, für die es keine vernünftige IDE gibt. Nehmen wir an, Rubin hat mir mit demselben Rubin nicht viel geholfen. SublimeText erwies sich als ausreichend. Obwohl ich nicht mit einem großen Ruby-Projekt gearbeitet habe, würde sich die IDE vielleicht dort zeigen.

    Und fünftens die berüchtigte Möglichkeit der Expansion. Mit guten Plugins wird der Editor sehr praktisch! Darüber hinaus sind die besondere Freude am kontinuierlichen Stimmen Ihres Hauptinstruments und das Gefühl der vollständigen Kontrolle darüber von großem Wert.

    Total


    Ich mag die IDE nicht wirklich, obwohl es im vorherigen Text so scheint. Ich denke, sie sind ziemlich monströs, mit einer Menge unnötiger Funktionen, langsam und ressourcenintensiv. Und die besten von ihnen sind ziemlich teuer. Darüber hinaus finde ich, dass die Verwendung der IDE entspannend und bindend ist. Die Herausgeber sind jeweils das Gegenteil. Plus, die Verfügbarkeit und die Möglichkeiten der Feineinstellung für Sie. Zumindest Vim und Emacs. Am Ende mag ich sie einfach. Diesen Artikel schreibe ich zum Beispiel in Emacs.

    Aber die Industrie (und ihre Vorgesetzten) diktieren ihre eigenen Anforderungen. Wenn Sie die IDE nicht verwenden, sinkt die Leistung erheblich. Aber niemand wird Ihnen eine halbe Stunde Zeit geben, um in zehntausend Codezeilen nach einem fehlenden Komma zu suchen. All dies sollte automatisch erfolgen und automatisch korrigiert werden. Manchmal stöbere ich auch gerne ohne Werkzeug im Code herum - aber bei der Arbeit ist es eine unzulässige Zeitverschwendung.

    Nach all meinen Versuchen und Irrtümern bin ich zu diesem Schluss gekommen - der Herausgeber kannVerwenden Sie es für die Entwicklung, aber mit einer IDE kann es nach einer bestimmten Grenze nicht mehr verglichen werden. Die Verwendung des Editors für etwas, für das Sie bezahlt werden, ist ein unzulässiger Luxus. Ja, wenn Sie die richtigen Entwicklungspraktiken anwenden, den Code korrekt entwerfen / dokumentieren, den Standards folgen, können Sie die inhärenten Mängel der Editoren beseitigen. Da wir jedoch nicht in einer idealen Welt leben, ist die Verwendung von IDEs eine Notwendigkeit, unabhängig von unserem Wunsch.

    Jetzt auch beliebt: