Pouvons-nous utiliser EiffelBuild pour de grands projets ou devrions-nous limiter son utilisation pour le prototypage?

Question

EiffelBuild est l'outil graphique de construction d'interface graphique ISE dédié à Eiffel.

Je l’essaye et je le trouve très facile à utiliser, mais je suis un peu préoccupé par l’utilisation d’un tel outil pour un grand projet. L'utilisation d'un outil de création d'interface graphique peut être restrictive.

Etant donné que l'héritage Eiffel facilite la création de composants, il peut être préférable, à long terme, d'utiliser nos propres versions spécialisées des objets graphiques plutôt que les objets standard.

Êtes-vous au courant de toute limitation d’EiffelBuild qui justifierait d’éviter son utilisation pour les grands projets.

Answer 1

Je limiterais l'utilisation d'EiffelBuild au prototypage. C'est un bel outil, mais à long terme, la gestion des projets EiffelBuild sera de plus en plus compliquée (et cela s'applique à la plupart des concepteurs):

• Les nouvelles versions d’estudio sont publiées tous les 6 mois, ce qui vous oblige à maintenir vos projets EiffelBuild toujours en état de fonctionner comme prévu, et vous attendez de devoir gérer des migrations de temps en temps. Désormais, tout votre code Eiffel sera soumis aux mêmes défis, mais avec des projets dans EiffelBuild, vous devrez faire face aux deux changements de langue ET à EiffelBuild (et parfois aux deux en même temps ...)
• Si les versions N + 1 et N ne sont pas compatibles, vous devrez créer une branche de vos projets EiffelBuild pour prendre en charge les deux versions, que ce soit uniquement pendant la période de transition
• Il peut être difficile d’intégrer plusieurs projets EiffelBuild
• Certains composants graphiques peuvent être difficiles à réutiliser dans EiffelBuild, par exemple un composant graphique spécialisé (un ensemble de classes, par exemple), notamment si ce composant n'est pas un projet EiffelBuild lui-même
• J'ai eu du mal à réutiliser des composants d'une application EiffelBuild dans une autre, alors qu'avec des composants assez bien conçus, c'est beaucoup moins un problème

J'espère que cela vous aidera.

Answer 2

  

Je l’essaye et je le trouve très facile à utiliser, mais je suis un peu préoccupé par l’utilisation d’un tel outil pour un grand projet. L'utilisation d'un outil de création d'interface graphique peut être restrictive.

Comment est-ce "restrictif"? Et comment la taille du projet entre-t-elle en jeu?

Si vous voulez dire que c'est un générateur de code et que vous ne comprenez pas complètement le code, alors je suis tout à fait d'accord. La génération de code ne fonctionne que dans les cas où vous avez écrit le code à la main, à froid, et le générateur vous donne un coup de pouce en évitant le travail fastidieux. Dans ce cas, vous êtes totalement confiant dans la modification et la maintenance du code généré.

  

Etant donné que l'héritage Eiffel facilite la création de composants, il peut être préférable, à long terme, d'utiliser nos propres versions spécialisées des objets graphiques plutôt que les objets standard.

Quelle est la spécialisation que vous ajoutez? Je réfléchirais bien à cela, car cela impliquerait d'écrire, de déboguer et de maintenir une grande hiérarchie de classe dans perpetuam. Soyez absolument certain que la spécialisation est nécessaire, rentable et impossible à obtenir par tout autre moyen avant de franchir cette étape. Faites un effort honnête pour quantifier le coût avant de vous décider.

Je voterais pour l'écriture de votre propre générateur de code une fois que vous aurez suffisamment codé à la main à l'aide des classes d'interface graphique de bibliothèque. C’est une solution durable, IMO.

MISE À JOUR:

J'ai appris Eiffel dans le cadre d'un programme d'études supérieures qui a décidé, au milieu des années 90, que c'était le meilleur langage orienté objet disponible. À l'époque, le C ++ était prééminent mais considéré comme complexe, Java n'avait pas réussi à sortir des laboratoires de Sun et C # n'était même pas une lueur dans les yeux d'Anders. La faculté de cet établissement était amoureuse de la conception par contrat et de la rigueur académique qu’elle impliquait.

J'ai lu la "Construction de logiciels orientée objet" de Meyers. La première édition présentait DbC et faisait de Meyers une star dans le monde des objets. À mon avis, la deuxième édition était une chose boursouflée qui a mis fin à son ascension.

Honnêtement, si vous écrivez ce système volumineux pour un employeur, je vous conseillerais de laisser Eiffel et de passer à une langue plus courante pour vous et pour votre bien. C # pourrait être un bon choix si vous êtes sur une plate-forme Windows; utilisez Java si vous avez un environnement hétérogène ou si vous ne pouvez pas vous permettre la pile Microsoft.

SO a toutes les quatre questions taguées sur Eiffel. Je pense que le volume dit quelque chose. Vous avez peut-être raison de dire que la popularité n'est pas toujours le meilleur indicateur de qualité. On m'a dit que la bêta était une meilleure solution technique que la VHS, mais le fait est qu'elle a perdu sur le marché et est introuvable aujourd'hui. Même avec Eiffel. Je laisserais tomber si j'étais vous.

MISE À JOUR 2:

Très bien. Je ne saurais dire d'après votre message original quelle a été votre expérience avec d'autres langues.

" attentes élevées en matière de qualité " implique que vous pensez qu'Eiffel soutiendra la qualité au niveau linguistique d'une manière que vous ne pouvez pas dupliquer avec d'autres langues. Je ne suis pas d'accord avec cela. La qualité du code relève davantage des compétences et des pratiques des développeurs que du langage lui-même.

Design By Contract est entièrement survendu, IMO. J'ai lu qu'il est souvent désactivé en production parce que cela représente un succès. Si cela est vrai pour vous, comment pensez-vous qu'Eiffel contribue à la qualité?

Je m'assurerais que le client pour lequel vous écrivez cette application comprend toutes les conséquences qu'une décision de prendre avec Eiffel aura: un nombre limité de développeurs pour la maintenir, un personnel marginalisé par l'utilisation d'une langue morte , etc. Assurez-vous de ne pas trop le vendre à cause d'un souhait subjectif.