Facebook
Twitter
Google+
Kommentare
22

Standardisierung der IDE

Wisst ihr, was wirklich fies ist? Ein neues Handy zu bekommen und keine SIM Karte dazu zu haben. Und noch fieser ist es, wenn man das Handy gar nicht benutzen kann, wenn keine SIM Karte drinnen ist. So genug gejammert! Hab übrigens mal aus Spaß geschaut, ob man PHP auf dem Handy installieren kann und so wie es aussieht geht es. Macht natürlich keinen Sinn, aber cool ist es schon.

Einleitung Ende. Anfang des eigentlichen Themas. Ich hatte ja vorgstern schon ein wirklich diskusionsfreudiges Thema angesprochen, die Template Engines und ich hoffe, dass wir heute ein ähnlich gute Diskussion hinbekommen. Es geht um IDEs. Jeder hat seine Lieblings-Entwicklungsumgebung. Bei mir ist es PDT. Ich kenne und arbeite mit Leuten, bei denen es Netbeans, Notepad++, VIM, Zend Studio oder Emacs ist. Also eine sehr heterogene Infrastruktur. Jeder behauptet auch, dass seine IDE die beste ist und Dinge kann, die die anderen nicht können. Dem würde ich aber wiedersprechen. Netbeans und PDT schenken sich nicht viel. Beide sind ähnlich mächtig. Ich nehme einfach mal die zwei einzigen IDEs, die ich aufgezählt habe.

Wenn ich also in einer Firma arbeite, dann hätte ich gerne, dass alle die gleiche IDE verwenden. Auf diese Art kann das Wissen viel besser aufgebaut werden. Jeder kann jedem bei Problemen helfen. Alle haben die gleichen Einstellungsmöglichkeiten. Tipps und Tricks können geteilt werden.

Wirklich klar wurde mir das, als ich angefangen habe Codesniffer Sniffs zu schreiben und die in die IDE einbauen wollte. Ich würde es nie hinbekommen, es in alle IDEs zu integrieren. In PDT war’s ja auch nur möglich, da das PTI Plugin erschienen ist. Standardisierung kann viele Dinge vereinfachen.

Andererseits kann es problematisch sein, wenn man einem Entwickler eine IDE vorschreibt, die er gar nicht leiden kann. Aber ich denke viel ist da einfach nur psychologischer Natur. Man kann sich schon umgewöhnen.

Wie denkt ihr darüber? Würde es für euch ein Problem darstellen, wenn euer Arbeitgeber euch eine Standard-IDE „aufzwängt“? Ich finde Vereinheitlichung wichtig und würde es deshalb auch befürworten.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

22 Comments

  1. @tobias

    Nils hat doch noch eingeschränkt, dass er eigentlich nur Netbeans und PDT als IDE sieht

    @Thema

    Ich denke, ein Entwickler sollte so flexibel sein, dass er auch mit anderen Tools als seinem Lieblingstool zurecht kommt. Er sollte den Arbeitgeber aber im Bedarfsfall darauf hinweisen, dass es beim Umstieg von seiner IDE auf die vorgeschriebene IDE zu Beginn zu Produktivitätsverlusten kommen könnte. Zu Beginn muss sich jeder ja erst einmal zurecht finden. Wenn der Arbeitgeber langfristig sich von einer Standard-IDE mehr verspricht, muss er eben damit zurecht kommen, dass einige Mitarbeiter nach der Umstellung weniger produktiv sein werden. Wie lange sich diese Phase hinzieht, hängt dann von vielen Faktoren ab.

    Reply
  2. bei mir wars so das ich anfangs nur mit irgendwelchen ides zumgespielt hatte, die letzte war phpedit glaub ich.
    als ich dann zu meinem jetzigen Arbeitgeber kam war eclipse+pdt das tool was alles genutzt haben und dabei bin ich bis heute geblieben. hab auch schon netbeans und etliche andere Sachen durch, aber pdt ist einfach gut, wenns in der neuen Version auch ein wenig instabil ist und mal zu Abstürzen neigt beim workspace update, aber das hab ich einfach abgestellt.

    Reply
  3. Hi,

    bin auch der Meinung jeder Entwickler sollte wenn irgendwie möglich die IDE benutzen, welche ihm an besten gefällt. So lange dadurch keine Kosten entstehen (PDT, NetBeans & co). Komplizierter wird es natürlich wenn Zend Studio oder andere kommerzielle Produkte bevorzugt werden.

    Reply
  4. Ich würde es nicht gut finden, wenn ich mir meine IDE nicht selbst auswählen kann. Jedoch bin ich der Meinung und bisher haben wir es auch so gehalten, dass man innerhalb eines Projekts unbedingt nur eine IDE verwenden sollte.
    Daraus ergibt sich die Möglichkeit bei unterschiedlichen Projekten die Vorteile der unterschiedlichen IDEs kennen zu lernen, meist sind einige Teammitglieder eben grade mit dieser besser vertraut und können so ihr Wissen an die anderen übertragen.
    Sicher ist es nicht so, dass ständig zwischen der gesamten Bandbreite gewechselt wird, aber zwischen NetBeans und PDT schon.

    Reply
  5. Ich würde mir die Vorgabe einer Standard-IDE seitens des Arbeitgebers sehr wünschen. Auch wenn manche Kollegen nicht von meiner Lieblings-IDE (eclipse PDT) auf Anhieb begeistert sind. Da kommen die bekannten Vorurteile: zu langsam – beim Starten der IDE hol ich mir erst mal einen Kaffee, zu mächtig und kompliziert etc. Doch wenn man diese hervorragende IDE, voraussetzen würde ich optimaler Weise 6 GB Arbeitsspeicher aufgrund zahlreicher / aufwendiger Parsings der Sourcen, erst ein Mal kennenlernen und die Features genießen durfte, ist jeder Kollege dankbar. Dies fängt schon bei so kleinen Nettigkeiten an, dass durch Strg+Linksklick auf einen Funktionsaufruf direkt zu der Deklaration der entsprechenden Funktion gesprungen werden kann. So was kann TextPad, Notepad und wie sie alle heißen einfach nicht. Man muss den Kollegen von Zeit zu Zeit immer mal wieder ein Leckerli reichen (Debuggen, PTI), damit sie die Mächtigkeit der IDE mit Freude und Begeisterung erlernen und diese lieben lernen.

    Lange Rede, kurzer Sinn: Ich bin für eine Standardisierung!

    Reply
  6. Ich habe über die Jahre verschiedene IDEs genutzt und nutzen müssen. Daher vertrete ich den Standpunkt, dass ein Entwickler, wenn er nur alleine an einem Projekt arbeitet (und das auch immer so bleiben wird), durchaus selbst die Wahl haben darf. Weicht seine Wahl vom Firmenstandard ab, so muss gewährleistet sein, dass der Entwickler Fehler der IDE selbst beheben kann und nicht den IT-Support belästigt. Wenn allerdings eine Gruppe daran arbeitet oder arbeiten wird, sollte man sich auf eine IDE einigen oder durch die Firma eine vorschreiben lassen. So bleibt das Projekt „clean“ und die Entwickler können sich gegenseitig bei Fehlern der IDE helfen. Bei eclipse kann man ausserdem einfach die komplette Umgebung grad auf einen neuen Rechner kopieren und hat gleich alle Plugins 😉
    Viele Grüße,
    Uli

    Reply
  7. Ich halte von einer Standardisierung von IDEs nichts. Jeder sollte so Erwachsen genug sein und sich selber eine Meinung über evtl. Werkzeuge bilden können. Weil unterm Strich tun sich die IDEs in der jeweiligen Grundausstattung nicht wirklich viel. Jede kann mit Datenbanken umgehen, jede hat code completion, und direkt daneben die jeweilige Dokumentation zur Funktion. Versionsverwaltung ist auch direkt mit drin. Und zu irgendwelchen Deklarationen von Funktionen oder Methoden findet man auch. Aber dennoch habe ich schon unterscheide zwischen Netbeans und PDT festgestellt.
    Und letzten Endes nutze ich die IDE mit dessen Macken ich mich am besten arrangieren kann.

    Reply
  8. Auch wenn ich hier die Freiheit genieße, die IDE meiner Wahl zu nutzen, denke ich, dass eine Standard-IDE durchaus Sinn macht. Die Einarbeitungszeit wird bei regelmäßiger Nutzung im Rahmen bleiben. Zumal man, wie Nils schon ansprach, durch Diskussion mit den anderen Entwicklern im Laden auf einen vorhandenen „Wissenspool“ zurückgreifen kann und somit Hilfe direkt vor Ort hat, wenn’s mal hakt. Natürlich ist es erst einmal aufwändig sich in eine neue IDE einzuarbeiten, aber es hat wohl noch niemanden geschadet über den Tellerrand hinauszuschauen 🙂

    Reply
  9. NACHTRAG: Es liest sich jetzt so, dass ich natürlich gut reden habe, weil ich mir die IDE bisher ausgesucht habe.

    Ich habe aber vergessen zu schreiben, dass ich mich ab nächster Woche umstellen muss und mit dem Zend Studio for Ecplipse arbeiten werde. Also trifft o.g. auch auf mich zu. Ich werde mich fügen und freu mich auch schon drauf Neues kennenzulernen

    Reply
  10. Das ist wirklich nur eine Gewohnheitssache. Ich habe sehr lange mit PDT gearbeitet. Bei der Arbeit ging das jedoch nicht so gut, das das Programm recht viel Leistung von dem PC abverlangt. Also musste ich Alternativen suchen und haben Netbeans gefunden. Seit dem arbeite ich fast nur noch damit. Deswegen kann man durhcaus eine IDE vorschreiben. Nach ein/zwei Wochen ist das Arbeiten damit kein Problem mehr.

    Reply
  11. Ich wechsle meine IDE wie Unterwäsche.
    Momentan ist NetBeans dran, da sie es als erste geschafft haben sinnvolle CodeCompletition für PHP5.3 anzubieten, Refactoring geht gut, nur der Code-Formatter will noch nicht wie ich will.

    ZendStudio war vorher dran, hab lange damit gearbeitet, weils eben die einzige ist die alles abdeckt was ich so brauche (SVN, UnitTest, Refactoring, PHP5.3) nur das Teil wird von Version zu Version buggier und langsam.. 🙁

    Zwischendurch spiel ich immer mit den „kleineren“ wie PHPEd und PHPEdit herum, bin aber meistens nur am gucken.

    Bin mit NetBeans momentan sehr zufrieden, und der Umstieg war gar nicht soo gravierend, wenn man das ShortCut-Schema auf Eclipse umstellt 🙂

    Ich schreibe die IDE eigentlich nicht vor, aber es hat durchaus Vorteile (Code-Templates, Formatter-Schemes teilen, usw).

    Reply
  12. Ich glaube wir sind uns alle einig, dass Notepad++, VIM oder Emacs nur Texteditoren und keine IDEs sind. Bei den IDEs hat bisher auch noch keiner PHPEclipse und Aptana genannt. Na ja, nicht so wichig.

    Ich bin ziemlich gespalten ob man in einem Team die gleiche IDE nutzen sollte.

    Vorteile:
    – großer Wissenspool / Spezialisierung für die IDE
    – transparenter Austausch / Erfahrung / Einrichtung der IDE (eine Einrichtungs-Doku des Systems, nicht 4)

    Nachteile:
    – Fokusierung auf eine IDE
    – Einschränkung der Vorlieben des Programmiers –> unproduktiver während der Wechselzeit

    Ich glaube grundsätzlich würde ich umso mehr auf die gleiche IDE pochen umso größer das Team / Projekt ist, dann aber ohne Ausnahme. Bei kleineren Projekten, vor allem wenn Sie nebenher laufen, wohl eher nicht.

    Im Großen und Ganzen muss man aber auch feststellen, dass die Unterschiede zwischen den unterschiedlichen IDEs nicht so riesig sind. Selbst bei der gleichen IDE kann man ja durch die PlugIn- und Personalisierungs-Möglichkeiten sehr verschiedene Oberflächen erreichen.

    Viele Grüße
    Ulf

    Reply
  13. Ich finde eine Standardisierung innerhalb einer Firma ist ein richtiger Schritt. Wir haben hier alle auch dasselbe Linux Betriebssystem 😉 Einzig unser Entwickler, der auch Software für Mac OS X & iPhone / iPod touch programmiert nutzt eine andere IDE.

    Reply
  14. @Ulf PHPEclipse, Aptana sind genauso wie pdt eclipse Ableger. Der Grundaufbau wird also schon sehr ähnlich bis gleich sein.

    Was mich nur stört an der Sache: Ich könnte verstehen, wenn jeder in der jeweiligen Firma mit seiner ide genauso umgehen würde wie mit einem vim oder einem emacs (also ausreizen was die shortcuts so hergeben) Dann hat es durchaus seine Berechtigung, aber in den meisten Firmen wird es wohl nicht der Fall sein. Und wenn die einzigen shortcuts die genutzt werden strg x|c|v|s sind, dann macht es keinen Sinn eine IDE festzulegen.

    Reply
  15. @Maren: Es geht deutlich weiter als nur die effiziente Nutzung der IDE. Gesetzt dem Fall, ich binde ein SVN in Projekt ein, dann gibt es einen ganzen Sack voll Fehlerquellen, die bei der Einbindung von SVN und der Verwendung möglich sind. Nun hat ein Entwickler des Teams Netbeans und alle anderen den Firmenstandard eclipse. Bei IT-Support wird der eine Entwickler kein Glück haben und wird also seine Zeit damit verbringen, den Fehler im Netz zu recherchieren. Effektiv ist das dann auch nicht.

    Reply
  16. Ich halte das Ganze auch für eine Typfrage. Wenn man Produktivität an Hand von Codequalität und Entwicklungszeit verschiedener Features zu messen versucht, kann ich durchaus behaupten den IDE-Usern nicht gerade hinterherzulaufen 😉

    Klar kann man sagen „Das ist aber ne andere Zeit gewesen“ aber ich habe damals noch mit Notepad angefangen und der Code war nicht viel schlechter. Heute arbeite ich mit UltraEdit und habe Debugging, etc. alles integriert über Tools die sich einklinken lassen. Es wird also zur Halb-IDE, wenn man so will, weil einiges dann doch schon möglich ist, bleibt aber ein ultraschneller Editor der so wenig Performance braucht, dass rieseige Datenmengen in Sekunden bearbeitet werden können.

    Dazu kommt, dass ich behaupte über 95% aller Klassen und Methoden unserer (nicht gerade kleinen) Applikation blind zu kennen, weil ich dieses Wissen Stück für Stück aufgebaut habe. Und genau das kann meiner Meinung nach auch ein großer Vorteil sein, denn die IDE verrät mir vieles nicht, was ich nur mit dem Überblick und Wissen um meine Applikation kennen und einsetzen kann. Leider habe ich dabei häufig den Eindruck dass viele, die mit IDEs arbeiten, einfach erwarten dass diese Dinger ihnen alles abnehmen und alles wissen, was sie sich aus Faulheit nicht mehr angucken. Mag ein Vorurteil sein, dass zum Teil auf wahren Begebenheiten beruht … aber das ist mein ganz persönlicher Eindruck.

    Ich streite nicht ab dass man sich, sollte man gezwungen werden, sicherlich irgendwie mit jedem Tool arrangieren kann. Dennoch bin ich davon überzeugt dass es die Entwicklung nicht nur „kurzfristig“ bremsen würde, da es nie 1 Tool ist, um das es geht. Die Entwicklungsumgebung die man sich zusammenbaut ist liebevoll bis ins Detail ineinander gesetzt und konfiguriert. Hunderte Tastenkombinationen für das Generieren von PHPdocs, Debugging, eingebundenen Tools und selbstgeschriebenen Scripten und und und … das kann man nicht in kurzer Zeit alles neu aufbauen und lernen – womöglich noch in einem Tool dass einem manches schwer bis unmöglich macht 😉

    Ich denke, wenn man nicht ein selbst programmiertes Plugin im Einsatz hat, was nur für 1 IDE funktioniert, sollte man jedem Entwickler die Wahl lassen. Es gibt Coding-Standards und zum Teil vordefinierte Prozessabläufe – aber mit welchem Werkzeug der Code entsteht – sollte jedem selbst überlassen sein.

    Reply
  17. Ja Okay Das Argument kann man gelten lassen.

    Aber dennoch, wenn dieser Fehler geklärt ist, wird er beim nächsten mal schnell(er) gelöst sein und die frage natürlich, wie oft tritt so ein Fehler auf (abgesehen davon das ich unter NB keine svn probs hab 😉 ).

    Ich hab z.B Plugins installiert die mich bei der Täglichen Arbeit unterstützen, die es aber in einer Eclipse nicht gibt, und auf die will ich wirklich nicht verzichten. Meine IDE kann zurzeit noch keinen Tee kochen, daran Arbeite ich aber ;o)

    Ich probiere regelmäßig verschiedene IDEs aus, um halt wirklich einen Überbilck zu haben. Natürlich hat Netbeans genauso Macken und Zicken, aber mit denen komme ich einfach besser klar als mit den Macken eines Eclipse Derivat. Ich ärgere mich schon genug über die Probleme die ich lösen muss, da möchte ich mich „weniger“ mit meiner IDE rumschlagen.

    Reply
  18. Ich hab noch keine PHP-IDE gefunden, mit der ich rundum zufrieden bin. Ausprobiert habe ich PDT, PHPEclipse und Netbeans, früher auch ein paar andere. Was der Eine hat, fehlt dem Anderen.

    Wenn es das ‚Photoshop für PHP-Entwicklung‘ gibt, kann man sich gerne über Standardisierung unterhalten.

    Reply
  19. Eine strikte Vorgabe der IDE macht in meinen Augen nur dann Sinn, wenn man eine ganz bestimmte Tool-Integration in die IDE braucht – z.B., wenn ein bestimmter externer Bugtracker direkt eingebunden werden soll, wenn ein direkt in die IDE integriertes Tool für Code Reviews genutzt werden soll oder ähnliches.

    Werden externe Tools ohnehin eigenständig ohne IDE-Integration genutzt, reicht es, wenn man einfach lose Vorgaben macht – z.B.: Deine IDE muß immer nativ in UTF-8 arbeiten, sie muß Tabs in 4 Spaces umwandeln können, etc. … solche Vorgaben halt, die gewährleisten, daß die Coding Styleguides erfüllt werden können und die Entwickler sich nicht gegenseitig die Formatierung zerschiessen.

    Wenn Du strikte IDE-Vorgaben machst, kann das bei Entwicklern fix zu Motivationsproblemen führen: Arbeitet jemand zu Hause mit seiner Lieblings-IDE, und kriegt er in der Firma einen Boliden vorgesetzt, bei dem erstmal alle Operationen 3 Mal länger dauern als gewohnt, ohne einen wesentlichen Mehrwert dafür zu generieren, ist Frust vorprogrammiert.

    Ich persönlich habe schon relativ viele IDEs durch und bin über die Jahre immer genau dann zum nächsten Produkt weitergehüpft, wenn entweder etwas rauskam, was radikal bessere Features hatte, oder vergleichbare Features bei wesentlich besserer Performance geboten hat. Mit anderen Worten: Ich gehe dahin, wo die Produktivität am höchsten ist. Das heißt nicht, daß ich sprunghaft zwischen Produkten umher hüpfe, ich überlege mir sowas schon gut – im Schnitt bleibe ich 2-3 Jahre beim gleichen Produkt.

    Eine Umgebung vor die Nase zu bekommen, bei der die Produktivität runtergeht, ist extrem frustrierend, weil man immer im Hinterkopf hat: „Ich könnte schon lange fertig sein…“. Klar, man kann sich irgendwo mit allem arrangieren. Sich arrangieren heißt aber nicht, daß man nicht anders besser arbeiten und motivierter sein könnte. Freie Auswahl kann somit sogar ein Mittel sein, um Entwickler langfristig zu motivieren und zu halten.

    Reply
  20. Die psychologischen Auswirkungen sollte man nicht unterschätzen. Ich musste gerade dienstlich meinen Mail Client von Opera M2 auf Outlook umstellen. Das ist so, als würde man von Eclipse PDT (was ich auch nutze) zu Microsoft Visual Studio wechseln.
    Ich möchte an dieser Stelle === kein === Windows Bashing anfangen (der Opera läuft auch unter Windows), aber neben der langsameren Abarbeitung meiner vielen Mails erhöht sich tagtäglich auch mein Frustpotential.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen