nel dubbio sull'uso di generatori di codice

La capacità di astrarre è uno degli strumenti più potenti del cervello umano. Permette di gestire sistemi complessi come entità semplici, a condizione che le astrazioni con cui lavora siano adatte.

Questo concetto è molto spesso applicato alla programmazione, perché inevitabilmente dobbiamo gestire sistemi complessi. Persino Java come linguaggio è già un'astrazione della JVM, che a sua volta è un'astrazione della macchina attuale su cui stai lavorando. SQL è un'astrazione di database relazionali, che a loro volta sono un'astrazione di archiviazione.

Tutto questo funziona bene, perché pensi in termini di concetti in un livello di astrazione e questo livello è separato dagli strati sottostanti attraverso una barriera di astrazione . Questo è spiegato molto bene in SICP .

Basandosi su questo è l'approccio piuttosto comune di astrazione dell'architettura e dell'infrastruttura. Le librerie che fanno ciò vengono comunemente chiamate framework (anche se oggigiorno tutto viene definito come un framework).
Una cosa che dovrai accettare con i framework è che devi pensare all'interno del livello di astrazione che forniscono. Il modo in cui lavorano internamente non ti riguarda (assumendo che lavori come specificato) tranne che per curiosità personale.

È importante capire cosa fa un componente software, non come . In effetti affidarsi a come è un buon modo di spararti ai piedi. Stare sulle spalle dei giganti va bene.

Ora torniamo ai generatori di codice: i generatori di codice sono in qualche modo uno strumento di astrazione. Tu dici: Voglio un controller per questo e quello, e zooooom è lì. Non devi pensare a come si collega al resto dell'infrastruttura, perché tutto ciò è astratto. Questo è buono.
Tuttavia, in precedenza ho menzionato il concetto di barriere di astrazione . Un problema intrinseco dei generatori di codice è che non forniscono alcuna barriera di astrazione. Tutte le cose di cui hanno bisogno, non te le nascondono, ma invece te le mettono in faccia. E tu hai un codice che consiste in parti che devi cambiare e parti che non devi cambiare (purché tu rimanga nello stesso livello di astrazione).

In alcune lingue, essendo Java l'esempio canonico, i generatori di codice sono inevitabili se si desidera raggiungere determinati livelli di astrazione. Ma fintanto che hai una chiara comprensione di quale sia lo scopo del codice che generi e conosci le parti da non toccare, sei dalla parte della sicurezza.

Nel libro "The Pragmatic Programmer", vi è un intero capitolo dedotto per il problema che stanno menzionando La loro risposta è chiara: non usare codice generato che non capisci.

Un approccio probabilmente più pragmatico ( pun intended ) è: Se devi usare un codice generato che non capisci, per l'amor di dio, non toccarlo.

Ora sto entrando nel mondo del linguaggio assembly, e lo sono supposto di utilizzare diverse tecnologie come editor di testo, linker, assemblatori.

Sto imparando a usare quelli, il che è, direi, molto efficiente quando si tratta di portare a termine il lavoro.

È solo che, sono venuto dalla vecchia scuola di programmazione dove puoi inserire manualmente tutte le istruzioni su un pannello frontale, che è in qualche modo buono perché capisci il tuo programma CHE BENE.

Ma con questa roba del linguaggio assembly, con i generatori di codice dall'assemblatore, posso creare il programma senza toccarlo interruttori (preso però la parte di debugging). capisco il flusso dell'applicazione, ma non nella misura in cui posso capire cosa fa ogni bit.

Per farla breve, sto usando i generatori senza VERAMENTE capire bene il codice. Voglio solo chiedere se questo è un cattiva strada / pratica o va bene perché vogliamo PRODUTTIVITÀ?