Ci sono vantaggi nel codificare i valori dei dati in un programma?

13

Sono un programmatore autodidatta, principiante, quindi mi scuso se non inchiodo il gergo del programmatore.

Sto lavorando a un progetto in cui sto fornendo dati, che verranno continuamente aggiornati, agli sviluppatori che essenzialmente creeranno uno strumento per generare report dalle query sui dati.

Sembra che tutti i soggetti coinvolti pensino di dover codificare i valori dei dati (non lo schema, ma i domini / i valori stessi) nel programma di generazione dei report.

Ad esempio, supponiamo di riferire sul personale; il rapporto verrebbe suddiviso in categorie, con un'intestazione per ciascun dipartimento, e quindi sotto ciascuna rubrica ci saranno sottotitoli di titoli di lavoro, e poi sotto ogni sottovoce ci sarà un elenco di dipendenti. Gli sviluppatori vogliono codificare i dipartimenti e i titoli di lavoro. D'altra parte, penso che potrebbero / interrogare quelle cose in fase di esecuzione, ordinare i record per loro e generare intestazioni di report in modo dinamico in base a quali valori ci sono.

Poiché l'elenco dei potenziali valori cambierà nel tempo (ad esempio, i reparti verranno creati / rinominati, verranno aggiunti nuovi titoli di lavoro), il codice dovrà essere continuamente aggiornato. Mi sembra che potremmo saltare i passaggi di manutenzione del codice e organizzare dinamicamente i rapporti.

Dal momento che non sono uno sviluppatore, mi chiedo cosa mi manchi. Quali vantaggi potrebbero esserci per codificare i valori in uno strumento come questo? In genere è così che vengono progettati i programmi?

— Tom
fonte

1

possibile duplicato di Rimozione di valori codificati e design difensivo vs YAGNI

— moscerino

I campi incrociati dei rapporti indicano che i valori nelle righe devono apparire come colonne?

— Tulains Córdova,

1

@Brendan - Se si codificano i valori nel report, è necessario modificare l'elenco in DUE posizioni (origine dati e report) mentre se il report è dinamico, è necessario modificarlo solo in una posizione (report) .

— Kwah

1

@Brendan perché dovresti finire con tre posizioni? Forse la mia comprensione è errata ma sto immaginando una query sql per recuperare i dati da un database, l'applicazione aggregherà / raggrupperà i valori restituiti, ad esempio, dal dipartimento. Se si desidera avere l'overhead di più query db, è possibile selezionare dipartimenti / titoli di ruolo distinti, se proprio lo si desidera. In nessun momento i dati esistono in più di una posizione: il report è guidato dai dati.

— kwah

1

@Brendan Sono anche in disaccordo con la tua definizione di essere in un posto - il modo in cui lo descrivi è in più posizioni, sparsi in tutto il codice sorgente.

— kwah

9

Wikipedia:

L'hard coding (anche hard-coding o hardcoding) si riferisce alla pratica di sviluppo del software di incorporare ciò che, forse solo in retrospettiva, può essere considerato un dato di input o di configurazione direttamente nel codice sorgente di un programma o di un altro oggetto eseguibile o formattazione fissa di i dati, invece di ottenere quei dati da fonti esterne o generare dati o formattarli nel programma stesso con l'input fornito.

La codifica hardware è considerata un antipattern.

Considerato un anti-pattern, la codifica rigida richiede che il codice sorgente del programma venga modificato ogni volta che cambiano i dati di input o il formato desiderato, quando potrebbe essere più conveniente per l'utente finale cambiare i dettagli in qualche modo al di fuori del programma.

A volte non puoi evitarlo, ma dovrebbe essere temporaneo.

Spesso è richiesta una codifica rigida. I programmatori potrebbero non avere una soluzione di interfaccia utente dinamica per l'utente finale elaborato, ma devono comunque fornire la funzione o rilasciare il programma. Questo di solito è temporaneo ma risolve, in un senso a breve termine, la pressione per consegnare il codice. Successivamente, viene eseguito il softcoding per consentire a un utente di trasmettere parametri che consentono all'utente finale di modificare i risultati o i risultati.

La codifica dei messaggi rende difficile l'internazionalizzazione di un programma.
I percorsi di hardcoding rendono difficile adattarsi a un'altra posizione.

L'unico vantaggio dell'hardcoding sembra essere la consegna rapida del codice.

— Tulains Córdova
fonte

5

OK, ma "l'unico vantaggio" è spesso estremamente importante. Le decisioni di progettazione nella programmazione spesso riguardano il compromesso tra prove future e consegna rapida ora e, come tale, la codifica rigida può essere una scelta perfettamente accettabile. A volte non è difficile codifica è una scelta cattiva progettazione.

-1 Non penso che questa sia una risposta utile. Sostanzialmente dice che "incorporare i valori nel codice sorgente in modo inappropriato" è inappropriato. Penso che l'OP voglia una guida su quando le cose potrebbero appartenere al codice sorgente e quindi non rientrare nella definizione di Wikipedia.

— Nathan Cooper,

La codifica rigida dovrebbe essere una parte vitale del tuo processo e considerandolo un anti-pattern è obsoleto nell'era dei micro-servizi, con il tutorial di Angular Tour of Heroes che è un esempio di alto profilo di un'enorme software house che incorpora direttamente o addirittura impone come un passaggio intermedio. Inoltre, quando passi a dati dinamici, dovresti comunque conservare alcuni dati codificati come fallback, forse controllati da una variabile di ambiente o persino da un comando booleano sul codice stesso, in modo che bug e problemi di sicurezza possano essere adeguatamente isolati linea.

— Cosa c'è in una ricerca su Google il

24

Veramente? Non è possibile utilizzare casi validi?

Anche se concordo sul fatto che l' hard-coding è generalmente un anti-pattern o almeno un cattivo odore di codice , ci sono molti casi in cui ha senso:

semplicità ( YAGNI ),
l'input è effettivamente costante e non cambierà mai (ovvero rappresenta una costante naturale o aziendale o un'approssimazione di uno. es. 0, PI, ...),
software incorporato (vengono in mente i vincoli di memoria e allocazione),
software sicuro (questi valori non sono disponibili e / o facili da decodificare o decodificare, ad esempio token e sali crittografici),
codice generato (il tuo preprocessore o generatore è configurabile, ma sputa codice con valori hardcoded),
e probabilmente qualche altro.

Ancora un anti-pattern ? Quindi è un eccesso di ingegneria ! Riguarda l'aspettativa di vita del tuo software !!

Non che io stia dicendo che ci sono tutte ottime ragioni, e in genere mi oppongo ai valori codificati. Ma alcuni possono facilmente ottenere un pass per validi motivi.

E non supervisionare il primo per quanto riguarda la semplicità / YAGNI neanche pensando che sia banale: probabilmente non c'è motivo di implementare un parser pazzo e un controllo di valore per uno script semplice che fa un ottimo lavoro per un caso d'uso ristretto molto bene.

È difficile trovare l'equilibrio. A volte non prevedi che un software crescerà e durerà più a lungo del semplice script da cui è iniziato. Spesso però è il contrario: progettiamo troppo le cose e un progetto viene accantonato più velocemente di quanto tu possa leggere il programmatore pragmatico. Hai perso tempo e fatica sulle cose di quanto non fosse necessario un prototipo iniziale.

Queste sono le cose cattive con gli Anti-Pattern: sono presenti in entrambi gli estremi dello spettro e il loro aspetto dipende dalla sensibilità della persona che sta rivedendo il codice.

— haylem
fonte

È divertente, perché l'ho pilotato da solo, ed è stato molto più facile, veloce e pulito per me gestire i valori in modo dinamico. L'ho fatto in Python, mentre credo che il prodotto finale sarà codificato in Java, se questo fa la differenza. Mi è sembrato troppo ingegnerizzato quando ho codificato i valori, perché ogni colonna in arrivo doveva essere tracciata in più punti.

— Tom,

@ Tom: Stai dicendo che è stato più facile e veloce implementare (o persino riutilizzare) una libreria di ricerca della configurazione piuttosto che usare un valore hardcoded? Buon per te. Inoltre, non vedo come la tua ultima frase si adatti alla definizione di sovraingegneria. Sarebbe ovviamente disordinato, e ovviamente se è hardcoded e duplicato è anche peggio (che non era il punto della tua domanda, probabilmente ho frainteso, ma mi è sembrato che tu intendessi che il valore non era hard-coded sul posto ogni volta, ma in un unico punto del programma).

— haylem,

Ad ogni modo, sto solo sottolineando i casi in cui sarebbe valido. Sto anche sottolineando che sarebbe controverso nella mia ultima frase. Non puoi accontentare tutti e le squadre hanno persone con livelli di abilità variabili.

— Hayylem,

1

@ Tom, non venderti troppo corto. Sei decisamente d'accordo. Sembra più facile e meno dispendioso scrivere un algoritmo rapido per organizzare i dati guardando i campi Reparto e Titolo lavoro invece di codificare Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Sarebbe anche molto più difficile mantenere l'array hard coded in caso di introduzione di un nuovo dipartimento o titolo.

— Chris G,

1

Puoi avere cose più complesse che sono ancora sensibili al codice. Uno che mi viene in mente che ho scritto qualche anno fa erano tutte le possibili permutazioni di un insieme di valori. Avevo bisogno di trovare una direzione casuale casuale, scegliere una permutazione casuale e quindi prendere il primo risultato valido era di gran lunga la soluzione più efficiente e poiché era in un ciclo O (N ^ 3) contava l'efficienza.

— Loren Pechtel,

4

Ci sono volte in cui va bene inserire valori hard-code. Ad esempio, ci sono alcuni numeri come 0 o uno o vari valori n ^ 2-1 per maschere di bit che devono essere determinati valori a fini algoritmici. Consentire tali valori al configurabile non ha alcun valore e apre solo la possibilità di problemi. In altre parole, se cambiare un valore non farebbe altro che spezzare le cose, probabilmente dovrebbe essere codificato.

Nell'esempio che hai dato, non vedo dove l'hard-coding sarebbe utile. Tutto ciò che menzioni dovrebbe / dovrebbe già essere nel database, compresi i titoli. Anche le cose che guidano la presentazione (come l'ordinamento) possono essere aggiunte se non ci sono.

— JimmyJames
fonte

Grazie. L'ordinamento era l'unica preoccupazione che avevo. Tuttavia, nel nostro caso non importa e non ho nemmeno considerato che potrebbe essere aggiunto come un'altra tabella nel database.

— Tom,

1

Devo notare che la gestione di tutto questo nel DB è un'opzione. È inoltre possibile utilizzare file di configurazione o altre soluzioni, ma l'hardcoding sembra essere una scelta sbagliata. L'opzione DB viene spesso utilizzata perché è facile creare un'interfaccia per consentire alle opzioni di essere gestite dagli utenti. Ci sono anche strumenti come questo che sono specificamente progettati per questo scopo.

— JimmyJames,

-1

L'implementazione di una soluzione robusta che consenta valori che altrimenti potrebbero essere stati codificati in modo da essere configurabili dagli utenti finali richiede una solida convalida di tali valori. Hanno messo una stringa vuota? Hanno inserito qualcosa di non numerico dove avrebbe dovuto essere un numero? Stanno facendo l'iniezione SQL? Eccetera.

La codifica hardware evita molti di questi rischi.

Il che non vuol dire che l'hard-coding sia sempre, o spesso, una buona idea. Questo è solo uno dei fattori da prendere in considerazione.

— Topher Eliot
fonte