2009-10-08 10 views
8

Se tutti i membri del team sono obbligati a utilizzare lo stesso IDE (ad esempio eclipse, netbeans, intellij) per la programmazione, anche se il processo di compilazione è indipendente dall'IDE? (Supponiamo che nessun plug-in specifico IDE sia utilizzato nel progetto.)Se tutti i membri del team utilizzano lo stesso IDE?

Se tutti utilizzano lo stesso IDE, possono condividere la stessa configurazione e lavorare in un ambiente più coerente. Tuttavia, se hai lavorato con un certo IDE per molti anni, essere costretti a usarne un altro sarà frustrante e ridurrà la produttività perché cercheresti di imparare l'IDE invece di concentrarti sul dominio del problema.

io sono interessato a sapere che uno di questi due tipi di squadre che hanno lavorato in e che uno pensi funziona meglio.

Grazie

risposta

11

Se non plug-in specifici vengono usati allora perché non lasciare che la gente usa quello che vogliono? Utilizziamo una miscela di Eclipse, vim e altri editor per modificare un mix di Java, PL/SQL e Pro * C. Abbiamo tutti configurazioni diverse e non è mai stato un problema. Abbiamo detto che tutti usiamo Eclipse per Java, ma questo è principalmente perché è il miglior IDE per Java (per i nostri scopi). Siamo tutti su versioni diverse, quindi non c'è davvero alcuna coerenza forzata.

2

Se ti senti troppo draconiano per questo soffocherai l'innovazione e in due anni sarai su una versione antica di un IDE che è del tutto inadeguato per il tuo compito. D'altra parte, se registri liberamente, ogni sviluppatore farà le sue cose e avrai un successo in termini di produttività.

Hanno una "regola di 3". Lascia che il team scelga quale IDE desidera utilizzare. Se alcuni membri preferiscono un IDE diverso, consenti una seconda alternativa. Nel momento in cui alcuni membri vogliono passare a una terza alternativa, è giusto se il team accetta di sbarazzarsi di uno dei primi due.

In questo modo si dispone di una certa coerenza nel vostro team di sviluppo (con aumenti di produttività che vanno in questo), ma si consente di passare a soluzioni alternative, senza un comitato di decidere esso.

10

Io sono un fan di lasciare che ogni sviluppatore scegliere il proprio IDE. Ho lavorato in ambienti standardizzati e misti, e non ho visto molta differenza di produttività - è più un problema di morale (le persone costrette a usare strumenti che non amano sono meno felici).

si parla IDE Java-centric (Eclipse, NetBeans, IntelliJ). In un ambiente incentrato su Java, si può usare Maven per generare file di progetto per quegli IDE, il che riduce una buona parte dell'argomento per la standardizzazione su un singolo IDE - perché standardizzi a un livello inferiore - il file di progetto Maven.

L'unica avvertenza a mio parere è che trovo che gli sviluppatori che scelgono di utilizzare semplici editor di testo anziché IDE creano quasi sempre codice che è pieno di avvertimenti quando vengono visualizzati in un IDE, quindi mi concentro su quella pratica. Ovviamente, se qualcuno è un wiz con emacs o textmate, ecc. E non genera avvisi, non ho alcun problema con loro che continuano con la loro piattaforma scelta.

+1

Sono totalmente d'accordo con la parte morale. – fglez

+0

Ho anche sperimentato il caveat della scelta libera IDE. La maggior parte del nostro team utilizza IntelliJ, ma tutto ciò che l'utente di Eclipse controlla è pieno di avvisi. Non ho usato Eclipse, quindi non so se ha avvertimenti scadenti, o che lo sviluppatore li ha disattivati ​​o è solo uno sviluppatore scarso. –

2

costringendo tutti a utilizzare lo stesso IDE funziona solo se si impiegano cloni. Poiché ogni persona è diversa, ha approcci diversi per risolvere i compiti. Se il divario diventa troppo grande, consentire agli individui di utilizzare il loro strumento preferito può aumentare le prestazioni e il morale (morale perché le persone si sentono meglio quando credono che hanno un impatto).

Ma questo non deve portare a un problema di assistenza. Se qualcuno sta chiedendo un IDE oscuro (per qualsiasi motivo), è meglio che sia in grado di risolvere da sé i propri problemi.Scelta non significa che tu abbia una scusa per saltare il lavoro perché il tuo strumento si rompe tutto il tempo.

1

Non posso dire molto su Java. Ma per quanto riguarda il C++, se non si è d'accordo sul rientro (sono spazi, schede, schede di quale dimensione) il codice in runtime diventa un casino e meno leggibile.

Punto aggiuntivo che può essere contrario all'uso di più IDE nella stessa squadra se le revisioni paritarie/la codifica vengono eseguite regolarmente (ad esempio parte della revisione XP o Coe).

Se questi non sono problemi, non vedo perché i membri del team non possano raccogliere il loro IDE favourite.

Problemi correlati