La generazione del codice aumenta la qualità del codice?


12

Sostenendo per la generazione di codice, sto cercando alcuni esempi di modi in cui aumenta la qualità del codice. Per chiarire cosa intendo per generazione di codice, posso parlare solo di un mio progetto:

Utilizziamo i file XML per descrivere le relazioni tra entità nel nostro schema di database, quindi ci aiutano a generare il nostro framework ORM e i moduli HTML che possono essere utilizzati per aggiungere, eliminare e modificare entità.

A mio avviso, aumenta la qualità del codice perché l'errore umano è ridotto. Se qualcosa viene implementato in modo errato, viene interrotto nel modello, il che è positivo perché l'errore potrebbe apparire prima poiché anche il codice più generato viene interrotto.

Da quando mi è stata chiesta la definizione di qualità del codice , vorrei chiarire che cosa intendevo per qualità del software .

Qualità del software : non è un attributo ma molti, ad esempio efficienza, modificabilità, leggibilità, correttezza, solidità, comprensibilità, usabilità, portabilità ecc. Che si influenzano a vicenda.


3
Qual è la tua definizione di qualità del codice?
NoChance,

@EmmadKareem Ho aggiunto una breve definizione alla domanda originale.
platzhirsch,

1
Penso che la generazione automatica di codice contribuirà ad aumentare la coerenza e l'uniformità del codice. In alcuni casi ciò aumenta la qualità, ma non credo che sia un problema.
joshin4colours

Risposte:


38

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 devi mai modificare il codice generato . Se riesci a rispettare quella 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 secondo cui un singolo programmatore può produrre così tante righe di codice al giorno e con i generatori di codice potrebbero produrre migliaia di righe! Ovviamente non è questo il motivo per cui stiamo usando i generatori.


6
+ la sezione in corsivo mille volte. I generatori di codice dovrebbero funzionare come il tuo compilatore o il meccanismo del modello C ++: non dovresti mai modificare manualmente il loro output. L'unica volta che dovresti mai leggere l'output è se sospetti un bug.
anon

1
È un peccato non poter votare più ...
Fabricio Araujo,

@anon: gli omani non dovrebbero generalmente modificare l'output di generatori di codice o compilatori, ma a volte può essere perfettamente ragionevole avere un processo di compilazione che comporta l'esecuzione di un pezzo di codice generato dalla macchina attraverso un programma che applica alcune modifiche ad esso. Ci sono anche occasioni in cui potrebbe essere necessario che una modifica umana modifichi l'output di un processo di compilazione se è necessario patchare il codice in campo mentre si modifica un numero minimo di byte, ma quando il codice viene modificato a mano in questo modo si dovrebbe archivia anche tutti i file dal processo di compilazione (non solo sorgente!) e ...
supercat

... aggiorna anche il codice sorgente in modo che corrisponda alla semantica del codice oggetto modificato manualmente.
supercat

20

Direi il contrario : supponendo che tu stia scrivendo applicazioni interessanti, la generazione del codice diminuisce la qualità del codice. La natura della generazione del codice premia i framework molto cookie-cutter, esagerati e sovra-specificati che diventano molto difficili da gestire senza affidarsi continuamente allo strumento di generazione del codice per generare continuamente gruppi di codice più grandi, più complessi e più brutti. Sebbene possa essere un buon strumento, in realtà non dovrebbe essere lo strumento principale nella confezione.


3
D'accordo, la spazzatura che esce da alcuni ORM (spazzatura dal punto di vista di qualcuno che sa come scrivere codice di database ben funzionante) è un buon esempio. Spesso funziona abbastanza per qualcuno che non sa cosa sta facendo per pensare che funzioni. E i nuovi programmatori non hanno la capacità di fare le cose più difficili che devono essere fatte al di fuori del generatore perché non capiscono i concetti di base.
HLGEM,

1
Ooh, +1 o -1 .... da un lato la generazione del codice è molto utile per rimuovere il codice noiosamente ripetitivo in cui hai una definizione che è semplicemente espansa in codice, ma poi hai ragione che viene abusato in tutti i modi di complessità "risparmio di tempo" che finisce con un anti-pattern in sé.
gbjbaanb,

13

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

La generazione del codice è semplicemente un modo per risolvere un compito tecnico specifico. Il fatto che si traduca in una maggiore qualità del codice dipende molto da cosa stai facendo.

La tua situazione è un buon esempio di generazione di codice che si traduce in una maggiore qualità del codice attraverso una rapida rilevazione di potenziali errori.

Posso fare un altro esempio quando la generazione automatica di codice riduce la qualità del codice. È uscito onnipotente ASP.NET WebForms. Fa la generazione automatica di codice traducendo una gerarchia di controlli dell'interfaccia utente in markup HTML, che è tutt'altro che stabile, prevedibile e gestibile.

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


11

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

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à costantemente di buona qualità. Se, tuttavia, il generatore di codice emette un codice di cattiva qualità, otterrai un codice costantemente cattivo.

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


6

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 (cioè DRY) di quella che altrimenti dovresti scrivere
  • il generatore di codice crea un buon codice affidabile di cui non devi preoccuparti, anche se è prolisso

In questi casi, il codice di cui è necessario considerare la qualità è il codice immesso nel generatore.

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


e che il codice generato sia mappato in modo trasparente all'originale, quindi non è necessario eseguire il debug sul codice generato.

@ Thorbjørn: sono d'accordo. Su un'app che ho dovuto mantenere c'è Fortran generato. La necessità di essere in grado di eseguire il debug è andata perduta nel corso degli anni, e sono l'unico abbastanza stupido da essere ancora in giro per rispondere alle chiamate di servizio :)
Mike Dunlavey,

Non sono d'accordo sul fatto che il generatore di codice dovrebbe essere flessibile. Deve essere mirato: fai bene una cosa, non molte cose. Dovrebbe essere necessario un input piccolo e ben definito e scrivere un pezzo di codice per te. Quando inizia a essere il programma, si dirige verso un fallimento.
gbjbaanb,

@gbjbaanb: sono d'accordo. Ecco perché ho detto abbastanza flessibilità . Per me, il problema non è il generatore di codice stesso, ma il linguaggio specifico del dominio che funge da input. Se tale DSL è troppo flessibile, l'utente deve nuotare tra le opzioni. Se non è abbastanza specifico, l'utente deve aggirare i suoi limiti. Posso dare esempi di questi.
Mike Dunlavey,

4

Maggiore qualità del codice grazie a 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 lievi modifiche.


A meno che non sia necessario modificare il codice generato, che non è affatto ASCIUTTO .... L'ho dovuto fare di recente, non è affatto piacevole . Se dovessi modificare di nuovo manualmente una base di codice generata automaticamente, caricherò tre volte !!!
Fabricio Araujo,

1
Non dovresti mai modificare quel codice; modificare il codice che ha generato la generazione stessa e aumentarlo con ulteriori regole, se necessario. La modifica del codice generato dovrebbe essere l'ultima risorsa.
EarlNameless

1
Mi piacerebbe avere quella scelta .. Non l'ho fatto.
Fabricio Araujo,

2

Suppongo che intendi generatori di codice proprietari gestiti a mano per uno specifico uso interno, poiché altrimenti qualcosa che non sia il codice macchina è un generatore di codice. Ma ecco qua:

inserisci qui la descrizione dell'immagine

Penso che sia molto discutibile che il grafico dei nodi in Blueprints sia più facile da mantenere e sia molto meno soggetto ad errori rispetto al codice GLSL / HLSL che genera (e avrebbe altrimenti bisogno di essere scritto a mano).

È anche molto più produttivo trovare nuovi shader poiché ottieni un feedback visivo in tempo reale di come appare il risultato finale quando cambi il grafico. Preferirei sicuramente mantenere migliaia di shader rappresentati con grafici nodali in questo modo invece del codice GLSL / HLSL, e in realtà ho più familiarità con la scrittura di GLSL / HLSL rispetto all'uso di Blueprints. Penso che in realtà sia praticamente impossibile causare come un grosso bug oltre a forse qualche piccolo problema visivo che probabilmente colpiresti subito perché il "linguaggio visivo" impone vincoli sensibili con spesso uno stile funzionale puro che non ti consente, per esempio, di crash a shader, almeno AFAIK (devo ammettere che non sono un esperto di progetti).

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

Detto questo, mi sono imbattuto nella mia parte di generatori di codice proprietari che ha reso la vita più difficile, facendomi imparare questo stupido meta linguaggio che ha benefici molto limitati, se del caso, sulla scrittura del codice nella lingua del codice che ha generato. Per me un segno rivelatore della generazione di codice che è merda è uno che fa poco più che ridurre una piccola quantità di piastra di caldaia e in realtà non riduce, diciamo, la possibilità di bug. Sai che è particolarmente merdoso se in realtà introduce nuovi modi per causare bug che la lingua originale non aveva. Ma ci sono casi per la generazione di codice, come sopra, in cui l'incremento della produttività è così massiccio, rendendo le cose meticolose che costano tempo enorme ora costano centesimi, che nessuno lo userebbe mai e poi guarderebbe indietro.

Per me c'è un argomento più legittimo per lo sviluppo proprietario di Blueprints tra il team di Epic rispetto a molti linguaggi di programmazione superflui là fuori fatti per il grande pubblico che a malapena portano qualcosa di nuovo sul tavolo.


1

Direi che nel tuo caso potrebbe aumentare leggermente la qualità, ma riduce notevolmente i tempi di sviluppo. A volte il codice generato è traballante, imbarazzante o semplicemente male. In questi casi, il codice generato può ridurre la qualità e aggiungere più tempo ai test di test / correzione / regressione al progetto. E alcuni compiti sono troppo complessi per essere facilmente generati: il generatore diventa un sistema completamente separato (forse più grande e più complesso del progetto principale) per sé.

I generatori di codice vanno bene, ma fai attenzione!


1

Lavoravo in un negozio che faceva molto affidamento sulla generazione del codice. Nella mia mente ha reso il codice per il progetto molto uniforme. E a questo proposito, la qualità era OK.

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

Quindi penso che questo sia sicuramente un argomento con spade a doppio taglio. Sì, i generatori sono fantastici perché riducono gli errori e aumentano gli standard di codice, tuttavia, rendono stupidi anche "alcuni" dei programmatori, perché fanno affidamento sui generatori invece di dover sporcarsi le mani.

Solo i miei 2 centesimi.


3
I programmatori del linguaggio assembly erano soliti dire questo sui compilatori. Quindi non sono sicuro che questo sia un grande argomento. Essere costretti a sporcarti le mani può essere una buona esperienza di apprendimento, ma una volta che hai imparato dovresti usare lo strumento più produttivo disponibile.
MarkJ

@MarkJ: A volte l'assemblaggio può effettivamente essere migliore di un linguaggio compilato per uniformità. Ad esempio, in alcuni sistemi embedded è utile poter codificare l'equivalente x=someValue ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;e farlo codificare con quattro istruzioni letterali XOR. Se il supporto di memorizzazione del codice può scrivere solo byte vuoti (0xFF), il costrutto sopra consentirà quattro modifiche arbitrarie al valore. Anche se si riscrivesse l'espressione x=someValue; x = x ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;e il compilatore valutasse tutti gli xor in fase di esecuzione, potrebbe comunque utilizzare un "complemento di tutti i bit" ...
supercat

... istruzioni piuttosto che un xor-immediato.
supercat

1

Oltre alla risposta di Martin, aggiungerei che la generazione del codice SQL è molto buona quando lavori in base al record (seleziona * da tab1 dove tab1.pkcolumn =: parametro, aggiorna 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 principali preoccupazioni sono le metaquery - query sulle proprietà degli oggetti che l'ORM traduce in SQL usando qualunque algoritmo. Metaquery molto simili possono generare SQL completamente diversi e non hanno alcuna garanzia che questo SQL generato sia performante.

Un linguaggio di 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 un oggetto, quindi l'ORM deve creare un'istanza degli oggetti interessati, in modo che possa innescare un'altra pioggia di query per riempire gli attributi degli oggetti non portati dalla stessa metaquery ...


0

Sono totalmente d'accordo con coloro che affermano 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 è approssimativamente lo stesso numero di righe scritte a mano e se possiamo dire che è privo di bug, allora il numero di righe che potrebbero potenzialmente contenere bug è diminuito. Ergo, la qualità del codice dovrebbe essere aumentata.


Addendum: ovviamente, altri fattori, come i tempi di esecuzione, possono svolgere un ruolo.

Personalmente, ho scritto alcuni generatori di codice, ma mai come approccio iniziale.

È sempre stato quando ho notato un modello ripetitivo nel codice esistente, quindi il mio generatore prende un po 'di codice esistente quando aggiunge un nuovo codice simile ma ne ha parametrizzato alcune parti variabili.

In tal senso, il mio codice generato è quasi identico al codice scritto a mano esistente (tranne per il fatto che tende a essere meglio strutturato e più uniforme, il che trovo aiuti la leggibilità, se mai dovesse essere guardato).

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.