¿Podríamos usar EiffelBuild para proyectos grandes o deberíamos restringir su uso para la creación de prototipos?

Question

EiffelBuild es la herramienta gráfica de creación de GUI ISE dedicada a Eiffel.

Lo pruebo y me resulta muy fácil de usar, pero estoy un poco preocupado por el uso de esta herramienta para un proyecto grande. El uso de una herramienta de creación de GUI podría ser restrictivo.

Debido a que la herencia Eiffel hace que sea muy fácil crear componentes, a largo plazo, puede ser mejor usar nuestras propias versiones especializadas de los objetos gráficos que usar los estándares.

¿Conoce alguna limitación de EiffelBuild que justifique evitar su uso en grandes proyectos?

Answer 1

Restringiría el uso de EiffelBuild a la creación de prototipos. Es una buena herramienta, pero a la larga será cada vez más complicado administrar proyectos EiffelBuild (y esto es cierto para la mayoría de los diseñadores):

• Se lanzan nuevas versiones de estudio cada 6 meses, por lo que es una carga tener que mantener sus proyectos EiffelBuild funcionando como se espera de una versión a otra, y tener que lidiar con las migraciones de vez en cuando. Ahora, todo su código Eiffel estará sujeto a los mismos desafíos, pero con los proyectos en EiffelBuild tendrá que lidiar con ambos cambios en el idioma Y EiffelBuild (y a veces ambos al mismo tiempo ...)
• Si las versiones N + 1 y N no son compatibles, tendrá que hacer una rama de sus proyectos EiffelBuild para admitir ambas versiones, ya sea solo durante el período de transición
• Puede ser difícil integrar varios proyectos EiffelBuild
• Algunos componentes gráficos podrían ser difíciles de reutilizar en EiffelBuild, como un componente gráfico especializado (es decir, un conjunto de clases ...), por ejemplo, especialmente si ese componente no es un proyecto EiffelBuild en sí
• Me resultó difícil reutilizar piezas hechas de una aplicación EiffelBuild en otra, mientras que con componentes bastante bien diseñados es mucho menos un problema

Espero que esto ayude.

Answer 2

  

Lo pruebo y me resulta muy fácil de usar, pero estoy un poco preocupado por el uso de esta herramienta para un proyecto grande. El uso de una herramienta de creación de GUI podría ser restrictivo.

¿Cómo es esto " restrictivo " ;? ¿Y cómo entra en juego el tamaño del proyecto?

Si quiere decir que es un generador de código, y no comprende el código que está saliendo completamente, entonces estoy completamente de acuerdo. La generación de código solo funciona en aquellos casos en los que tiene que escribir el código a mano, y el generador le está dando un impulso al ahorrar trabajo pesado. Te sientes totalmente seguro al modificar y mantener el código generado en ese caso.

  

Debido a que la herencia de Eiffel hace que sea muy fácil crear componentes, a largo plazo, puede ser mejor usar nuestras propias versiones especializadas de los objetos gráficos que usar los estándares.

¿Cuál es la especialización que está agregando? Pensaría cuidadosamente en hacer esto, porque significa escribir, depurar y mantener una gran jerarquía de clases en perpetuo. Asegúrese de que la especialización sea necesaria, que valga la pena y que no se pueda obtener por ningún otro medio antes de dar este paso. Haga un esfuerzo honesto para cuantificar el costo antes de decidir.

Votaría por escribir su propio generador de código una vez que haya realizado suficiente codificación manual utilizando las clases de la GUI de la biblioteca. Esa es una solución sostenible, IMO.

ACTUALIZACIÓN:

Aprendí Eiffel en un programa de posgrado que decidió a mediados de los 90 que era el mejor lenguaje orientado a objetos disponible. En ese momento, C ++ era preeminente pero se consideraba complejo, Java no había salido de los laboratorios de Sun, y C # ni siquiera era un destello en los ojos de Anders. El profesorado de este establecimiento estaba enamorado del diseño por contrato y del rigor académico que implicaba.

He leído Meyers '' Objeto orientado a la construcción de software ''. La primera edición introdujo DbC e hizo de Meyers una especie de estrella en el mundo orientado a objetos. En mi opinión, la segunda edición fue una cosa hinchada que puso fin a su ascenso.

Honestamente, si estás escribiendo este gran sistema para un empleador, te aconsejaría que abandones Eiffel y cambies a un idioma más corriente por su bien y el tuyo. C # podría ser una buena opción si estás en una plataforma Windows; use Java si tiene un entorno heterogéneo o no puede pagar la pila de Microsoft.

SO tiene las cuatro preguntas etiquetadas sobre Eiffel. Creo que el volumen dice algo. Puede que tengas razón en que la popularidad no siempre es el mejor indicador de calidad. Me dijeron que Beta era una mejor solución técnica que VHS, pero el hecho es que se perdió en el mercado y no se puede encontrar en ninguna parte hoy en día. Lo mismo con Eiffel. Lo dejaría si fuera tú.

ACTUALIZACIÓN 2:

Muy bien: no podía decir en su publicación original cuál fue su experiencia con otros idiomas.

" Alta expectativa de calidad " implica que cree que Eiffel admitirá la calidad a nivel de idioma de una manera que no pueda duplicar con otros idiomas. No estaría de acuerdo con eso. La calidad del código tiene más que ver con la habilidad y las prácticas de los desarrolladores que con el lenguaje en sí.

El diseño por contrato está totalmente sobrevendido, IMO. He leído que a menudo se apaga en la producción porque representa un éxito en el rendimiento. Si eso es cierto para usted, ¿de qué otra manera espera que Eiffel contribuya a la calidad?

Me aseguraría de que el cliente para el que está escribiendo esta aplicación comprenda todas las consecuencias que traerá la decisión de ir con Eiffel: un grupo limitado de desarrolladores para mantenerlo, un personal que está marginado por el uso de un lenguaje muerto , etc. Asegúrese de no venderlo en exceso debido a un deseo subjetivo.