Sono generatori di codice di male?

StackOverflow https://stackoverflow.com/questions/202871

Domanda

Io uso MyGeneration con nHibernate per creare la base POCO di oggetti e file di mapping XML.Ho sentito alcune persone dire che pensare di generatori di codice non sono una buona idea.Qual è il miglior modo di pensare?È solo che la generazione del codice è male quando si genera migliaia di righe di non comprensibile codice?

È stato utile?

Soluzione

Il codice generato da un generatore di codice non dovrebbe (come generalizzazione) essere utilizzato in una situazione in cui viene successivamente modificato dall'intervento umano. Alcuni sistemi come i maghi su varie incarnazioni di Visual C ++ hanno generato codice che il programmatore avrebbe dovuto modificare a mano. Questo non era popolare in quanto richiedeva agli sviluppatori di scegliere il codice generato, comprenderlo e apportare modifiche. Significava anche che il processo di generazione era un colpo solo.

Il codice generato deve vivere in file separati da altri codici nel sistema e deve essere generato solo dal generatore. Il codice generato deve essere chiaramente contrassegnato come tale per indicare che le persone non devono modificarlo. Ho avuto occasione di fare parecchi sistemi di generazione di codice di un tipo o di un altro e Tutto del codice così generato ha qualcosa del genere nel preambolo: 

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

Generazione di codice in azione è un buon libro sull'argomento.

Altri suggerimenti

Generatori di codice sono grandi, il codice cattivo è cattivo.

La maggior parte delle altre risposte su questa pagina sono lungo le linee di "No, perché spesso il codice generato non è molto buona."

Questa è una scarsa risposta perché:

1) Generatori di strumento come tutto il resto, se abusare di loro, non la colpa strumento.

2) gli Sviluppatori tendono a sono orgogliosi della loro capacità di scrivere il codice una sola volta, ma non l'uso di generatori di codice per uno sconto progetti.

Utilizziamo un sistema di Generazione di Codice per la persistenza in tutti i nostri progetti Java e hanno migliaia di classi generate in fase di produzione.

Come un manager, io li amo perché:

1) Affidabilità:Non ci sono significative restanti bug nel codice.È stato così ampiamente testati e perfezionati nel corso degli anni, rispetto a quando il debug non mi preoccupo mai il livello di persistenza.

2) Normalizzazione:Tutti gli sviluppatori di codice è identico a questo riguardo c'è molto meno per un ragazzo di imparare quando raccogliendo un nuovo progetto da un collaboratore.

3) Evoluzione:Se dobbiamo trovare un modo migliore per fare le cose siamo in grado di aggiornare i modelli e aggiornamento di 1000 classi in modo rapido e coerente.

4) Rivoluzione:Se si passa a un altro la persistenza di sistema, in futuro, il fatto che ogni singolo persistente classe è esattamente identico API rende il mio lavoro molto più facile.

5) Produttività:Si trova a soli pochi clic per creare un oggetto persistente sistema di metadati, che salva migliaia di noioso sviluppatore ore.

La generazione del codice è come usare un compilatore su un singolo caso, si potrebbe essere in grado di scrivere meglio ottimizzato in linguaggio assembly, ma su grandi numeri di progetti che si sarebbe piuttosto necessario che il compilatore di farlo per voi giusto?

Ci avvaliamo di un semplice trucco per garantire che le classi possono sempre essere riutilizzata senza perdere le personalizzazioni:ogni classe generata è astratto.Lo sviluppatore si estende con un calcestruzzo di classe, aggiunge la logica di business personalizzata e sostituisce qualsiasi metodi della classe base vuole diversi dallo standard.Se vi è un cambiamento nei metadati, egli è in grado di rigenerare la classe astratta in qualsiasi momento, e se il nuovo modello si rompe la classe di calcestruzzo con il compilatore, fargli sapere.

Il problema più grande che ho avuto con i generatori di codice è durante la manutenzione. Se si modifica il codice generato e si apporta una modifica allo schema o al modello e si tenta di rigenerare, è possibile che si verifichino problemi.

Un problema è se lo strumento non ti consente di proteggere le modifiche apportate al codice modificato, quindi le modifiche verranno sovrascritte.

Un altro problema che ho riscontrato, in particolare con i generatori di codice in RSA per i servizi Web, se si modifica troppo il codice generato, il generatore si lamenterà della mancata corrispondenza e si rifiuta di rigenerare il codice. Questo può accadere per qualcosa di semplice come cambiare il tipo di una variabile. Quindi sei bloccato nel generare il codice in un altro progetto e nel riunire i risultati nel tuo codice originale.

I generatori di codice possono essere un vantaggio per la produttività, ma ci sono alcune cose da cercare:

Ti consentono di lavorare nel modo in cui vuoi lavorare.

Se devi piegare il tuo codice non generato per adattarlo al codice generato, probabilmente dovresti scegliere un approccio diverso.

Esegui come parte della normale build.

L'output deve essere generato in una directory intermedia e non deve essere archiviato nel controllo del codice sorgente. L'ingresso deve essere registrato per il controllo del codice sorgente, tuttavia.

Nessuna installazione

Idealmente, controlli anche lo strumento per il controllo del codice sorgente. Fare in modo che le persone installino cose quando si prepara una nuova macchina per costruire è una cattiva notizia. Ad esempio, se si ramifica, si desidera poter eseguire la versione degli strumenti con il codice.

Se è necessario, creare un singolo script che prenderà una macchina pulita con una copia dell'albero dei sorgenti e configurerà la macchina come richiesto. Completamente automatizzato, per favore.

Nessun output di modifica

Non dovresti modificare l'output. Se l'output non è abbastanza utile così com'è, lo strumento non funziona per te.

Inoltre, l'output dovrebbe indicare chiaramente che si tratta di un file generato & amp; non dovrebbe essere modificato.

Output leggibile

L'uscita deve essere scritta & amp; formattato bene. Vuoi essere in grado di aprire l'uscita & Amp; leggilo senza troppi problemi.

#line

Molte lingue supportano qualcosa come una direttiva <=>, che consente di mappare il contenuto dell'output all'input, ad esempio quando si producono messaggi di errore del compilatore o quando si inserisce il debugger. Questo può essere utile, ma può anche essere fastidioso se non fatto davvero bene, quindi non è un requisito.

La mia posizione è che i generatori di codice non sono male, ma MOLTI usi di essi lo sono.

Se stai usando un generatore di codice per risparmiare tempo che scrive buon codice, quindi ottimo, ma spesso a volte non è ottimizzato, o aggiunge un sacco di sovraccarico, in quei casi penso che sia cattivo.

La generazione di codice potrebbe causare problemi se desideri mescolare il comportamento nelle tue classi. Un'alternativa altrettanto produttiva potrebbe essere attributi / annotazioni e riflessione sul runtime.

I compilatori sono generatori di codice, quindi non sono intrinsecamente dannosi a meno che non ti piaccia solo programmare in codice macchina grezzo.

Credo comunque che i generatori di codice dovrebbero sempre incapsulare completamente il codice generato. Cioè non dovresti mai modificare manualmente il codice generato, qualsiasi modifica dovrebbe essere fatta modificando l'input al generatore e rigenerando il codice.

Se è un generatore di codice cobol mainframe che Fran Tarkenton sta cercando di venderti, allora assolutamente sì!

Prima ho scritto alcuni generatori di codice - e ad essere sinceri mi hanno salvato il culo più di una volta!

Una volta che hai un oggetto chiaramente definito - raccolta - progettazione del controllo utente, puoi utilizzare un generatore di codice per costruire le basi per te, consentendo al tuo tempo di sviluppatore di essere usato in modo più efficace nella costruzione di cose complesse, dopo tutto, chi vuole davvero scrivere più di 300 dichiarazioni di proprietà pubblica e istanze variabili? Preferirei rimanere bloccato nella logica aziendale piuttosto che in tutte le attività ripetitive insensate.

L'errore che molte persone commettono quando usano la generazione del codice è di modificare il codice generato. Se tieni presente che se ritieni di dover modificare il codice, devi effettivamente modificare lo strumento di generazione del codice che è un vantaggio per la produttività. Se combatti costantemente il codice che viene generato finirà per costare la produttività.

I migliori generatori di codice che ho trovato sono quelli che ti consentono di modificare i template che generano il codice. Mi piace davvero Codesmith per questo motivo, perché è basato su modelli e i modelli sono facilmente modificabili. Quando scopri che c'è una carenza nel codice che viene generato, devi solo modificare il modello e rigenerare il tuo codice e dopo sarai sempre bravo.

L'altra cosa che ho scoperto è che molti generatori di codice non sono super facili da usare con un sistema di controllo del codice sorgente. Il modo in cui ci siamo aggirati è quello di controllare nei modelli piuttosto che nel codice e l'unica cosa che controlliamo nel controllo del codice sorgente generato è una versione compilata del codice generato (file DLL, principalmente ). Questo ti fa risparmiare un sacco di dolore perché devi solo controllare alcune DLL piuttosto che possibilmente centinaia di file generati.

Il nostro attuale progetto fa ampio uso di un generatore di codice. Ciò significa che ho visto sia il & Quot; ovvio & Quot; i vantaggi della generazione del codice per la prima volta - nessun errore del programmatore, nessun errore di battitura, migliore aderenza a uno stile di codifica standard - e, dopo alcuni mesi in modalità di manutenzione, i lati negativi imprevisti. Il nostro generatore di codice, infatti, inizialmente ha migliorato la qualità della nostra base di codice. Ci siamo assicurati che fosse completamente automatizzato e integrato con le nostre build automatizzate. Tuttavia, direi che:

(1) Un generatore di codice può essere una stampella. Nel nostro sistema ora abbiamo diverse enormi e brutte porzioni di codice difficile da mantenere, perché a un certo punto in passato era più facile aggiungere venti nuove classi al nostro file XML di generazione del codice, piuttosto che fare analisi e classe adeguate refactoring.

(2) Eccezioni alla regola ti uccidono. Usiamo il generatore di codice per creare diverse centinaia di classi Screen e Business Object. Inizialmente, abbiamo applicato uno standard su quali metodi potrebbero apparire in una classe, ma come tutti gli standard, abbiamo iniziato a fare eccezioni. Ora, il nostro file XML di generazione del codice è un enorme mostro, pieno di frammenti di codice Java in casi speciali che vengono inseriti in classi selezionate. È quasi impossibile analizzare o capire.

(3) Dato che gran parte del nostro codice viene generato, utilizzando i valori di un database, è diventato difficile per gli sviluppatori mantenere una base di codice coerente sulle loro singole workstation (poiché possono esserci più versioni del database). Il debug e il tracciamento attraverso il software sono molto più difficili e i neofiti del team impiegano molto più tempo a capire il & Quot; flow & Quot; del codice, a causa dell'ulteriore astrazione e delle relazioni implicite tra le classi. Gli IDE non possono rilevare relazioni tra due classi che comunicano tramite una classe generata da codice.

Probabilmente è abbastanza per ora. Penso che i generatori di codice siano fantastici come parte del toolkit individuale di uno sviluppatore; una serie di script che scrivono il codice del boilerplate facilita l'avvio di un progetto. Ma i generatori di codice non risolvono i problemi di manutenzione.

In alcuni (non molti) casi sono utili. Ad esempio se si desidera generare classi basate su dati di tipo ricerca nelle tabelle del database.

La generazione di codice è negativa quando rende più difficile la programmazione (IE, codice generato in modo scadente o un incubo di manutenzione), ma sono utili quando rendono la programmazione più efficiente.

Probabilmente non sempre generano un codice ottimale, ma a seconda delle tue necessità, potresti decidere che i salvataggi di sviluppatori salvati compensano alcuni problemi minori.

Detto questo, la mia più grande lamentela con i generatori di codice ORM è che la manutenzione del codice generato può essere una PITA se lo schema cambia.

I generatori di codice non sono male, ma a volte vengono utilizzati in situazioni in cui esiste un'altra soluzione (ovvero, istanziare un milione di oggetti quando una matrice di oggetti sarebbe stata più adatta e realizzata in poche righe di codice).

L'altra situazione è quando vengono utilizzati in modo errato o codificati male. Troppe persone giurano generatori di codice perché hanno avuto brutte esperienze a causa di bug o il loro malinteso su come configurarlo correttamente.

Ma di per sé, i generatori di codice non sono male.

-Adam

Sono come qualsiasi altro strumento. Alcuni danno risultati migliori di altri, ma spetta all'utente sapere quando usarli o meno. Un martello è uno strumento terribile se stai cercando di avvitare una vite.

Questa è una di quelle questioni molto controverse. Personalmente, penso che i generatori di codice siano davvero cattivi a causa del codice di merda non ottimizzato che la maggior parte di essi pubblica.

Tuttavia, la domanda è davvero una domanda a cui solo tu puoi rispondere. In molte organizzazioni, i tempi di sviluppo sono più importanti della velocità di esecuzione del progetto o persino della manutenibilità.

Usiamo generatori di codice per generare classi di entità di dati, oggetti di database (come trigger, proc memorizzati), proxy di servizio ecc. Ovunque vedi un sacco di codice ripetitivo che segue uno schema e un sacco di lavoro manuale, i generatori di codice possono aiutare. Ma non dovresti usarlo troppo nella misura in cui la manutenibilità è un dolore. Alcuni problemi sorgono anche se si desidera rigenerarli.

Strumenti come Visual Studio, Codesmith hanno i propri modelli per la maggior parte delle attività comuni e semplificano questo processo. Ma è facile da implementare da solo.

Può davvero diventare un problema con la manutenibilità quando devi tornare e non puoi capire cosa sta succedendo nel codice. Pertanto, molte volte devi valutare quanto sia importante portare a termine il progetto velocemente rispetto alla facile manutenibilità

manutenibilità < > processo di codifica semplice o veloce

Uso My Generation con Entity Spaces e non ho alcun problema. Se ho una modifica dello schema, rigenero solo le classi e tutto funziona perfettamente.

Servono da stampella che può disabilitare la tua capacità di mantenere il programma a lungo termine.

I primi compilatori C ++ erano generatori di codice che sputavano codice C (CFront).

Non sono sicuro che si tratti di un argomento a favore o contro generatori di codice.

Penso che Mitchel lo abbia colpito alla testa. La generazione del codice ha il suo posto. Ci sono alcune circostanze in cui è più efficace che il computer faccia il lavoro per te! Può darti la libertà di cambiare idea sull'implementazione di un particolare componente quando il costo di modifica del codice è ridotto. Naturalmente, è ancora probabilmente importante capire l'output del generatore di codice, ma non sempre. Abbiamo avuto un esempio di un progetto che abbiamo appena finito in cui un certo numero di app C ++ dovevano comunicare con un'app C # su named pipe. Per noi era meglio usare file piccoli, semplici, che definivano i messaggi e generassero tutte le classi e il codice per ciascun lato della transazione. Quando un programmatore stava lavorando sul problema X, l'ultima cosa di cui aveva bisogno era preoccuparsi dei dettagli di impianto dei messaggi e dell'inevitabile hit della cache che avrebbe comportato.

Questa è una domanda sul flusso di lavoro. ASP.NET è un generatore di codice. Il motore di analisi XAML in realtà genera C # prima che venga convertito in MSIL. Quando un generatore di codice diventa un prodotto esterno come CodeSmith, isolato dal flusso di lavoro di sviluppo, è necessario prestare particolare attenzione a mantenere sincronizzato il progetto. Ad esempio, se il codice generato è un output ORM e si apporta una modifica allo schema del database, sarà necessario abbandonare completamente il generatore di codice oppure sfruttare la capacità di C # di lavorare con classi parziali (che consentono di aggiungere membri e funzionalità a una classe esistente senza ereditarla).

Personalmente non mi piace la natura isolata / Alt-Tab dei flussi di lavoro del generatore; se il generatore di codice non fa parte del mio IDE, mi sento come se fosse un kludge. Alcuni generatori di codice, come Entity Spaces 2009 (non ancora rilasciato), sono più integrati rispetto alle generazioni precedenti di generatori.

Penso che la panacea allo scopo dei generatori di codice possa essere apprezzata nelle routine di precompilazione. C # e altri linguaggi .NET mancano di questo, sebbene ad ASP.NET piaccia ed è per questo che, diciamo, SubSonic funziona così bene per ASP.NET ma non molto altro. SubSonic genera il codice C # in fase di compilazione appena prima che inizi la normale compilazione ASP.NET.

Chiedi al tuo fornitore di strumenti (ad es. Microsoft) di supportare le routine di pre-build in modo più approfondito, in modo che i generatori di codice possano essere integrati nel flusso di lavoro delle tue soluzioni utilizzando i metadati, anziché gestirli manualmente come file di codice trasmessi esternamente che devono essere mantenuti in isolamento.

Jon

La migliore applicazione di un generatore di codice è quando l'intero progetto è un modello e tutto il codice sorgente del progetto viene generato da quel modello. Non sto parlando di UML e di cazzate correlate. In questo caso, il modello di progetto contiene anche un codice personalizzato.

Quindi l'unica cosa di cui gli sviluppatori devono preoccuparsi è il modello. Una semplice modifica architettonica può comportare la modifica istantanea di migliaia di righe del codice sorgente. Ma tutto rimane sincronizzato.

Questo è l'IMHO l'approccio migliore. Sembra utopico? Almeno so che non lo è;) Il prossimo futuro lo dirà.

In un recente progetto abbiamo creato il nostro generatore di codice. Abbiamo generato tutto il materiale della base di dati e tutto il codice di base per le nostre classi di controller di visualizzazione e visualizzazione. Sebbene il generatore abbia impiegato diversi mesi per essere costruito (principalmente perché questa era la prima volta che lo facevamo e abbiamo avuto un paio di false partenze) si è ripagato da solo la prima volta che l'abbiamo eseguito e generato il framework di base per l'intera app in una decina di minuti. Tutto questo era in Java, ma Ruby crea un eccellente linguaggio di scrittura del codice, in particolare per piccoli progetti di tipo unico. La cosa migliore era la coerenza del codice e l'organizzazione del progetto. Inoltre, devi pensare in anticipo al framework di base, il che è sempre positivo.

I generatori di codice sono fantastici supponendo che sia un buon generatore di codice. Soprattutto funzionando c ++ / java che è molto dettagliato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top