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

Pensi che abbia senso imporre che ogni membro di una squadra debba usare lo stesso IDE?

Ad esempio, tutti gli ingegneri che fanno già parte del team usano IDE X. Due nuovi ingegneri vengono e vogliono invece utilizzare IDE Y perché è quello che usano da diversi anni.

Hai qualche esperienza con i team "IDE misti"? Se è così, che cosa è?

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

Se il tuo team si affida a determinati plug-in disponibili solo per determinati IDE, ha senso unificare tutti nella stessa piattaforma di sviluppo. Trovo anche più facile aiutare qualcuno con un problema di sviluppo se hanno lo stesso IDE di me, mentre se devo leggere lo schermo di qualcuno con un'interfaccia sconosciuta ci vorrà un po 'più di tempo.

Uno svantaggio è che durante l'associazione non è possibile scambiare la tastiera tra di voi in modo fluido. Tra gli IDE tradizionali questo non è probabilmente un grosso problema, ma se una persona viene utilizzata per Eclipse mentre l'altra viene utilizzata per vim, ci sarà una discrepanza. L'utente di Eclipse potrebbe non essere del tutto in grado di usare vim, mentre l'utente di vim (sono io;) trascorre molto tempo imprecando sottovoce per l'orrenda lentezza dell'uso di Eclipse alla vaniglia.

Detto questo, preferirei di gran lunga usare me stesso. A condizione che la tua coppia sia contenta di uno solo di voi "alla guida" per lunghi periodi, funziona bene.

E so che ci sono plugin per far funzionare Eclipse come vi, ma sto parlando dell'abbinamento dove vado a sedermi con qualcuno che ha Eclipse che funziona come piace a loro, quindi non installeranno quel plugin.

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

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

Professionisti

• Ogni sviluppatore può essere più produttivo con ciò che sa meglio
• Alcuni IDE possono fornire un vantaggio rispetto ad altri (uno potrebbe essere migliore nel refactoring, un altro potrebbe essere migliore nel fornire aiuti alla codifica, altri potrebbero essere migliori con l'integrazione dei dati, qualunque cosa). L'uso di una miscela potrebbe consentire al tuo team di capitalizzare su questo.
• Avrai un po 'di copertura contro la possibilità che uno degli IDE vada in fallimento.

Contro

• Problemi di licenza. Se sono coinvolti più IDE commerciali, forse è più costoso. Almeno, potrebbe essere più di cui tenere traccia.
• 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 dispongono di componenti di generazione del codice o motori di formattazione dello stile che fanno le cose in modo diverso, 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 extra alla fine della riga. Questo rovina 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 in Visual Studio. Una volta ci maledice dicendo che non formattiamo correttamente il file. Ma poi quando ha scoperto che ciò è dovuto al problema delle impostazioni predefinite, abbiamo tutti accettato lo stesso formato.
Se qualcuno mi costringe a usare un particolare IDE, non mi sentirò male. Qualunque cosa sia buona per la squadra, la rispetterò e la comprometterò di conseguenza.

Lo sviluppatore di oggi vuole scegliere i propri strumenti.

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

Oggi ci sono molte scelte e ognuna ha molti vantaggi.

Nella mia esperienza personale ho usato un IDE - rubyMine - per un paio d'anni prima di passare da 'back' a vi (m). L'ho fatto perché Ruby è un linguaggio molto difficile per cui scrivere un IDE (typing anatra e altre caratteristiche dinamiche) e di conseguenza gli IDE tendono ad essere lenti e / o richiedono la macchina più recente e veloce.

Ebbene si, ho delle esperienze in merito al fatto di far parte del team misto windows / unix & c ++ / java. Penso che questo non sia un problema a condizione che tutti si sentano a proprio agio a lavorare con l'altro IDE o che non ci sarà mai una situazione in cui chiunque non abbia familiarità con IDE Y debba lavorare sull'altro ragazzo (che è il ragazzo con IDE Y ) sistema.

Se tutti lo vogliono, va bene, ma persone diverse potrebbero voler utilizzare editor / IDE diversi. Non vorrei davvero che le persone mi costringessero a usare un editor diverso dal mio preferito se stavo lavorando a qualcosa di grosso con una squadra, e dubito di essere solo. Le persone potrebbero essere molto contente della situazione se non le costringi a utilizzare un determinato editor.

A proposito, Emacs!

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

Ad esempio, se il tuo IDE è integrato nel processo di revisione del codice per quanto riguarda i commenti e l'aggiornamento del codice, 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 utilizzare un IDE non supportato (o una versione diversa) mentre tutti gli altri ne usano uno compatibile, la vita potrebbe essere difficile per le persone che hanno scelto di essere al di fuori del loop di supporto.

Al nostro posto costruiamo i nostri progetti utilizzando Visual Studio. Quando si tratta di modificare il testo, passo a Emacs. Alla tua azienda non dovrebbe interessare finché il lavoro è finito.

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

Se non influisce sulla catena degli strumenti o sui plug.ins di controllo del codice sorgente, forse sì. Inoltre, le due nuove persone possono dimostrare un chiaro beneficio? Hanno usato il tuo IDE?

Altrimenti, non ho pazienza con questa assurdità 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 andarsene. Stava usando l'altro IDE l'unico punto saliente nel vecchio lavoro: in tal caso, dovrebbero essere STFU ed essere grati ..

SÌ! Applica IDE singleton.

Crea problemi quando cambia la dipendenza del progetto. se si introduce una nuova dipendenza nel progetto, ognuno perderà tempo per introdurre quella nuova dipendenza, e alcuni potrebbero fallire e perdere tempo in quel processo. ENORME RIFIUTO DEL TEMPO.

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