Vielfalt oder Uniform? Eclipse und IntelliJ im selben Projekt

Wenn wir mit neuer Besetzung in ein Projekt starten, stellen sich viele Fragen: welche Sprachen werden verwendet? Wie soll die Pipeline aussehen? Welche Tools verwenden wir?

Für die meisten Punkte findet sich schnell eine gemeinsame Lösung. Oft hat sich bereits ein Vorgehen oder Muster etabliert und kann so wiederverwendet werden – zum Beispiel beim Thema Codeformatierung. Doch mit unterschiedlichen Menschen kommen auch unterschiedliche Vorlieben. Viele Entwickler gewöhnen sich über lange Zeit an eine IDE und kennen sich damit sehr gut aus. Das Problem ist nur, dass selten alle die gleiche Entwicklungsumgebung nutzen möchten und hier muss eine Entscheidung getroffen werden – setzen alle das gleiche Werkzeug ein oder bleibt jeder bei dem, was er kennt? Hier ein paar Argumente für beide Seiten. (Hinweis: ich gehe hier nur auf die beiden verbreitetsten IDEs Eclipse und IntelliJ ein, die bei uns im Java-Umfeld Relevanz haben.)

Eine IDE für alle

Die einfachste Möglichkeit ist es, eine IDE als Standard festzulegen, die alle im Team dann nutzen (müssen). Daraus ergeben sich folgende Vorteile:

  • Alle Einstellungen, von Codeformatierung über Templates bis zu Save Actions, müssen nur an einer Stelle gepflegt werden. Dazu kann man noch je nach IDE bequeme Verteilungsmechanismen nutzen, z.B. Oomph oder Yatta bei Eclipse oder das Settings Repository bei IntelliJ.
  • Tiefergehendes Know-How im Umgang mit der Entwicklungsumgebung kann sich gut im Team verteilen – es gibt keine fragenden Gesichter, wenn jemand ein Feature erklärt, sondern eher den „Aha-Effekt“.
  • Jeder findet sich beim Anderen zurecht – das hilft gerade bei Pair Programming Sessions. So vermeidet man den Klassiker: „Welche Tastenkombination ist das denn hier?“

 

Gemischte Welt

Der Gegenentwurf: jeder arbeitet mit dem, was er kennt und liebt. Da kommt folgendes in den Sinn:

  • Wer sich nicht umstellen muss, kann effizient arbeiten. Bis die ganzen Menüwege, Tastenkürzel und Verhaltensweisen einer neuen IDE in Fleisch und Blut übergegangen sind, vergeht viel Zeit und die ist ja bekanntermaßen Geld. Hier gilt es also dringend abzuwägen, ob der erhöhte Abstimmungsaufwand bei gemischten IDEs das rechtfertigt.
  • Es entsteht ein Know-How Austausch über den eigenen Tellerrand hinweg. Je nach Anwendungsfall bieten verschiedene Werkzeuge objektiv betrachtet eine bessere Unterstützung und da ist es gut, wenn man weiß, welches das richtige Werkzeug ist. Nicht umsonst gibt es das Sprichwort: „Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

 

Möglichkeiten zur Zusammenarbeit

Für beide Vorgehensweisen gibt es gute Gründe. In einem aktuellen Projekt haben wir den zweiten Weg gewählt und sind nach anfänglichen Startschwierigkeiten inzwischen ganz zufrieden. Wie bekommt man aber nun eine Zusammenarbeit einfach hin?

Doppelte Pflege

Die schlechteste Variante – jede Einstellung separat für die IDEs festlegen und pflegen. Die Abweichung voneinander ist quasi vorprogrammiert und man ärgert sich schnell über riesige Diffs im Pull Request.

EditorConfig

Das Projekt editorconfig.org hilft dabei, grundlegende Konventionen für den Code IDE-übergreifend einhalten zu können. Es wird von sehr vielen Editoren unterstützt (teils über Plugins, teils nativ) und bietet eine Konfiguration über .ini Dateien nach folgendem Muster:

Solange die gemeinsamen Regeln für den Code im Team nicht zu umfangreich sind, ist das eine tolle Sache. Sobald die Regeln aber über die unterstützten Features hinausgehen, scheitert der Ansatz leider.

Eclipse Settings in IntelliJ importieren

IntelliJ unterstützt seit Version 13 von Haus aus den Import von Eclipse Formatierungseinstellungen. Leider gab es hier recht schnell Ernüchterung bei uns, denn immer wieder fanden wir einzelne Punkte, die dann doch nicht übernommen wurden. Als Alternative nutzen wir inzwischen die beiden IntelliJ Plugins Eclipse Code Formatter und Save Actions. Dadurch konnten wir tatsächlich (fast!) alle unsere Regeln durch einen einfachen Import übernehmen. Eine 100% Lösung haben wir zwar immer noch nicht, aber dieser Weg funktioniert für uns ausreichend gut. Die festgelegten Regeln ändern sich ja im Laufe des Projekts eher wenig, daher ist uns vor allem wichtig, dass neue Entwickler sich schnell einrichten können.

 

Würde ich es im nächsten Projekt nun genauso tun? Ganz klar: es kommt drauf an – und zwar auf die Teammitglieder. Wenn es eine halbwegs gleiche Verteilung an Präferenzen gibt, dann ist das Mischmodell ein guter Weg, um früh effizient arbeiten zu können und die Erfahrung hat gezeigt, dass es funktioniert. Bei einem homogeneren Team mit wenigen Ausreißern würde ich wohl eine IDE vorgeben, um die dadurch entstehenden Vorteile für das Projekt mitnehmen zu können.

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*