Potremmo usare EiffelBuild per grandi progetti o dovremmo limitarne l'uso per la prototipazione?

Question

EiffelBuild è lo strumento grafico per la creazione di GUI ISE dedicato a Eiffel.

Lo provo e lo trovo molto user-friendly, ma sono un po 'preoccupato di usare uno strumento del genere per un grande progetto. L'uso di uno strumento di costruzione della GUI potrebbe essere restrittivo.

Poiché l'ereditarietà Eiffel rende molto semplice la creazione di componenti, a lungo termine, potrebbe essere meglio utilizzare le nostre versioni specializzate degli oggetti grafici che quelle standard.

Sei a conoscenza di qualsiasi limitazione di EiffelBuild che giustificherebbe evitare il suo utilizzo per grandi progetti.

Answer 1

Vorrei limitare l'uso di EiffelBuild alla prototipazione. È uno strumento piacevole, ma a lungo andare diventerà sempre più complicato gestire i progetti EiffelBuild (e questo è vero per la maggior parte dei designer):

• Le nuove versioni di estudio vengono rilasciate ogni 6 mesi, il che rende un onere dover mantenere i progetti EiffelBuild ancora funzionanti come previsto da una versione all'altra, prevedendo di dover gestire le migrazioni di tanto in tanto. Ora tutto il tuo codice Eiffel sarà soggetto alle stesse sfide, ma con i progetti in EiffelBuild dovrai affrontare entrambe le modifiche alla lingua E EiffelBuild (e talvolta entrambe allo stesso tempo ...)
• Se le versioni N + 1 e N non sono compatibili, dovrai creare una diramazione dei tuoi progetti EiffelBuild per supportare entrambe le versioni, sia durante il periodo di transizione
• Può essere difficile integrare diversi progetti EiffelBuild
• Alcuni componenti grafici potrebbero essere difficili da riutilizzare in EiffelBuild, come ad esempio un componente grafico specializzato (ad es. un insieme di classi ...), specialmente se quel componente non è un progetto EiffelBuild stesso
• Ho trovato difficile riutilizzare parti realizzate da un'applicazione EiffelBuild in un'altra, mentre con componenti abbastanza ben progettati è molto meno un problema

Spero che questo aiuti.

Answer 2

  

Lo provo e lo trovo molto user-friendly, ma sono un po 'preoccupato di usare uno strumento del genere per un grande progetto. L'uso di uno strumento di costruzione della GUI potrebbe essere restrittivo.

In che modo questo "restrittivo"? E come entra in gioco la dimensione del progetto?

Se intendi che è un generatore di codice e non capisci il codice che ne esce completamente, allora sono completamente d'accordo. La generazione del codice funziona solo nei casi in cui hai scritto il codice a mano a freddo, e il generatore ti sta dando un vantaggio salvando il lavoro grugnito. Ti senti completamente sicuro nel modificare e mantenere il codice generato in quel caso.

  

Poiché l'ereditarietà Eiffel rende molto semplice la creazione di componenti, a lungo termine, potrebbe essere meglio utilizzare le nostre versioni specializzate degli oggetti grafici che quelle standard.

Qual è la specializzazione che stai aggiungendo? Penserei attentamente di farlo, perché significa scrivere, eseguire il debug e mantenere una gerarchia di grande classe in perpetuo. Siate assolutamente certi che la specializzazione sia necessaria, che valga il costo e non ottenibile con qualsiasi altro mezzo prima di fare questo passo. Fai uno sforzo onesto per quantificare il costo prima di decidere.

Vorrei votare per aver scritto il tuo generatore di codice una volta che avessi fatto abbastanza codifica manuale usando le classi GUI della libreria. Questa è una soluzione sostenibile, IMO.

AGGIORNAMENTO:

Ho imparato Eiffel in un corso di laurea che ha deciso a metà degli anni '90 che era il miglior linguaggio orientato agli oggetti disponibile. All'epoca, C ++ era preminente ma considerato complesso, Java non era uscito dai laboratori di Sun e C # non era nemmeno un barlume agli occhi di Anders. La facoltà di questo stabilimento era innamorata del design per contratto e del verbo rigore accademico che implicava.

Ho letto Meyers "Contratto software orientato agli oggetti". La prima edizione ha introdotto DbC e ha reso Meyers una specie di star nel mondo orientato agli oggetti. Secondo me, la seconda edizione è stata una cosa gonfia che ha posto fine alla sua ascesa.

Onestamente, se stai scrivendo questo grande sistema per un datore di lavoro, ti consiglierei di abbandonare Eiffel e passare a un linguaggio più tradizionale per il loro bene e il tuo. C # potrebbe essere una buona scelta se ti trovi su una piattaforma Windows; usa Java se hai un ambiente eterogeneo o non puoi permetterti lo stack Microsoft.

SO ha tutte e quattro le domande taggate su Eiffel. Penso che il volume dica qualcosa. Potresti avere ragione sul fatto che la popolarità non è sempre il miglior indicatore di qualità. Mi è stato detto che Beta era una soluzione tecnica migliore di VHS, ma il fatto è che si è perso sul mercato e non si trova da nessuna parte oggi. Lo stesso con Eiffel. Lo lascerei perdere se fossi in te.

AGGIORNAMENTO 2:

Molto bene: dal tuo post originale non sono riuscito a capire quale sia stata la tua esperienza con altre lingue.

"Alta aspettativa di qualità" implica che ritieni che Eiffel sosterrà la qualità a livello linguistico in un modo che non puoi duplicare con altre lingue. Non sarei d'accordo con quello. La qualità del codice ha più a che fare con l'abilità e le pratiche degli sviluppatori che con il linguaggio stesso.

Design By Contract è interamente ipervenduto, IMO. Ho letto che spesso è spento in produzione perché rappresenta un successo nelle prestazioni. Se questo è vero per te, in che altro modo ti aspetti che Eiffel contribuisca alla qualità?

Mi assicurerei che il client per cui stai scrivendo questa applicazione capisca le conseguenze complete che porterà una decisione con Eiffel: un pool limitato di sviluppatori per mantenerlo, uno staff emarginato dall'uso di una lingua morta , ecc. Assicurati di non esagerare a causa di un desiderio soggettivo.