Ist eine Firmenbestellung, zu einer bestimmten IDE zu wechseln, eine rote Fahne? [geschlossen]

80

Ich bin kürzlich einem schnell wachsenden Startup beigetreten. In den letzten 3 Monaten ist das Entwicklerteam von 4 auf 12 gewachsen. Bis jetzt waren sie sehr laissez-fair darüber, was Entwickler früher für ihre Arbeit getan haben. Tatsächlich war eines der Dinge, die ich anfangs an dem Unternehmen attraktiv fand, dass die meisten Programmierer Linux verwendeten oder welches Betriebssystem sie für ihre Bemühungen am besten hielten.

Jetzt ist ohne Diskussion der Befehl gekommen, dass jeder zu Eclipse wechseln soll. Ein guter Redakteur. Ich bevorzuge SublimeText2, aber es ist nur mein persönlicher Geschmack.

Um ganz klar zu sein: Wir sind ein JS-Team, das Backbone verwendet, und Eclipse ist einfach nicht gut darin, Backbone-Code zu verstehen. Dies bedeutet, dass diejenigen im Team, die eine / good / IDE (PHP Storm) verwenden, wieder eine Menge Dinge tun müssen, die vor drei Schritten gesucht und gefunden wurden Anstatt nur Strg + Klicken und Vor- / Zurück-Taste zu verwenden - verringert sich wahrscheinlich die Produktivität um 15% und die Freude um 50% ...

Ist das eine rote Fahne? Es scheint launisch und unangemessen zu sein, Entwicklern (Nicht-MS) mitzuteilen, welche IDE oder Tool-Sets sie verwenden sollen, wenn sie bereits etabliert und produktiv sind.

Justin Alexander
quelle
7
Was ist Ihr Build-Prozess? Was muss vorhanden sein, damit die von Ihnen eingegebenen Zeichen als Binärcode für Kunden verwendet werden können?
22
Dies ist ein Start-up. Wenn das Management einseitig eine Entscheidung trifft, die sich auf die Entwicklung auswirkt, ohne darüber zu diskutieren, kann dies eine große rote Fahne sein, unabhängig davon, worum es geht.
Joshin4colours
29
Nein - es gibt unzählige Gründe, sich für eine einzelne IDE zu entscheiden: Lizenzierung, Prozess, Kontinuität, Konsistenz ...
Wonko the Sane
55
Ein wachsendes Unternehmen, das frühzeitig versucht, einen Standard zu etablieren, ist meines Erachtens ein kluges Unternehmen (egal was es ist)! Setzen Sie alle auf die gleiche Seite und erwerben Sie Fachkenntnisse mit einer gemeinsamen IDE. Dann wird das Team effizienter, da sich alle gegenseitig helfen und den Code einfacher teilen können, ohne sich um die Breite des Tabulators, die Codierung und ähnliche Dinge kümmern zu müssen.
Yanick Girouard
23
Eclipse ist eine ganze Umgebung, nicht nur ein Editor. Vielleicht stellte die IT fest, dass der Umgang mit jeder speziellen Schneeflocke in einem wachsenden Unternehmen zu einer großen und lästigen Aufgabe wurde und standardisieren wollte. Vielleicht gibt es ein Tool im Eclipse-Ökosystemmanagement, das Sie bald nutzen möchten. Möglicherweise haben 12 verschiedene Editoren für die automatische Formatierung Ihr Repository verärgert und zusätzliche Builds verursacht. Möglicherweise nicht lizenzierte Tools "von zu Hause" sorgen für das Management, die nicht verklagt werden wollen. Vielleicht sind Sie der Neue. Erwarten Sie wirklich, bei umfassenden IT- und Entwicklungsentscheidungen konsultiert zu werden? Könnte eine Million Gründe haben, völlig normal.
Patrick Hughes

Antworten:

92

"Jetzt sind Befehle ohne Diskussion gekommen, dass jeder zu Eclipse wechseln soll."

Ich denke, das ist die echte rote Fahne. Ihr Team ist der Experte für Softwareentwicklung und derjenige, der von der Entscheidung betroffen ist, und dennoch haben Sie in der Diskussion, die zu dieser Bestellung geführt hat, kein Wort verloren?

Es hört sich an, als würden spitze Chefs überhand nehmen. Hat die entscheidende Person / das entscheidende Team relevante Einsichten für diese Entscheidung?


Angesichts der Tatsache, dass die Entscheidungsträger für eine solche Entscheidung qualifiziert genug sind, hat die Abwesenheit der Meinung des Entwicklerteams mindestens zwei Nachteile:

  • Das Team fühlt sich nicht involviert. Die Einbeziehung des Teams sollte für das Management Priorität haben. Ich möchte nicht irgendwo als Entwickler arbeiten, wo meine Meinung zu zentralen Themen wie IDE nicht genug gewürdigt wird, um überhaupt gefragt zu werden. Zugegeben, dass es schlimmer sein kann, jemanden nach seiner Meinung zu fragen und sich dann dagegen zu entscheiden, aber in diesem Fall würde ich eine solide Begründung für diese Entscheidung erwarten.

  • Das Management, wie erfahren es auch sein mag, arbeitet nicht zu 100% mit der Entwicklung dieses spezifischen Codes. Angenommen, die Leute, die überhaupt keine interessanten Einsichten haben, wären naiv. Natürlich kann es sein, dass die Manager an alles gedacht haben, was die Entwickler sich ausgedacht haben, aber der einzige Weg, dies zu wissen, ist zu fragen.

Gauthier
quelle
9
Unsinn. Nur weil das Team nicht konsultiert wurde, heißt das noch lange nicht, dass die höheren Klassen keine Ahnung haben. Als Nicht-Java-Entwickler ist Eclipse interessant. Ich weiß, dass es die IDE ist, die man so gut wie verwenden kann, aber ich habe nie von dem Favoriten des OP gehört, bis er es veröffentlicht hat. Es wäre ein Fehler, dem Team zu erlauben, sich auf eine ungewöhnliche IDE zu standardisieren, was Probleme bei der Rekrutierung anderer neuer Entwickler verursacht.
Andy
5
Haben Sie in Betracht gezogen, dass das "obere Management" leitende Entwickler sein könnte? Einige Organisationen haben viele Schichten?
2
Sie lesen viel zu viel darüber. Das Management hat möglicherweise andere Bedenken, wie z. B. Supportoptionen, und es ist möglicherweise auf etwas zurückzuführen, das mit angemessenen Supportkosten recht beliebt war (ich spreche von bezahlten Supportvorfällen). Wenn dies der Fall ist, gab es möglicherweise keine andere Wahl. Wie wäre es also sinnvoll, die Entwickler zu fragen? Haben Sie auch schon versucht, eine kleine Anzahl (10-15) Entwickler dazu zu bringen, sich auf etwas zu einigen? Es gibt einen Grund, warum Entwickler dazu gebracht werden, sich zu einigen, als würden sie Katzen horten.
Andy
3
@Andy Katzen zu horten ist einfach (sprechen Sie mit jedem Spinner), sie zu hören ist eine ganz andere Sache. ; o)
JW01
3
@ JW01 Ahh, ich habe das falsche Wort verstanden. Aber würde es nicht Hüten sein? :-)
Andy
63

Wenn Sie an einem gemeinsamen Projekt arbeiten, ist es vernünftig, dass Sie auf jeder Workstation alle Tools zum Bearbeiten / Erstellen / Debuggen Ihrer Software zur Verfügung haben und dass die Kerntools für etwa 90% der Entwicklung jedem in bekannt sind Die Mannschaft. Dieses Ziel ist schwieriger zu erreichen, wenn Ihr Team wächst und jeder sein persönliches Lieblings-Toolset verwendet - je mehr Leute, desto mehr Meinungen. Und die administrative Arbeit wird auch einfacher, wenn Sie die Anzahl der Tools nicht mehr als nötig anwachsen lassen.

Wenn ein Entwickler darauf besteht, seinen persönlichen Lieblingseditor zu verwenden, kann dies in Ordnung sein, solange er sicherstellen kann, dass die Quelle im Haupteditor des Teams (in Ihrem Fall Eclipse) nicht anders aussieht oder sich anders verhält B muss die Quelle von Entwickler A bearbeiten, Entwickler B sollte nicht gezwungen sein, den persönlichen Lieblingseditor von A zu lernen, um die Quelle effektiv ändern zu können. Aber Vorsicht, wenn die beiden von Zeit zu Zeit vor dem gleichen Display zusammenarbeiten müssen (oder eine Paarprogrammierung durchführen müssen), ist es oft einfacher, wenn der ausgewählte Editor beiden bekannt ist.

Doc Brown
quelle
2
Erstens ist es selten, dass ein Entwickler Änderungen an einem anderen Computer vornehmen muss. Ich stimme "je mehr Menschen, desto mehr Meinungen" zu, aber das ist kein Problem, es sei denn, die Menschen versuchen, anderen Meinungen aufzuzwingen. Bezüglich der Quelle sollten alle Projekte einen automatischen Ein-Befehl-Erstellungsprozess haben. Solange das funktioniert und der Code Konventionen folgt, spielt es keine Rolle, welche IDE-Benutzer verwenden. Die meisten IDEs sind für einfache Dinge intuitiv (für komplexere Aufgaben haben sie jeweils ihre eigenen Vorteile), sodass die Paarprogrammierung kein Problem darstellt. Bei Fragen kann der Entwickler, der die IDE verwendet, antworten.
Matthew Flaschen
Wenn Sie beide die Sprache kennen, ist es kein Problem, sich einen anderen Editor anzusehen. Einige Syntax markiert ist anders und der Dateiname kann in einem anderen Ort sein, aber es gibt kein Problem , wenn Sie tatsächlich mit anderen Entwicklers Setup.
Izkata
30
Ich arbeite bei Google und in meinem speziellen Team verwendet eine Person Eclipse, während eine Person Intelligenz verwendet. Ich verwende Emacs mit bösem Modus, um Vim zu emulieren, und eine Person verwendet Vim selbst. Wir arbeiten gut miteinander und die Werkzeugunterschiede sind kein Problem. Es hilft zwar, dass wir alle dasselbe Build-System verwenden und eine festgelegte Stilrichtlinie zum Lesen von Code haben, aber das hat wenig mit der Editorauswahl für jeden einzelnen zu tun.
Jeremy Wall
@JeremyWall: Wie gesagt, es kann in Ordnung sein, wenn Ihr Quellcode in allen von Ihnen verwendeten Editoren gleich angezeigt wird und Sie nicht viel paarweise programmieren.
Doc Brown
5
@JeremyWall: Nur weil Ihr Entwicklerteam so arbeiten kann, heißt das nicht, dass alle Teams so arbeiten können. Tatsächlich würde ich ein Team von Google-Entwicklern als außerhalb der Norm liegend betrachten.
James P. Wright
25

Aus Gründen der Paarbildung ist es schön, wenn beide Teilnehmer vor dem Bildschirm die gleichen Fähigkeiten haben, wenn sie die Tastatur verwenden. Es ist auch gut zu wissen, dass Ihr Projekt, wenn es in der IDE spezielle Konfigurationsanforderungen gibt, für alle gleich konfiguriert ist. Es ist einfacher, einen neuen Entwickler zu finden, wenn die Tools für alle gleich sind.

Aber wenn man das damit vergleicht, nur zu versuchen, am effektivsten zu sein, dann ist es das nicht wirklich wert

Espen Schulstad
quelle
7
+1 für die Feststellung der Vorteile ähnlicher Entwicklungsumgebungen bei der Paarprogrammierung
Jcmeloni
1
+1. Ich konnte nicht mehr zustimmen. Die Arbeit mit mehreren Entwicklern, von denen jeder seine eigenen bevorzugten Tools und Codierungsmethoden hat, kann die Hölle sein! Möglicherweise möchten Sie beispielsweise Speicherplatz für Registerkarten, eine bestimmte Einrückungsgröße und UTF-8-Codierung für alle Ihre Quellen erzwingen. Ich musste das in meinem Team vorher durchgehen und wir mussten am Ende genau aus den oben genannten Gründen dafür sorgen, dass jeder die gleiche IDE verwendet. Jeder ernsthafte Entwickler würde sowieso nicht lange aufwenden müssen, um sich an eine neue IDE anzupassen, daher sehe ich keinen Schaden daran. Es erleichtert auch neuen Mitgliedern den Einstieg, wenn alle das gleiche Tool verwenden.
Yanick Girouard
@Yanick: Leerzeichen über Tabulatoren, Einrückungsgröße, Codierung ... Alle diese Parameter müssen im Codierungsstandard enthalten sein, den alle Entwickler einhalten müssen. Es ist egal, wie sie sich an sie halten wollen, oder? Die Formatierungsanforderungen sollten sich darauf konzentrieren, dass das Ergebnis korrekt ist und nicht darauf, wie Sie dorthin gelangen. Wenn die Entwickler die IDE wechseln müssen, um die richtige Formatierung zu erhalten, würde ich sie nicht als "ernsthafte Entwickler" bezeichnen. Tut mir leid, dass sie mutig sind.
Gauthier
18

Ja, es ist ein bisschen wie eine rote Fahne, dass sich das Management ein besseres Urteil darüber bildet, mit welchen Tools Sie effizienter arbeiten als mit Ihnen.

matt b
quelle
38
Hängt stark von den Gründen ab, warum die IDE gleich sein sollte.
3
Wir sind uns nicht sicher, wer die Entscheidung getroffen hat oder warum. Der Begriff "ohne Diskussion" könnte bedeuten, dass sie den neuen Mann nicht einschließen.
mhoran_psprep
3
Ich habe nicht den Repräsentanten, den ich ablehnen kann, aber ich stimme dieser Perspektive nicht zu. Auch wenn das vom Management beschlossen Werkzeug ist in der Tat nicht die besten, wäre es besser, als keine Standardisierung aufweist. Es ist klar, dass die Entwickler nicht in der Lage sind, die Entscheidung darüber zu treffen, was "am besten" ist, da sie alle auf ihre eigenen Geräte angewiesen sind und verschiedene Tools ausgewählt haben. Es ist sinnlos zu behaupten, dass verschiedene Tools in unterschiedlichen Kontexten besser funktionieren, da die meisten dieser Entwickler ohnehin nicht in sehr vielen Fällen fließend werden.
FumbleFingers
4
"Es ist klar, dass die Entwickler nicht in der Lage sind, die Entscheidung darüber zu treffen, welches" am besten "ist, da sie alle auf sich allein gestellt verschiedene Tools ausgewählt haben." Sie wählen das beste (produktivste) Tool für sich . Jeder hat unterschiedliche Erfahrungen und Arbeitsmuster. Sie können alle recht haben.
Matthew Flaschen
2
@Andy Das ist eigentlich nicht wahr, wie die Meinungsverschiedenheiten zwischen Vim und Emacs zeigen. Und das sind in erster Linie Texteditoren, keine vollständigen IDEs. Es kann dauern Jahre eine neue Umgebung zu bekommen bis zu beschleunigen in.
Izkata
14

Es ist keine rote Fahne für sich.

Manchmal muss das Management Entscheidungen treffen . Alle Probleme, bei denen eine Standardisierung erforderlich ist, fallen in diese Kategorie. Ich habe einmal bei einem Kunden gearbeitet, der ein paar Jahre lang zuließ, dass sich Standards ändern, und der über 20 verschiedene SCM-Tools verfügte. Was als unabhängige Entscheidung von verschiedenen Entwicklungsteams begann, wurde zu einem logistischen Albtraum, der den Austausch von Fähigkeiten und die Zusammenarbeit bei Code im gesamten Unternehmen erheblich beeinträchtigte. Integrierte Builds waren ..... ähm ..... nicht sehr integriert .....

Darüber hinaus ist es nicht praktisch oder notwendig, bei jeder Entscheidung alle zu konsultieren . Inwieweit dies getan werden muss, hängt von der Unternehmenskultur und der Wichtigkeit / Komplexität der Entscheidung ab. Normalerweise würden Sie eine dieser weniger beratungsintensiven Optionen wählen:

  1. Treffen Sie die Entscheidung selbst, wenn Sie über ausreichende Kenntnisse der Vor- und Nachteile verfügen und diese Entscheidung nicht wichtig genug ist, um eine umfassende Beratung zu erfordern.
  2. Wenden Sie sich an einige Schlüsselpersonen (die wahrscheinlich die erfahrensten Entwickler sind, die für die Entscheidung am besten geeignet sind).
  3. Machen Sie alle Betroffenen darauf aufmerksam, dass Sie eine Entscheidung treffen (E-Mail, Rathaussitzung, Teambesprechungen). Sagen Sie, was Sie für die richtige Entscheidung halten, aber dass Sie bereit sind, dies zu ändern, wenn neue Beweise im Gegenteil auftauchen. Bitten Sie die Teilnehmer, sich einzeln zu äußern, wenn sie wichtige Ansichten haben
  4. Bitten Sie die Mitarbeiter, ein Unterteam zu bilden, um die Optionen zu prüfen und eine Entscheidung zu empfehlen. Gute Option, wenn es sich wirklich um einen engen Anruf handelt, Sie die Antwort nicht kennen und möchten, dass die Beteiligten in die Entscheidung einbezogen werden.

Für so etwas wie Developer Tooling (was ein potenziell umstrittenes Problem ist) würde ich wahrscheinlich 2 gefolgt von 3 oder 4 machen. Dh es würde definitiv einige Personen geben, mit denen ich nicht persönlich über das Problem sprechen würde, aber auf der anderen Seite die meisten von den Schlüsselpersonen würden eine Wahrscheinlichkeit erhalten, zur Entscheidungsfindung beizutragen.

Für mich wäre die echte rote Fahne da, wenn Sie das Gefühl hätten, dass eine falsche Entscheidung getroffen wurde (falsch == es schadet dem Unternehmen und nicht nur Ihrem Lieblingswerkzeug, das nicht ausgewählt wurde). Wie reagiert das Management, wenn Sie dieses Problem ansprechen:

  • Gutes Management wird auf Ihre Argumentation hören, sich aufrichtig für das Feedback bedanken und ihre Position überdenken, falls Sie neue Erkenntnisse gewonnen haben . Sie stimmen möglicherweise immer noch nicht mit Ihnen überein und halten möglicherweise an ihrer Entscheidung fest, aber sie werden es zu schätzen wissen, dass Sie sie angesprochen haben, und Sie die Höflichkeit haben zu sagen, warum sie an ihrer Entscheidung festhalten. Sie könnten in Zukunft sogar die Art und Weise ändern, in der sie solche Entscheidungen treffen, und wenn Sie gute Argumente vorgebracht haben, könnten Sie auf ihre Liste der "klugen Leute" gesetzt werden.
  • Schlechtes Management wird defensiv, sagt, dass "die Entscheidung getroffen wird" und andere solche Taktiken, um zu vermeiden, dass sie sich der Tatsache stellen, dass sie möglicherweise eine falsche Entscheidung getroffen haben. Sie können Sie als "Unruhestifter" sehen. Das Unternehmen leidet ebenso wie Ihr Vertrauen in das Management. Das ist eine echte rote Fahne! Geh raus, solange du kannst!
mikera
quelle
6
Es gibt einen ziemlich großen Unterschied zu einem ide / editor und einem scm- oder build-System. und ide / editor ist für den persönlichen Gebrauch und in der Regel auf den Einzelnen zugeschnitten. Das SCM- oder Build-System wird weltweit von jedem verwendet. Eines dieser Dinge muss zentral verwaltet werden, das andere auf keinen Fall.
Jeremy Wall
2
Meine Antwort bezog sich eher auf die Managementfragen als auf die spezifische Entscheidung über IDEs an sich. Es gibt jedoch auch viele gute Gründe, sich auf eine IDE zu standardisieren (z. B. Kenntnisse, Schulung, Lizenzkosten, Effizienz der Paarprogrammierung, Integration mit anderen Tools, Gesamtqualität der IDE, Supportkosten, einfache Bereitstellung). In einigen Zusammenhängen ist die richtige Entscheidung die Standardisierung - Sie sind falsch, wenn Sie der Meinung sind, dass dies immer der individuellen Wahl überlassen bleiben kann (auch wenn dies in vielen Situationen die richtige Entscheidung ist)
mikera
2
@ Jeremy: Ich denke, deine Perspektive ist perfekt für eine Ein-Mann-Band oder eine kleine Gruppe von Hackern. Ich habe großes Mitgefühl: Ich bin für meine persönlichen Projekte genau das Gleiche. Dieser Ansatz lässt sich jedoch nicht auf größere Unternehmenskontexte übertragen. Eine Vorliebe für Tools ist in Ordnung, aber ich erwarte, dass ein guter professioneller Entwickler bereit und in der Lage ist, die Tools zu erlernen und anzuwenden, die die Organisation insgesamt am effektivsten machen.
Mikera
3
Meine Sichtweise wird von meinem Arbeitgeber Google geteilt, der sich mit Sicherheit als größerer Unternehmenskontext qualifiziert. Ich stimme zu, dass ein guter professioneller Entwickler bereit sein sollte, Tools zu erlernen und anzuwenden, um die Organisation insgesamt am effektivsten zu machen. Ich bin nicht einverstanden, dass eine Idee oder ein Herausgeber jemals in diese Kategorie fallen könnte.
Jeremy Wall
2
Coole, großartige Firma, und Sie haben das Glück, an einem Ort zu arbeiten, an dem viele "kleine Gruppen von Hackern" an relativ unabhängigen Projekten arbeiten können. Die meisten großen Unternehmen haben diesen Luxus leider nicht. Stellen Sie sich eine große Bank vor, die 100 Java-Einsteiger in Indien einstellen und schulen muss, um an der Wartung von Callcenter-Apps zu arbeiten. Sie alle dazu zu ermutigen, kreativ zu sein und ihren eigenen IDE- / Build-Workflow zu wählen, wird einfach nicht funktionieren.
Mikera
12

Wenn Sie Maven oder ähnliches verwenden, sollte es keine Rolle spielen, welche IDE Sie verwenden. Es kann Fälle geben, in denen man an eine bestimmte IDE wie Eclipse gebunden ist, wenn es Plugins gibt, auf die Sie sich verlassen können.

Ich denke, Sie sollten in der Lage sein, Ihre eigene IDE zu wählen, die IDE, in der Sie am produktivsten sind. Wie ich jedoch bereits sagte, gibt es Fälle, in denen es sinnvoll ist, eine Standard-IDE zu verwenden.

Jarle Hansen
quelle
z.B. Wenn Sie ADF ausführen möchten, ist JDeveloper die natürliche Wahl. Plugins für andere IDs verfügen möglicherweise nicht über alle Funktionen.
Rohit Banga
11

Ich hätte die "Corporate Mandated" -ID installiert, würde aber trotzdem den größten Teil meiner Arbeit in der von mir gewünschten IDE erledigen - es ist nicht so, als könnte jemand sagen, mit welcher IDE eine Quelldatei bearbeitet wurde.

Auf der IDE vs. Editor Front ... für fast alle Sprachen, ich stark ein IDE (IntelliJ) bevorzugen , weil es einfach so viel mehr ist es für Sie als Redakteur kann tun können. Es gibt einige Dinge, für die ich auf ST2 oder Emacs zurückgreife, aber für die tägliche Codierung gewinnt die IDE fast immer, obwohl ich beide ST2 / Emacs mag.

Dave Newton
quelle
1
Ich bestreite Ihre Behauptung, dass eine IDE wesentlich mehr kann als ein Editor. Es gibt deutlich schlechtere Editoren, z. B. würden Sie mit nano oder gedit keine ernsthaften Entwicklungen durchführen, aber ich kann in vim schneller programmieren als ich und ich denke, die meisten anderen können dies in einer IDE. Und obwohl ich es hasse, Emacs zu verteidigen, bin ich mir sicher, dass ein erfahrener Emacs-Benutzer in Emacs auch schneller ist als in einer IDE.
Kevin
1
@ Kevin Dispute away - Ich bin ein langjähriger Emacs-Benutzer, der mit ST2 besser wird, und es gibt einfach keinen Vergleich. Bessere, kontextsensitivere Vervollständigung, engere Debugging-Integration. Es gibt nicht allzu viele Dinge, für die ich einem Texteditor zustimmen würde. Einige Sprachen sind besser als andere, zum Beispiel würde ich Java in Emacs so gut wie gar nicht codieren, für Ruby und Python bin ich ungefähr halb und halb, aber IntelliJ überzeugt mich. Für die eigentliche Textbearbeitung benutze ich einen Editor, egal ob es sich um Code handelt oder nicht.
Dave Newton
1
Ich weiß, dass die Frage und die meisten Antworten auf die Java-Welt ausgerichtet sind, aber hier in der .NET-Welt von Microsoft ist die Vorstellung, dass ein Editor besser sein könnte als die Mainstream-IDE (Visual Studio), absolut zurückgeblieben. Ich würde keinen .NET-Entwickler einstellen, der darauf bestand, Notepad ++ über Visual Studio zu verwenden.
Graham
11

Jedes Team, in dem ich jemals war, hatte eine Vielzahl von IDEs und Editoren: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - das war noch nie ein Problem. Noch nie.

Für mich spricht dies für ein Missverständnis auf hoher Ebene der Organisation, was wirklich wichtig ist. Was zählt, ist, gute Programmierer tun zu lassen, was sie tun müssen, und die Werkzeuge zu verwenden, die sie am bequemsten machen. Die Einheitlichkeit der IDE hat sehr wenig mit der tatsächlichen Kommunikation zu tun, die über die wesentlichen Fragen der Objektarchitektur, der Komponententests, der Algorithmen usw. stattfindet.

Dieselbe IDE wie der nächste zu haben, bedeutet nur, dass wir beide wissen, wie man den Code mit denselben Verknüpfungen durchsucht und wie unsere Kompilierung / Konfiguration eingerichtet ist. Nichts davon wird von Bedeutung sein, wenn es um echte Code-Probleme geht.

Schauen Sie, es ist lebenswert, abhängig von anderen Faktoren im Unternehmen. Sie können für alltägliche Aufgaben immer Ihren eigenen bevorzugten Editor verwenden. Und vielleicht macht Ihre Gruppe andere großartige Dinge, die eine großartige Kultur schaffen. Aber mandatierte IDEs sind ein großer Fehltritt der IMO. Für mich, wenn ich mit einem Unternehmen wurde interviewt und sie teilte mir mit, welches IDE wurde ich erlaubt zu bedienen, ich sie höflich für ihre Zeit danken würde.

Dave Sims
quelle
8

In unserem Ruby-Shop gibt es eine starke Empfehlung, die IDE zu verwenden, die das meiste des Teams mag (RubyMine), weil wir wissen, dass es die Arbeit macht und wir uns gegenseitig Abkürzungen beibringen können usw.

Entwicklern steht es frei, eine andere IDE zu verwenden, aber wir fordern von ihnen solide Kenntnisse in diesem Editor, falls sie dies wünschen. Wenn wir jemanden sehen, der Schwierigkeiten hat, in seinem Projekt zu navigieren oder Text in seinem benutzerdefinierten FooEdit zu bearbeiten, ist es RubyMine.

triskweline
quelle
4

Wenn ein Programmierer ein Experte für eine bestimmte IDE ist, sollte er diese verwenden. Wenn sie keine IDE-Experten sind, gibt es wahrscheinlich einen oder zwei, die in Ihrer Programmiersprache oder in Ihrem Team sehr häufig vorkommen, und es ist wahrscheinlich sinnvoll, dass sie dies lernen.

Auf einer IDE standardisieren zu müssen, klingt nach einer schrecklichen Idee.

Matt Rogish
quelle
2

Die Gründe für ein Unternehmen, einen bestimmten Editor oder eine bestimmte Software generell seinen Entwicklern aufzuzwingen, sollten untersucht werden. Der paranoide (vielleicht nicht das Wort, nach dem ich suche) Teil von mir glaubt, dass es eine Art Produktivitäts-Tracking geben könnte, das zu der Sonnenfinsternis hinzugefügt wird, die Entwickler installieren sollen. Ein viel weniger paranoider Gedanke wäre, dass sie Zeit damit verbracht haben, dieser IDE Produktbuilding-Tools hinzuzufügen, die die Dinge viel einfacher machen würden, wenn jeder die gleiche Taste zum Testen und Erstellen seines Code-Zweigs drücken würde.

Was ich damit sagen will, ist wahrscheinlich mehr als bloße Bürokratie oder eine Methode, mit den Entwicklerköpfen herumzuspielen.

Pykler
quelle
2

Dies ist eine massive rote Fahne. Jedes Unternehmen hat ein paar solche dummen Ideen, aber wenn andere rote Fahnen kommen, gehen Sie einfach.

taw
quelle
Nicht zustimmen. Viele große Unternehmen treffen Entscheidungen schnell, und wenn sie einen Fehler machen, hören Sie auf Feedback und wiederholen es. Sie verlieren keine Zeit damit, sich bei jeder Entscheidung in endlosen Konsultationen festzumachen.
mikera
2

Es ist leicht, die Motivation hinter einigen Entscheidungen zu verlieren - insbesondere bei einem schnell wachsenden Team. Die Motivation für den Umstieg auf Eclipse ist möglicherweise die Tatsache, dass die meisten Entwickler anscheinend viel Zeit mit der Konfiguration der IDE verschwenden und dass nur begrenztes Fachwissen in Ihrem Unternehmen vorhanden ist.

Ich würde einfach den Befehl annehmen, zu Eclipse zu wechseln, um zu bedeuten, dass Sie Eclipse einrichten sollten, falls dies erforderlich ist, aber Ihre Arbeit in Ihrem bevorzugten Editor fortsetzen. (Möglicherweise müssen Sie schrittweise zu Eclipse wechseln, wenn Ihr Unternehmen mit der Bereitstellung cooler Tools in Eclipse beginnt.)

Rote Fahne: Ich würde warten, wenn es noch ein paar solche irrationalen Befehle gibt, bevor ich mir Sorgen mache.

Vineet
quelle
1

Ein Startup versucht im Allgemeinen, lange genug agil zu bleiben, um ein nachhaltiges Geschäftsmodell zu finden. Sobald der Geldanteil ermittelt ist, zieht das Management ein, um das Geschäft zu vergrößern. In der Regel treten alle frühen Tech-Mitarbeiter aus dem Unternehmen aus, da die Engineering-Prozesse verschärft werden.

Wie Sie wissen, wissen Sie nicht, was Code tatsächlich tut, bis Sie ihn ausführen. Turing hat das in den Anfängen des Rechnens bewiesen. Dies bedeutet, dass es beim Schreiben von Software kein aussagekräftiges Maß für die Produktivität gibt. Damit das Management seine Arbeit erledigen kann, muss die Produktivität lesbar sein. Da Sie den Code nicht messen können (und die Benutzer beispielsweise Codezeilen ausprobiert haben), messen sie, was sie sehen können. Programmierer sind besser lesbar als die von ihnen entwickelte Software. Das typische Managementteam versucht, Programmierer zu kontrollieren, um diese Dinge für sie lesbar zu machen (anstatt ihre eigentlichen Aufgaben zu erledigen: aus dem Weg zu gehen). Und weil sie die falschen Dinge messen, funktioniert es nicht sehr gut.

Trotzdem kann man mit einem locker gekoppelten Team noch einen weiten Weg gehen. Das Entwicklungsteam von Github besteht aus rund 50 Mitarbeitern, die alle Regeln der betriebswirtschaftlichen Lehrbücher brechen. Ihnen scheint es gut zu gehen. Bugs werden (irgendwann) behoben. Features werden hinzugefügt. Feuer werden gelöscht.

Was ist eine große rote Fahne ist, wenn sie versuchen, die Dinge zu vergrößern, ohne herausgefunden zu haben, wie man Geld verdient. Zu diesem Zeitpunkt mussten Sie sich fragen, wie viel Ihre nicht erworbenen Optionen und Zuschüsse wirklich wert sind.

Ho-Sheng Hsiao
quelle
Dies scheint völlig unabhängig von der Frage zu sein. Meinten Sie woanders posten?
Daenyth
@ Daenyth Ich meine, dies hier zu posten. Die ursprüngliche Überschrift "Eine IDE, um alle zu regieren?" hatte nichts mit dem erklärenden Absatz zu tun. Das OP scheint zu fragen, ob die Notwendigkeit, eine IDE zu verwenden, Zeit für eine Sicherheitsleistung des Unternehmens bedeutet.
Ho-Sheng Hsiao
1

Sicher ist das eine schlechte Idee. Es ist unvermeidlich, dass das Team weniger produktiv wird, da es lernen muss, mit neuen Werkzeugen umzugehen. Und selbst dann werden sie nicht so effektiv sein wie mit den Werkzeugen, die sie bereits haben .

Da ich verschiedene Tools selbst ausprobiert habe, hatte ich immer das Gefühl, dass dieser Editor mich nervt mit <Fehler / Unterschied zum bevorzugten Tool einfügen>. Es wird also auch ein moralischer Nachteil sein.

Aber es gibt natürlich auch Profis, die ein ganzes Team die gleichen Werkzeuge benutzen lassen. Teilen von Configs, Skripten, Plugins und all diesen Dingen. Was mit einer Vielzahl von Toolsets nicht möglich wäre.

Andererseits ... wäre das letzte Stück nicht nötig, wenn jeder seine bevorzugte Software verwenden würde. ;)

noxoc
quelle
0

Sie können Eclipse "verwenden", während Sie noch SublimeText2 eingeben.

Dies bedeutet, dass Sie Eclipse für Ihre Projekte installiert und konfiguriert haben und sich auf dem Laufenden halten, damit Sie es auch bei der Paarprogrammierung verwenden können. Niemand wird (oder sollte) sich darum kümmern, welchen Editor Sie tatsächlich verwendet haben, um einen Code einzugeben, den Sie festgeschrieben haben, solange die parallele Einrichtung nicht übermäßig viel Zeit in Anspruch nimmt und Sie sich nicht vom Code abkoppeln Standard-Entwicklungsumgebung.

Tiberiu Ana
quelle
0

Wenn Sie Git verwenden und Ihre Verzweigung unterbrochen ist, sollten Sie ohnehin nicht die Editoren des anderen verwenden müssen. Sie können einfach auf einen Zweig drücken und ihn von einem anderen Entwickler ziehen lassen, um ihn zum Laufen zu bringen, wenn er Ihr Toolset wirklich nicht herausfinden kann. Jeden dazu zu zwingen, denselben Editor zu verwenden, klingt nach einer Anweisung eines Geschäftsführers, der schlau aussehen möchte, aber nicht wirklich versteht, wie ihr arbeitet.

tubbo
quelle
0

Wenn Sie aus Managementsicht darüber nachdenken, liegt der Grund möglicherweise in der Einhaltung der gesetzlichen Bestimmungen. Das Unternehmen ist dafür verantwortlich, dass jedes verwendete Werkzeug legal verwendet wird und das zu entwickelnde Produkt nicht belastet. (Einige Editoren sind frei für den persönlichen Gebrauch, aber nicht frei für andere Zwecke usw.) Die Prüfung aller Tools, die jeder Entwickler verwenden möchte, kann teuer werden. Ich habe gesehen, dass bei Projekten mit engen Zeitplänen das Management vorsichtig sein wird, welche Tools / Bibliotheken / usw. verwendet werden, um Änderungen im späteren Verlauf des Projekts zu minimieren, die von den Angehörigen der Rechtsberufe gesteuert werden.

Bei Projekten mit höherer Sicherheit geht es auch darum, wo die IDEs temporäre Dateien speichern und welche Informationen zwischen Sitzungen gespeichert werden.

SammyO
quelle
0

Es hängt alles von den Gründen ab, aus denen sie Eclipse empfehlen müssen. Wenn Entwickler Probleme haben, ihre Umgebungen einzurichten, weil jeder die Dinge anders organisiert, kann es einen Grund geben, eine Zwangsjacke zu empfehlen. Wenn jedoch alle glücklich und produktiv waren, was immer sie wollten, gibt es kaum einen Grund, etwas zu ändern, das so tief in den kreativen Prozess involviert ist.

Eclipse ist viel mehr als ein Editor - Sie können Ihren bevorzugten Editor für die Bearbeitung Ihres Codes verwenden und sich bei der Quellcodeverwaltung, dem Debugging und allen anderen Aufgaben, für die der von Unternehmen vorgegebene Workflow verwendet werden soll, auf Eclipse verlassen.

Eine letzte Sache - die Durchsetzung des Prozesses auf dieser Ebene könnte darauf hindeuten, dass das Unternehmen beabsichtigt, das Entwicklungsteam zu erweitern, und eine gewisse Struktur wünscht, damit neue Teammitglieder schneller produktiv werden können. Wenn Sie Rails (oder Django) als ein "eigenwilliges" Framework betrachten, werden Sie feststellen, dass eine Struktur das Verständnis neuer Anwendungen erleichtert.

rbanffy
quelle
0

Die rote Fahne ist nicht so sehr, dass jedem Entwickler ein einziger IDE / Editor aufgezwungen wird, sondern dass diese Entscheidung und insbesondere die Entscheidung, welcher IDE / Editor verwendet werden soll, nicht von allen Entwicklern getroffen wurde, und vielleicht auch nicht von allen Sie!?!

Mit Sicherheit wäre es für die Entwickler am besten, einen Konsens zu erzielen, zumal sie offensichtlich für die Entscheidung am besten qualifiziert sind (zumindest für welchen Editor / welche IDE). Es mag gute Gründe für eine Anpassung geben, und diese Entscheidung sollte die Präferenz des Managements einschränken, aber welcher Editor / welche IDE die Entscheidung aller Entwickler gewesen sein sollte.

Es wäre einfach, 12 Entwickler zur Stimmabgabe zu bewegen. Sicher war genug Zeit dafür! Die Schlussfolgerung wäre für einige ohnehin schmerzhaft gewesen und hätte am Ende sogar zu Eclipse geführt, aber die Kennzeichnung der Anforderung als "rote Fahne" wäre in diesem Fall viel fragwürdiger.

Ghbarratt
quelle