Ogni membro di una squadra dovrebbe utilizzare lo stesso IDE? [chiuso]

A patto che il sistema di build "ufficiale" (usato dai server di Continuous Build) sia lo stesso per tutti, non vedo alcun motivo per cui ogni membro del team non possa scegliere gli strumenti che vuole ...

Se il tuo team si basa su determinati plugin disponibili solo per determinati IDE, allora ha senso unificare tutti sotto la stessa piattaforma di sviluppo. Trovo anche più facile aiutare qualcuno con un problema di sviluppo se hanno lo stesso IDE come me, mentre se devo leggere lo schermo di qualcuno con un'interfaccia non familiare ci vorrà un po 'di più.

Uno svantaggio è che quando si accoppia non è possibile scambiare la tastiera tra di voi come fluente. Tra gli IDE mainstream questo probabilmente non è un grosso problema, ma se una persona è abituata a Eclipse mentre l'altra è abituata a Vim, ci sarà una discrepanza. L'utente di Eclipse potrebbe non essere completamente in grado di utilizzare vim, mentre l'utente vim (che sono io;) passa un sacco di tempo a maledire sottovoce l'orribile lentezza dell'utilizzo di vaniglia Eclipse.

Detto questo, preferirei ancora molto usare io stesso. Se la tua coppia è felice con uno solo di te che "guida" per lunghi periodi, funziona OK.

E so che ci sono dei plugin per far funzionare Eclipse come vi, ma sto parlando di unire dove vado e di sedere con qualcuno che fa funzionare Eclipse come gli piace, quindi non installeranno quel plugin.

Non avrebbe alcun senso forzare tutti gli sviluppatori del kernel di Linux a usare lo stesso IDE (o usare qualsiasi IDE).

Non ho esperienza con IDE misti, a meno che non contiate un IDE commerciale con integrazione occasionale di un editor di testo "IDE multipli", ma posso pensare a un paio di pro e contro.

Pro

• Ogni sviluppatore può essere più produttivo con ciò che conosce meglio
• Alcuni IDE possono offrire un vantaggio rispetto ad altri (uno potrebbe essere più bravo nel refactoring, un altro potrebbe essere migliore nel fornire aiuti per la codifica, altri potrebbero essere migliori con l'integrazione dei dati, qualunque cosa sia). L'utilizzo di una fusione potrebbe consentire al tuo team di capitalizzare su quello.
• Avrai un po 'di protezione contro la possibilità che uno degli IDE rimanga defunto.

Contro

• Problemi di licenza. Se ci sono più IDE commerciali coinvolti, forse è più costoso. Per lo meno, potrebbe essere più di tenere traccia di.
• Problemi di licenza 2. Se ci sono framework o plug-in che sono concessi in licenza da IDE o langauge, questo sarà un problema?
• Come accennato da Dszordan, alcuni plug-in potrebbero non essere compatibili con i diversi IDE.
• Se gli IDE hanno componenti di generazione del codice o motori di formattazione dello stile che fanno le cose diversamente, ciò potrebbe causare confusione.

C'è un motivo per cui questo può essere forzato. Basta considerare Visual Studio ed Emacs / Vim. Come su Windows Visual Studio aggiungerà un \ r alla fine della linea. Questo fa casino con il display in emacs / vim. Anche le schede creano problemi. Il problema con noi è che noi sviluppatori lavoriamo su Linux, ma la nostra architettura software è comoda nello studio visivo. Una volta ci maledice dicendo che non formattiamo il file correttamente. Ma poi, quando ha scoperto che questo è dovuto al problema delle impostazioni predefinite, abbiamo accettato tutti lo stesso formato.
Se qualcuno mi obbliga a usare un particolare IDE, non mi sentirò male. Qualunque cosa sia buona per la squadra, la rispetterò e comprometterò di conseguenza.

Lo sviluppatore di oggi desidera scegliere i propri strumenti.

Questo però è cambiato nel tempo. 10 o 15 anni fa non c'erano tante scelte nei posti in cui ho lavorato. (sì, c'erano molti editori ma non erano una "scelta"). Il negozio in cui ho lavorato 15 anni fa era molto "old school" (anche allora!) E vi era l'editor. Nessuna scelta. Questo è stato davvero piuttosto utile, perché dopo il primo mese di imprecazioni e parolacce mi è piaciuto molto.

Oggi ci sono molte scelte e ognuno ha molti vantaggi.

Nella mia esperienza personale ho utilizzato un IDE - rubyMine - per un paio d'anni prima di passare da "indietro" a vi (m). L'ho fatto perché Ruby è un linguaggio molto difficile per scrivere un IDE (digitazione anatra e altre caratteristiche dinamiche) e di conseguenza gli IDE tendono a essere lenti e / o richiedono l'ultima macchina più veloce.

Ebbene sì, ho un po 'di esperienza per quanto riguarda l'essere parte di mixed windows / unix & c ++ / team java. Penso che questo non sia un problema se tutti sono a proprio agio a lavorare con l'altro IDE o non ci sarà mai una situazione in cui qualcuno che non ha familiarità con IDE ha bisogno di lavorare con l'altro (è il ragazzo con IDE Y sistema).

Se tutti lo desiderano, va bene, ma persone diverse potrebbero voler utilizzare diversi editor / IDE. Non vorrei davvero che la gente mi costringesse a usare un editor diverso dal mio preferito se stavo lavorando a qualcosa di grosso con una squadra, e dubito che sia solo. Le persone potrebbero essere più contente della situazione se non le imponi di utilizzare un particolare editor.

BTW, Emacs!

Non penso che tutti debbano avere lo "stesso" IDE, ma sarebbe bello che tutti avessero un IDE "supportato".

Ad esempio, se l'IDE è integrato nel processo di revisione del codice per quanto riguarda il commento e l'aggiornamento del codice, allora avrebbe senso per tutti essere su una piattaforma supportata.

Se la tua azienda utilizza un ambiente collaborativo come Rational Team Concert e uno o due ragazzi vogliono usare un IDE non supportato (o una versione diversa) mentre tutti gli altri usano quelli compatibili, quindi la vita potrebbe essere difficile per le persone che hanno scelto di essere al di fuori del ciclo di supporto.

Al nostro posto costruiamo i nostri progetti usando Visual Studio. Quando si tratta di modificare il testo, passo ad Emacs. La tua azienda non dovrebbe preoccuparsi finché il lavoro è finito.

Sembra un po '"abbiamo usato questo al mio vecchio lavoro". Bene, non sono al loro vecchio lavoro.

Se non influisce sulla catena degli strumenti o sul plug-in di controllo sorgente, allora forse sì. Quindi, ancora una volta, i due nuovi abitanti possono dimostrare un chiaro vantaggio? Hanno usato il tuo IDE?

Altrimenti, non ho pazienza con queste sciocchezze a meno che non ci sia un buon caso per questo. Non sono al loro vecchio lavoro: non poteva essere così bello per loro voler andare via. Stavo usando l'altro IDE come unico punto di forza nel suo vecchio lavoro: se così fosse, dovrebbero essere STFU e essere grati ..

YES! Enforce singleton IDE.

Rende problemi quando la dipendenza dal progetto cambia. se si introduce una nuova dipendenza dal progetto, allora ognuno perderà tempo per introdurre quella nuova dipendenza, e alcuni potrebbero fallire e perdere tempo in quel processo. GRANDI SCARTI DI TEMPO.

ci dovrebbe essere una valida giustificazione per aggiungere un IDE diverso al team, il che significa che il tempo risparmiato dovrebbe superare il tempo dedicato alla migrazione del sistema verso IDE diversi