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

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 é?

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 ...

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.

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.

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

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.

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.

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.

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.

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!

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.

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.

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 ..

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.