Por que todos não usar ferramentas de RAD? [fechadas]

Question

ferramentas RAD como Clarion e reivindicação WINDEV ser 10x a 20x vezes mais rápido em desenvolvimento e os usuários destas ferramentas reivindicar o mesmo. Se isso é através, por que há tão poucas pessoas que utilizam essas ferramentas? se o pedido for feito em 40 horas em vez de 400 você gostaria de fazer muito mais dinheiro, certo?

Answer 1

Como

1. Eles são grandes, se você quer algo que eles previram, mas terrível se não
2. Eles às vezes escondem muita informação técnica que é vital para o bom desempenho
3. Você não pode criar facilmente fluido, interfaces dinâmicas ou qualquer coisa "fora da caixa"
4. Você não pode estender-los facilmente
5. Você não pode comprar / obter componentes de terceiros que pode servi-lo
6. Eles permitem que programadores medíocres para produzir abominações
7. Qualidade, Preço, Tempo. Escolha dois.

Answer 2

Não há bala de prata, e as reivindicações de 20x etc são um grão pena de sal.

No entanto, uma grande parte disso é as percepções mencionadas em outras respostas neste tópico. Eles variam desde o simples ( "não pode ser verdade") para o genérico ( "duro personalizar") para o geral ( "gera código confuso"). A fim de realmente comparar você precisa comparar um ambiente 3GL específico com um ambiente 4GL específico. Ambos terão pontos fortes e fracos. Ambos provavelmente irá permitir que você crie bons ou maus programas.

A maior fronteira é o fator habilidade. Para obter o melhor de qualquer ferramenta leva tempo e esforço. Não é de surpreender os usuários de de 4GL são muitas vezes os maiores defensores de que, tão claramente algo sobre eles trabalha para um monte de gente. Mas eles geralmente custam mais (para comprar), têm suas próprias idiossincrasias e as suas próprias forças e fraquezas. Obtendo programadores para converter de um ambiente para outro é difícil.

Em grandes organizações há também um monte de código existente para atender. Se você tem equipes de desenvolvedores, é difícil fazer um caso para mudar toda uma equipe de programadores de uma ferramenta para outra. Mesmo se você fez isso, sem usuário experiente existente na equipe, o processo de aprendizagem será lenta e difícil. Novamente, isto é verdade, independentemente da linguagem ou ambiente.

Economics também desempenha um grande papel. Empresas como a segurança de estar no main-stream. Mesmo se ele custa mais. Eles gostam da idéia de que esquadrões de programadores estão disponíveis para escrever código na linguagem "atual". Os programadores são uma mercadoria que são esperados para ir e vir, e pode ser substituído quando necessário. O mundo está cheio de C, Java, C # programadores etc. Escolhendo uma linguagem "pequeno" que resulta em problemas políticos intermináveis, as decisões têm de ser justificado e assim por diante. É a velha "ninguém foi demitido por comprar IBM" síndrome. No final do dia, se o dinheiro não é objeto, em seguida, há outras considerações que (politicamente) importa mais.

Não é nenhuma surpresa, então, que a maioria dos usuários de produtos como o Clarion e Windev são ou programadores independentes, ou membros de empresas muito pequenas. Nestas situações economia diárias importa mais do que utilizando a mais recente ferramenta ou preenchimento de um CV. Imagine um mundo onde você só paga quando os navios do programa. De repente produtividade da matéria importa e a coisa mais importante é começar o trabalho feito para que você pode comer.

Uma vez que existem muito mais pessoas que trabalham como um empregado de trabalhar para si próprios, não é surpreendente que a maioria dos programadores não precisa se preocupar diretamente sobre sendo pago. Se você receber o seu salário, não importa o que você usa, então você pode muito bem ir com o fluxo. Há trabalhos muito mais lá fora, se este passa por baixo. Assim, as ferramentas tradicionais permanecem mainstream, e tudo o resto é ignorado.

O fato de que muitos dos preconceitos mencionados em outras respostas aqui são falsas realmente não importa. A percepção é tudo e em um mundo binário de certo e errado qualquer linguagem que você está usando agora é o "direito" um, eo resto são "errado".

Answer 3

Não há Silver Bullet .

Na minha experiência, ferramentas e IDEs RAD remover algum do trabalho penoso de codificação, mas pouco fazem para acelerar um projeto-se. Os maiores ganhos de produtividade vem muito mais cedo no ciclo de desenvolvimento de software, especificamente na definição da natureza, tamanho e escopo do problema, criando estimativas, e gestão de riscos.

ferramenta Não há RAD pode corrigir erros cometidos no início da SDLC . De fato, o oposto pode ocorrer: desenvolvedores que usam essas ferramentas podem rapidamente despejar código contra uma má spec. Isso dá a ilusão de que estão a ser produtivo, quando na realidade o produto errado está sendo construída.

Answer 4

ferramentas RAD não lhe dá a personalização de escrever coisas em seu próprio país. O cliente normalmente diz algo como "Isso seria bom se ele funcionou exatamente assim", o que seria uma mudança muito rápido se você tivesse codificado, mas vai exigir que você estudar a ferramenta para ver se essa mudança é possível (e frustrar o cliente, se ele não é).

Além disso, você tem mais controle sobre o que está feito, e é menos propensos a ter um comportamento estranho 'causada por suposições erradas. É mais fácil de testes de escrita também.

Finalmente, é uma coisa totalmente nova para aprender, com um risco de que o tempo gasto não vale a pena (talvez seria, mas eu não estou disposto a correr o risco de aprender algo muito específico que eu não poderia usar) .

Answer 5

rápido nem sempre significa precisa. Um exemplo que eu posso pensar, se alguém estivesse desenvolvendo um pacemaker, eu prefiro que eles gastam 400 horas começá-lo corrigir em vez de desenvolvê-lo em apenas 40 e arriscar um potencial resultado desastroso.

Answer 6

Não é inteiramente verdade. Eles podem melhorar a produtividade para algumas tarefas não mordeu todos. E a maioria IDE já contêm grande quantidade de ferramentas para aumentar a produtividade. Para modelos de código de exemplo e conclusão de código. Então eu não acho que eles podem gerenciar de 10 a 20 vezes para um projeto inteiro, em comparação com outras ferramentas modernas.

Answer 7

Você não pode confiar em uma ferramenta RAD para escrever código limpo, sustentável. Basta ver por si mesmo, use o Visual Designer Studio, arraste um datagrid e uma conexão de banco de dados e, em seguida, verificar o código confuso ele irá gerar, se você precisa para personalizar algo que não estava previsto pelos desenvolvedores do assistente, você vai encontrar-se em um monte de problemas. Agora, como você vai manter o código? Tudo é tão confuso e fortemente acoplados.

Answer 8

Quando você decidir usar uma ferramenta RAD você aceitar certos sacrifícios:

• conhecimento profundo do código / sistema é uma coisa que é muito difícil ter quando você tem gerado muito do seu código ou permitido uma ferramenta RAD de ajuda.

• A flexibilidade pode ser perdida; algumas ferramentas irá anular quaisquer alterações feitas pelo homem e regenerar o código como eles sabem como. Pessoalmente acredito que essas ferramentas devem ser capazes de identificar quando as alterações foram feitas por uma pessoa e pelo menos lixo para executar -. Alterações humana deve sempre prevalecer

• Muitas vezes essas ferramentas podem ajudar no desenvolvimento greenfield, mas deixam uma quantidade monstruosa de código por trás de manter. As reivindicações de 10x a 20x ganhos de produtividade, provavelmente, são medidos por linhas de código em vez de funcionalidade acabado real.

Answer 9

Se um já tem uma equipe usado para certos IDEs, qual é o custo de mudar isso? Quero dizer, se eu vou a partir do Visual Studio 2008 para Clarion ou WINDEV, é meu empregador preparado para lidar com o custo que a minha incrementando em que vai ser? Há também a questão a minha mente de quanto fazer essas ferramentas custar e que tipos de garantias se algum pode ser dada de que eles vão fazer, bem como reivindicado.

Answer 10

Eu faço acreditar que as ferramentas RAD doesnt dar u uma mão flexível no código. No entanto, se qualquer ferramenta específica RAD é salvar 60-70 por cento do tempo de desenvolvimento, investir tempo vale a pena nela. Agora-a-dia desenvolvedores qualificados estão no pico de demanda. Isto leva a aumentar nos índices de atrito. desenvolvedores confiáveis ??estão renunciando apenas para 5/10% de aumento em payscales. Isto impacta As empresas de desenvolvimento muito. A única, que fez a maior parte do desenvolvimento, de repente folhas. Esta atinge o cronograma de conclusão do projeto severamente. RAD Tools torna a organização menos dependente do Skilled Developers. Mais importante, a maioria dos clientes são menos incomodado sobre o que a tecnologia que você está usando para o desenvolvimento. Eles estão felizes, se seus requisitos funcionais sejam atendidos.

Tudo dito e feito, ferramentas RAD terá uma demanda crescente no cenário atual, onde o atrito é elevado. A maioria dos projetos se arrastado para fora do cronograma só porque dessa dependência. Os leitores podem diferir.