Podemos usar o eiffelbuild para grande projeto ou devemos restringir seu uso para prototipagem?

Question

Eiffelbuild é a ferramenta gráfica de construção do ISE GUI dedicada a Eiffel.

Eu tento e acho muito fácil de usar, mas estou um pouco preocupado em usar essa ferramenta para um projeto grande. O uso de uma ferramenta de construção da GUI pode ser restritivo.

Como a herança Eiffel facilita a criação de componentes, a longo prazo, pode ser melhor usar nossas próprias versões especializadas dos objetos gráficos que usam os padrão.

Você está ciente de qualquer limitação do Eiffelbuild que justificaria evitar seu uso para grandes projetos.

Answer 1

Eu restringiria o uso do eiffelbuild à prototipagem. É uma boa ferramenta, mas, a longo prazo, ficará cada vez mais complicado para gerenciar projetos eiffelbuild (e isso é verdade para a maioria dos designers):

• Novas versões do Estudio são lançadas a cada 6 meses, tornando -se um fardo ter que manter seus projetos eiffelbuild ainda funcionando conforme o esperado de uma versão para a outra, espere ter que lidar com as migrações de vez em quando. Agora, todo o seu código Eiffel estará sujeito aos mesmos desafios, mas com os projetos no Eiffelbuild você terá que lidar com as mudanças no idioma e no eiffelbuild (e às vezes ambos ao mesmo tempo ...)
• Se a versão n+1 e n não forem compatíveis, você precisará fazer uma filial de seus projetos eiffelbuild para suportar as duas versões, seja apenas durante o período de transição
• Pode ser difícil integrar vários projetos eiffelbuild
• Alguns componentes gráficos podem ser difíceis de reutilizar no Eiffelbuild, como um componente especializado em gráfico (ou seja, conjunto de classes ...) Por exemplo, especialmente se esse componente não for um projeto de eiffelbuild
• Achei difícil reutilizar peças feitas de um aplicativo Eiffelbuild em outro, enquanto com componentes bastante bem projetados é muito menos um problema

Espero que isto ajude.

Answer 2

Eu tento e acho muito fácil de usar, mas estou um pouco preocupado em usar essa ferramenta para um projeto grande. O uso de uma ferramenta de construção da GUI pode ser restritivo.

Como isso é "restritivo"? E como o tamanho do projeto entra em jogo?

Se você quer dizer que é um gerador de código e você não entende o código que está saindo completamente, concordo completamente. A geração de código funciona apenas nos casos em que você está escrevendo o código à mão para baixo, e o gerador está lhe dando um elevador salvando o trabalho grunhido. Você se sente totalmente confiante em modificar e manter o código gerado nesse caso.

Como a herança Eiffel facilita a criação de componentes, a longo prazo, pode ser melhor usar nossas próprias versões especializadas dos objetos gráficos que usam os padrão.

Qual é a especialização que você está adicionando? Eu pensaria com cuidado em fazer isso, porque significa escrever, depurar e manter uma grande hierarquia de classe em Perpetuam. Esteja absolutamente certo de que a especialização é necessária, vale o custo e inatingível por qualquer outro meio antes de dar esse passo. Faça um esforço honesto para quantificar o custo antes de decidir.

Eu votaria para escrever seu próprio gerador de código depois de fazer codificação manual suficiente usando as classes da GUI da biblioteca. Essa é uma solução sustentável, IMO.

ATUALIZAR:

Aprendi Eiffel em um programa de pós-graduação que decidiu nos anos 90 que era o melhor idioma orientado a objetos disponíveis. Na época, o C ++ era preeminente, mas considerado complexo, Java não havia saído dos laboratórios do Sun, e C# não era um brilho nos olhos de Anders. O corpo docente deste estabelecimento estava apaixonado pelo design por contrato e o verneer do rigor acadêmico que implicava.

Eu li a "Contrrução de software orientada a objetos" de Meyers. A primeira edição introduziu o DBC e fez de Meyers uma estrela no mundo orientado a objetos. Na minha opinião, a segunda edição foi uma coisa inchada que acabou com sua subida.

Honestamente, se você está escrevendo esse grande sistema para um empregador, eu o aconselharia a deixar Eiffel e mudar para uma linguagem mais convencional por sua causa e sua. C# pode ser uma boa escolha se você estiver em uma plataforma Windows; Use Java se você tiver um ambiente heterogêneo ou não poderá pagar a pilha da Microsoft.

O mesmo acontece com todas as quatro perguntas marcadas sobre Eiffel. Eu acho que o volume diz algo. Você pode estar certo de que a popularidade nem sempre é o melhor indicador de qualidade. Disseram -me que a beta era uma solução técnica melhor que o VHS, mas o fato é que ela perdeu no mercado e não está em lugar algum hoje. O mesmo com Eiffel. Eu deixaria soltar se fosse você.

Atualização 2:

Muito bom - eu não sabia dizer na sua postagem original qual era sua experiência com outros idiomas.

"Alta expectativa de qualidade" implica que você acredita que a Eiffel apoiará a qualidade no nível do idioma de uma maneira que você não pode duplicar com outros idiomas. Eu discordaria disso. A qualidade do código tem mais a ver com as habilidades e práticas dos desenvolvedores do que o próprio idioma.

O design por contrato é totalmente superado, IMO. Eu li que muitas vezes é desligado na produção porque representa um sucesso de desempenho. Se isso é verdade para você, de que outra forma você espera que Eiffel contribua para a qualidade?

Eu garantiria que o cliente que você está escrevendo para entender todas as consequências que uma decisão de ir com a Eiffel trará: conjunto limitado de desenvolvedores para mantê -lo, uma equipe que é marginalizada pelo uso de um idioma morto etc. Certifique -se de não exagerar por causa de um desejo subjetivo.