Todo membro de uma equipe deve usar o mesmo IDE? [fechadas]

23

Você acha que faz sentido reforçar que todos os membros de uma equipe devem usar o mesmo IDE?

Por exemplo, todos os engenheiros que já fazem parte da equipe usam o IDE X. Dois novos engenheiros vêm e desejam usar o IDE Y, porque é isso que eles estão usando há vários anos.

Você tem alguma experiência com equipes de "IDE misto"? Se assim for, o que é?

finrod
fonte
4
O problema que tive com os ambientes de editor misto é a formatação automática de código e o tratamento de coisas como guias. Contanto que você entenda tudo direito, não importa muito.
Michael Kohne

Respostas:

54

Desde que o sistema de criação 'oficial' (usado pelos servidores de criação contínua) seja o mesmo para todos, não vejo motivo para que cada membro da equipe não possa escolher as ferramentas que deseja ...

Xavier Nodet
fonte
5
Esta é a resposta certa.
31
Eu acrescentaria que, se o sistema oficial de compilação depender de um IDE, há um problema.
AProgrammer
4
Quando você passa muito tempo na mesa de outros membros da equipe, pode ser irritante descobrir sua configuração antes de poder ajudá-los.
Doug T.
4
AMD!!! Um IDE desenvolvido internamente ??? Essa é uma receita para um desastre, como um sistema de rastreamento de erros desenvolvido internamente.
Job
8
@Job, eu trabalho na Microsoft, então, estritamente falando, o VS também é um IDE desenvolvido internamente. Também usamos sistemas de rastreamento de bugs desenvolvidos internamente ... TFS e Product Studio :).
JSB ձոգչ
7

Se sua equipe depende de determinados plug-ins disponíveis apenas para determinados IDEs, faz sentido unificar todos na mesma plataforma de desenvolvimento. Também acho mais fácil ajudar alguém com um problema de desenvolvimento se ele tiver o mesmo IDE que eu, enquanto que se eu quiser ler a tela de alguém com uma interface desconhecida, levará um pouco mais de tempo.

Dszordan
fonte
7
Se sua equipe conta com um plug-in IDE para algo não trivial, você já tem problemas maiores.
HedgeMage
@HedgeMage Apenas um sith lida com absolutos. Por exemplo, e se o projeto for baseado na plataforma Eclipse? Não sei qual é o estado atual, mas há alguns anos o IntelliJ era incapaz de fazer validações sofisticadas para os metadados do plug-in Eclipse. Tivemos um desenvolvedor na equipe que insistiu no IntelliJ - mais de uma vez verificando o código quebrado.
21813 Eugene
3

Uma desvantagem é que, ao emparelhar, você não pode trocar o teclado entre você com a mesma fluência. Entre os IDEs convencionais, isso provavelmente não é um problema enorme, mas se uma pessoa estiver acostumada ao Eclipse enquanto a outra estiver acostumada a vim, haverá uma incompatibilidade. O usuário do Eclipse pode muito bem ser incapaz de usar o vim, enquanto o usuário do vim (sou eu;) passa muito tempo xingando baixinho com a horrível lentidão do uso do Eclipse de baunilha.

Dito isto, ainda prefiro usar o vim. Desde que seu par esteja satisfeito com apenas um de vocês "dirigindo" por longos períodos, ele funciona bem.

E eu sei que existem plugins para fazer o Eclipse funcionar como o vi, mas estou falando de emparelhamento onde eu vou e sento com alguém que tem o Eclipse trabalhando como eles gostam, para que eles não estejam instalando esse plug-in.

Hamish Downer
fonte
2

Não faria sentido forçar todos os desenvolvedores do kernel do Linux a usar o mesmo IDE (ou usar qualquer IDE).

segfault
fonte
2

Não tenho experiência com IDEs mistos, a menos que você conte com um IDE comercial com suplementos ocasionais por um editor de texto "múltiplos IDEs", mas posso pensar em alguns prós e contras.

Prós

  • Cada desenvolvedor pode ser mais produtivo com o que sabe melhor
  • Alguns IDEs podem fornecer uma vantagem sobre outros (um pode ser melhor na refatoração, outro pode ser melhor no fornecimento de auxílios de codificação, outros podem ser melhores na integração de dados, qualquer que seja). Usar uma mistura pode permitir que sua equipe aproveite isso.
  • Você terá um pouco de proteção contra a possibilidade de um dos IDEs se desfazer.

Contras

  • Problemas de licenciamento. Se houver vários IDEs comerciais envolvidos, talvez seja mais caro. No mínimo, poderia ser mais para acompanhar.
  • Problemas de licenciamento 2. Se houver estruturas ou plug-ins licenciados pelo IDE ou langauge, isso será um problema?
  • Como Dszordan mencionou, certos plug-ins podem não ser compatíveis com os diferentes IDEs.
  • Se os IDEs tiverem componentes de geração de código ou mecanismos de formatação de estilo que façam as coisas de maneira diferente, isso poderá causar alguma confusão.
Bernard Dy
fonte
1

Há uma razão pela qual isso pode ser forçado. Basta considerar o visual studio e o emacs / vim. Como no Windows, o visual studio adicionará um extra no final da linha. Isso atrapalha a exibição no emacs / vim. Além disso, as guias criam um problema. O problema conosco é que nós desenvolvedores trabalhamos no Linux, mas nossa arquitetura de software é confortável no visual studio. Uma vez, ele nos amaldiçoa dizendo que não formatamos o arquivo corretamente. Porém, quando ele descobriu que isso se devia ao problema de configuração padrão, todos concordamos com o mesmo formato.
Se alguém me forçar a usar um IDE específico, não me sentirei mal. O que for bom para a equipe, respeitarei isso e comprometer-me-ei.

Manoj R
fonte
1
Você está confundindo o padrão de formatação de código com o uso do IDE. Se você decidir usar 3 espaços para o seu nível de indentação, poderá defini-lo no Visual Studio ou no Emacs (eu sei, eu uso os dois). Outras questões como os diferentes terminações de linha no Windows, Macs, e Unix poderia ser resolvido por costume check-in / check-out roteiros, ala se OS == Windoze ...
SnoopDougieDoug
1

O desenvolvedor de hoje quer escolher suas próprias ferramentas.

Isso mudou ao longo do tempo. 10 ou 15 anos atrás, não havia tantas opções em lugares onde trabalhei. (Sim, havia muitos editores, mas eles não eram uma "escolha"). A loja em que trabalhei há 15 anos era muito "velha escola" (até então!) E vi era o editor. Sem escolha Isso foi realmente muito útil, porque depois do primeiro mês de xingamentos e xingamentos, eu realmente gostei.

Hoje, existem muitas opções e cada uma tem muitas vantagens.

Na minha experiência pessoal, usei um IDE - rubyMine - por alguns anos antes de voltar para vi (m). Fiz isso porque o Ruby é uma linguagem muito difícil de escrever para um IDE (tipagem de pato e outros recursos dinâmicos) e, como resultado, os IDE tendem a ser lentos e / ou exigem a máquina mais recente e rápida.

Michael Durrant
fonte
0

Bem, sim, eu tenho alguma experiência nesse sentido em fazer parte de uma equipe mista de janelas / unix e c ++ / java. Acho que isso não é um problema, desde que todos se sintam à vontade para trabalhar com o outro IDE ou nunca haverá uma situação em que alguém que não esteja familiarizado com o IDE Y precise trabalhar com o outro (que é o cara com o IDE Y ) sistema.

Gaurav
fonte
0

Se todo mundo quiser, tudo bem, mas pessoas diferentes podem querer usar editores / IDEs diferentes. Eu realmente não gostaria que as pessoas me obrigassem a usar um editor diferente do meu preferido se eu estivesse trabalhando em algo grande com uma equipe e duvido que esteja sozinho. As pessoas podem ficar mais felizes com a situação se você não forçá-las a usar um editor específico.

Aliás, Emacs!

compman
fonte
0

Não acho que todo mundo precise ter o "mesmo" IDE, mas seria bom que todos tivessem um IDE "suportado".

Por exemplo, se o seu IDE estiver integrado ao processo de revisão de código no que diz respeito a comentar e atualizar o código, faria sentido que todos estivessem em uma plataforma suportada.

Se sua empresa estiver usando um ambiente colaborativo, como o Rational Team Concert, e um ou dois caras quiserem usar um IDE não suportado (ou uma versão diferente) enquanto todos os outros usarem compatíveis, a vida poderá ser difícil para as pessoas que escolheram ser fora do loop de suporte.

Zoot
fonte
-2

Em nosso lugar, criamos nossos projetos usando o Visual Studio. Quando se trata de editar texto, mudo para o Emacs. Sua empresa não deve se importar enquanto o trabalho estiver concluído.

rfcoder89
fonte
-3

Parece um pouco como "usamos isso no meu antigo emprego". Bem, eles não estão no seu antigo emprego.

Se isso não afetar sua cadeia de ferramentas ou plug.ins de controle de origem, talvez sim. Então, novamente, as duas novas pessoas podem demonstrar um benefício claro? Eles já usaram o seu IDE?

Caso contrário, não tenho paciência com essa bobagem, a menos que haja um bom argumento para isso. Eles não estão em seu antigo emprego: não poderia ter sido tão bom para eles querer ir embora. Estava usando o outro IDE o único destaque em seu antigo trabalho: nesse caso, eles deveriam STFU e agradecer ..

gbn
fonte
As preferências das pessoas não deveriam importar para um local de trabalho? A preferência é um absurdo? A satisfação de um programador não é um benefício para a empresa? Sinto muito, mas isso não "compila" para mim.
daramarak
@daramarak: Onde isso se transforma em arrogância ou sendo uma prima donna, especialmente para lojas maiores com padrão corporativo? Lembre-se: novos caras entrando em uma nova empresa dizendo "queremos isso" são arrogância.
gbn 14/02
-6

SIM! Aplicar IDE singleton.

Isso causa problemas quando a dependência do projeto é alterada. se alguém introduzir uma nova dependência no projeto, todos perderão tempo para introduzir essa nova dependência, e alguns poderão falhar e perder tempo nesse processo. ENORME PERDA DE TEMPO.

deve haver uma justificativa MUITO boa para adicionar um IDE diferente à equipe, significando que o tempo economizado deve ultrapassar o tempo dedicado à migração do sistema para diferentes IDEs.

Mostrar nome
fonte
Um IDE é realmente um editor. De maneira alguma um editor constitui uma dependência do projeto. (Estou ciente de que esta resposta pode ter sido sarcástico, no entanto, este não é o lugar para o sarcasmo)
Arafangion
O IDE não é realmente um editor, porque você não usa "Notepad.exe". você precisa de um trabalho extra feito pelo IDE, e o ide não possui padrões, o que dificulta o uso da capacidade externa. e se você mencionar que a edição hexadecimal é apenas "editor de texto", o código não é apenas texto.
Nome para exibição
O IDE é realmente apenas um editor, com várias outras ferramentas, a grande maioria das quais pode ser chamada na linha de comando de qualquer maneira.
Arafangion
Eu não tenho pessoas aqui. eles dizem que um ide interno é ruim e o ide uniforme é ruim. portanto, o ide deve ser uniforme para todos os programadores, mas não para todos os programadores que trabalham no mesmo projeto. HÃ?! Eu não entendo!
Exibir nome
2
É apenas uma ferramenta. Qualquer programador competente deve poder utilizar suas ferramentas adequadamente e, se achar que um IDE diferente é mais adequado para o desenvolvimento, deve fazê-lo.
Arafangion