La generazione del codice aumenta la qualità del codice?

I generatori di codice non possono generare codice migliore della persona che ha scritto il generatore.

La mia esperienza con i generatori di codice è che vanno bene finché non è necessario modificare il codice generato . Se riesci a mantenere questa regola, allora sei a posto. Ciò significa che puoi rigenerare in modo affidabile quella parte del sistema con sicurezza e velocità, aggiungendo automaticamente più funzionalità se necessario. Immagino che possa contare per la qualità.

Una volta ho sentito un argomento per i generatori di codice che un singolo programmatore può produrre così tante linee di codice al giorno e con i generatori di codice, potrebbero produrre migliaia di linee! Ovviamente non è questo il motivo per cui stiamo usando i generatori.

Direi il contrario - presumendo che tu stia scrivendo applicazioni interessanti, la generazione del codice diminuisce la qualità del codice. La natura della generazione del codice ricompensa molto i framework cookie-cutter, esagerati, sovradimensionati che diventano molto difficili da gestire senza fare continuamente affidamento sullo strumento di generazione del codice per generare in continuazione mazzi di codice più grandi, più complessi e più brutti. Anche se può essere un buon strumento, in realtà non dovrebbe essere lo strumento principale nella scatola.

Penso che la generazione automatica del codice e la qualità del codice siano in qualche modo ortogonali e non necessariamente correlati.

La generazione di codice è semplicemente un modo per risolvere un compito tecnico specifico. Se il risultato è un aumento della qualità del codice dipende molto da quello che stai facendo.

La tua situazione è un buon esempio di generazione di codice che si traduce in un aumento della qualità del codice attraverso il recupero tempestivo di potenziali errori.

Posso darti un altro esempio quando la generazione automatica del codice diminuisce la qualità del codice. È fuori onnipotente Web Form di ASP.NET. Realizza la generazione automatica del codice traducendo una gerarchia di controlli dell'interfaccia utente in markup HTML, che è tutto tranne che stabile, prevedibile e gestibile.

Per trarre conclusioni, la generazione automatica del codice può aiutare ad aumentare la qualità del codice se usato correttamente.

La generazione del codice non influenza il codice qualità , di per sé, tanto quanto il codice consistenza .

Il codice generato sarà coerente tra le istanze di generazione. Se il generatore è progettato per emettere un codice di buona qualità, il codice generato sarà sempre di buona qualità. Se, tuttavia, il generatore di codice emette un codice di cattiva qualità, otterrai sempre un codice errato.

La generazione del codice può anche essere utilizzata per creare codice più veloce . Più veloce, tuttavia, non significa migliore ... Potrebbe solo significare che ottieni il tuo codice di cattiva qualità molto più rapidamente.

La generazione del codice è buona se:

• il codice generato non dovrebbe essere modificato
• il generatore di codice ti offre abbastanza flessibilità per fare ciò che devi fare
• la lingua di input per il generatore di codice è migliore (vale a dire DRY) rispetto a quello che altrimenti dovresti scrivere
• il generatore di codice crea un buon codice affidabile di cui non devi preoccuparti, anche se è prolisso

Quando questo è il caso, il codice di cui è necessario considerare la qualità è il codice che viene inserito nel generatore.

Una semplice misura della qualità è, per i tipici cambiamenti nei requisiti, quanta modifica manuale devi fare. Meno è, meglio è.

Maggiore qualità del codice a causa di DRY (Non ripeterti).

Le regole di generazione del codice sono scritte una volta; non sono codificati per ogni istanza di codice generato, e quindi riducono il potenziale di errore umano nel copiare / incollare il contenuto con leggere modifiche.

Suppongo che tu intenda generatori di codice proprietario manipolati per uso interno specifico, altrimenti qualsiasi codice macchina non è un generatore di codice. Ma ecco qua:

PensochesiamoltodiscutibilecheilgrafodeinodiinBlueprintssiapiùfaciledamantenereemoltomenosoggettoaerroririspettoalcodiceGLSL/HLSLchegenera(echealtrimentiavrebbedovutoesserescrittoamano).

Èanchemoltopiùproduttivotrovarenuovishaderpoichéottieniunriscontrovisivointemporealesucomeappareilrisultatofinalementremodifichiilgrafico.PreferireisicuramentemantenereinquestomodomigliaiadishaderrappresentaticongraficinodalialpostodelcodiceGLSL/HLSL,einrealtàhopiùfamiliaritàconlascritturadiGLSL/HLSLcheconBlueprints.Pensochesiapraticamenteimpossibiledacausarecomeunbugimportanteoltreaqualchepiccoloinconvenientevisivocheprobabilmenteavresticatturatosubitoperchéil"linguaggio visivo" impone vincoli sensibili con spesso uno stile puramente funzionale che non ti permette, per esempio, di crash uno shader, almeno AFAIK (non sono un esperto di Blueprints).

Non c'è nemmeno il "codice" da mantenere più. Basta posizionare i nodi all'interno di un grafico e disegnare i collegamenti tra loro e, voilà, genera codice shader per te. Chi mantiene questa roba e dice " Sai, la mia vita sarebbe molto più semplice e avrò molto più tempo libero se questo fosse appena scritto nel codice GLSL invece di usare i Blueprint. " Probabilmente mai.

Detto questo, mi sono imbattuto nella mia parte di generatori di codice proprietari che hanno reso la vita più difficile, facendomi apprendere questo stupido linguaggio meta che ha vantaggi molto limitati, se ce ne sono, sulla scrittura del codice nella lingua del codice generato. Per me, un segno rivelatore della generazione di codice che è uno shite è uno che fa poco più che ridurre una piccola quantità di standard e in realtà non riduce la possibilità di errori. Sai che è particolarmente shit se introduce in realtà nuovi modi per causare bug che la lingua originale non aveva. Ma ci sono casi per la generazione del codice, come sopra, dove l'aumento della produttività è così massiccio, rendendo le cose meticolose che costano molto tempo ora costano pochi centesimi, che nessuno lo userebbe mai e poi guarderanno indietro.

Per me c'è un argomento più legittimo per lo sviluppo proprietario di Blueprints nel team di Epic rispetto a molti linguaggi di programmazione superflui creati per il grande pubblico che a malapena portano qualcosa di nuovo alla tavola.

Direi che nel tuo caso potrebbe aumentare un po 'la qualità, ma riduce di molto i tempi di sviluppo. A volte il codice generato è instabile, scomodo o semplicemente cattivo. In questi casi, il codice generato può ridurre la qualità e aggiungere più tempo di test di testing / fixing / regressione al progetto. E alcuni compiti sono troppo complessi per essere generati facilmente: il generatore diventa un intero sistema separato (probabilmente più grande e più complesso del progetto principale) a se stesso.

I generatori di codice vanno bene, ma fai attenzione con loro!

Lavoravo in un negozio che si basava molto sulla generazione del codice. Nella mia mente ha reso il codice per il progetto molto uniforme. E a tale riguardo, la qualità era OK.

Tuttavia, quando non ti è più permesso scrivere codice personalizzato perché tutto deve passare attraverso il generatore, penso che tu perda un po 'il vantaggio di essere un programmatore.

Quindi penso che questo sia un argomento di spada a doppio taglio di sicuro. Sì, i generatori sono grandi perché riducono gli errori e aumentano gli standard di codice, tuttavia, rendono anche "un po '" stupidi i programmatori, perché dipendono dai generatori invece di dover sporcarsi le mani.

Solo i miei 2 centesimi.

Oltre alla risposta di Martin, vorrei aggiungere che la generazione del codice SQL è molto buona quando si lavora in base al record (selezionare * dalla tab1 in cui tab1.pkcolumn =: parametro, aggiornamento tab1 impostato [qualsiasi numero di colonne] dove tab1.pkcolumn =: parametro, ecc.). E il tuo ORM brillerà in quello scenario, perché l'SQL che deve essere generato è davvero ripetitivo.

Le mie preoccupazioni principali sono le metaqueries - query sulle proprietà dell'oggetto che l'ORM traduce in SQL usando qualunque algoritmo. Le metaqueries molto simili possono generare SQL completamente diverso e non si garantisce che questo SQL generato sia performativo.

Un linguaggio metaquery che si traduce in un'altra lingua (SQL) che si traduce in un piano di query per eseguire efficacemente la raccolta dei dati. E il risultato generato deve essere oggetti, quindi l'ORM deve istanziare gli oggetti interessati - in modo che possa attivare un'altra pioggia di query per riempire gli attributi degli oggetti non portati dalla metaquera stessa ...

Sono totalmente d'accordo con chi dice che la generazione del codice va bene fintanto che non devi mai modificare (preferibilmente, non devi mai guardare) il codice generato.

Se possiamo accettare che il codice generato sia approssimativamente lo stesso numero di righe scritto a mano, e se possiamo dire che non contiene errori, allora il numero di righe che potrebbero potenzialmente contenere bug diminuito. Ergo, la qualità del codice dovrebbe essere aumentata.

Addendum: ovviamente, altri fattori, come il tempo di esecuzione, possono avere un ruolo.

Personalmente, ho scritto un bel po 'di generatori di codice, ma mai come approccio iniziale.

È sempre stato quando ho notato un pattern ripetitivo nel codice esistente, quindi il mio generatore prende del codice esistente quando aggiunge un nuovo codice, ma simile, e parametrizza alcune parti variabili di esso.

In questo senso, il mio codice generato è quasi identico al codice scritto a mano esistente (eccetto che tende a essere visivamente migliore e più uniforme, che trovo sia di grande leggibilità, se mai deve essere guardato).

Btw, sostengo l'inserimento di commenti di apertura / chiusura che indicano che il codice è stato generato, inclusi i dettagli dello strumento e del suo manutentore.