Sono un autodidatta, un programmatore alle prime armi, quindi mi scuso se non inchiodo il gergo del programmatore.
Sto lavorando a un progetto in cui fornisco dati, che saranno continuamente aggiornati, agli sviluppatori che creeranno essenzialmente uno strumento per generare report dalle query sui dati.
Sembra che tutte le persone coinvolte pensino che hanno bisogno di codificare i valori dei dati (non lo schema, ma i domini / valori stessi) nel programma di generazione dei rapporti.
Ad esempio, supponiamo di riferire sul personale; il rapporto verrebbe suddiviso in categorie, con unintestazione per ogni reparto, quindi sotto ogni intestazione di reparto ci saranno i sottotitoli dei titoli di lavoro, quindi sotto ogni sottotitolo ci sarà un elenco di dipendenti. Gli sviluppatori vogliono codificare i reparti e i titoli di lavoro. Daltra parte, penserei che potrebbero / vorrebbero interrogare queste cose in fase di esecuzione, ordinare i record in base a loro e generare intestazioni di report dinamicamente in base a quale valore ci sono.
Poiché lelenco 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.
Dato che non sono uno sviluppatore, mi chiedo cosa mi manchi. Quali vantaggi potrebbero esserci per lhard-coding di valori in uno strumento come questo? È di solito questo il modo in cui sono progettati i programmi?
Commenti
- possibile duplicato di Rimozione hard-coded valori e design difensivo rispetto a YAGNI
- I rapporti sono campi incrociati, il che significa che i valori nelle righe dovrebbero apparire come colonne?
- @Brendan – Se inserisci i valori nel rapporto , ‘ dovrai modificare lelenco in DUE posizioni (origine dati e rapporto) mentre se il rapporto è dinamico, devi solo modificarlo in una posizione (il rapporto) .
- @Brendan perché dovresti ritrovarti con tre sedi? Forse la mia comprensione non è corretta, ma ‘ sto immaginando una query sql per recuperare dati da un database, lapplicazione aggregherà / raggrupperà i valori restituiti, ad esempio, dal dipartimento. Se ‘ sei disposto ad avere il sovraccarico di più query db, puoi selezionare reparti / titoli di ruolo distinti se lo desideri. In nessun momento i dati sono presenti in più di una posizione: il rapporto è basato sui dati.
- @Brendan Non sono inoltre daccordo con la tua definizione di un luogo, il modo in cui lo descrivi ‘ in più posizioni, sparse nel codice sorgente.
Risposta
Wikipedia:
Difficile codifica (anche hardcoding o hardcoding) si riferisce alla pratica di sviluppo del software di incorporare ciò che può, forse solo in retrospettiva, essere considerato un input o dati di configurazione direttamente nel codice sorgente di un programma o altro oggetto eseguibile, o formattazione fissa del dati, invece di ottenere quei dati da fonti esterne o generare dati o formattarli nel programma stesso con linput fornito.
Lhard-coding è considerato un antipattern .
Considerato un n anti-pattern, lhard coding richiede la modifica del codice sorgente del programma ogni volta che i dati di input o il formato desiderato cambiano, quando potrebbe essere più conveniente per lutente finale modificare i dettagli con qualche mezzo al di fuori del programma.
A volte non puoi evitarlo, ma dovrebbe essere temporaneo.
Lhard coding è spesso richiesto. I programmatori potrebbero non disporre di una soluzione di interfaccia utente dinamica per lutente finale, ma devono comunque fornire la funzionalità o rilasciare il programma. Questo di solito è temporaneo ma risolve, in un senso a breve termine, la pressione per fornire il codice. Successivamente, il softcoding viene eseguito per consentire a un utente di trasmettere parametri che danno allutente finale un modo per modificare i risultati o il risultato.
- Hardcoding di messaggi rende difficile internazionalizzare un programma.
- I percorsi di hardcoding rendono difficile ladattamento a unaltra posizione.
Lunico vantaggio dellhardcoding sembra essere la consegna rapida del codice.
Commenti
- OK , ma il ” unico vantaggio ” è spesso estremamente importante. Le decisioni di progettazione nella programmazione riguardano spesso il compromesso tra prove future e consegna rapida ora, e come tale, lhard coding può essere una scelta perfettamente accettabile. A volte non lhard coding è una cattiva scelta di design.
- -1 Non ‘ penso che questa sia una risposta utile. In sostanza dice che ‘ incorporare valori nel codice sorgente in modo inappropriato ‘ è inappropriato. Penso che lOP voglia una guida su quando le cose possono appartenere al codice sorgente e quindi non rientrare nella tua definizione di Wikipedia.
- Lhard coding dovrebbe essere una parte vitale del tuo processo e considerarlo un anti-pattern è obsoleto nel età dei micro-servizi, con il tutorial Angular Tour of Heroes che è un esempio di alto profilo di una grande software house che incoraggi direttamente o addirittura impone come passaggio intermedio. Inoltre, quando si passa a dati dinamici, è necessario conservare alcuni dati codificati come riserva, magari controllati da una variabile di ambiente o anche da un interruttore booleano sul codice stesso in modo che bug e problemi di sicurezza possano essere adeguatamente isolati riga.
Risposta
Davvero? Non sono possibili casi duso validi?
Anche se sono daccordo che hard-coding è generalmente un anti-pattern o almeno un pessimo odore di codice , ci sono molti casi in cui ha senso. Eccone alcuni.
-
Semplicità / YAGNI .
-
Costanti reali che in realtà non cambiano mai.
ovvero la costante rappresenta un naturale o attività costante o unapprossimazione di uno. (ad es. 0, PI, …)
-
Vincoli ambientali hardware o software
Nel software integrato, vengono in mente i vincoli di memoria e allocazione.
-
Software sicuro
Questi valori non sono disponibili e / o facili da decodificare o da decodificare, ad es. token e sali crittografici. (Nota che mantenerli hard-coded ha anche evidenti svantaggi …)
-
Codice generato
Il tuo preprocessore o generatore è configurabile, ma emette codice con valori hard-coded. Non insolito per il codice che si basa su motori di regole o se si dispone di unarchitettura basata su modello.
-
Codice ad alte prestazioni
In un certo senso questo è ” generato ” codice , anche se ancora più specializzato. per esempio. una tabella di ricerca / calcolo predeterminata con cambiamenti improbabili. Questo non è affatto insolito, ad esempio, nella programmazione grafica.
-
Configurazione e fallback
Sia nel codice effettivo che nei file di configurazione, è probabile che siano presenti valori di configurazione e fallback per diversi casi (quando la configurazione non è disponibile, quando un componente non risponde come previsto, ecc …). Tuttavia, in genere è meglio tenerlo fuori dal codice e cercarlo, ma potrebbero esserci casi in cui si desidera assolutamente avere un valore / reazione specifico a unazione / problema / situazione specifici.
-
E probabilmente qualcun altro …
Ancora un Anti-Pattern ? Quindi Over-Engineering ! Riguarda laspettativa di vita del tuo software !!
Non che sto dicendo ci sono tutte ottime ragioni, e in genere mi oppongo a valori hard-coded. Ma alcuni possono facilmente ottenere un passaggio per validi motivi.
E non sorvegliare il primo riguardante la semplicità / YAGNI anche pensando che sia banale: probabilmente non cè motivo di implementare un pazzo parser e value checker per un semplice script che fa un lavoro per un caso duso ristretto molto bene.
È difficile trovare il bilanciamento ance. A volte non prevedi che un software crescerà e durerà più a lungo del semplice script con cui è iniziato. Spesso, però, è il contrario: ingegnerizziamo troppo le cose e un progetto viene accantonato più velocemente di te leggi il Pragmatic Programmer. Hai sprecato tempo e fatica in cose di quanto non fosse necessario un prototipo iniziale.
Questo è il problema con Anti-Patterns: sono presenti in entrambi gli estremi dello spettro, e il loro aspetto dipende dal sensibilità della persona che rivede il tuo codice.
Personalmente, tenderei a seguire sempre la strada generica, non appena vedo che qualcosa potrebbe cambiare o se “Ho dovuto farlo più di una volta. Ma un approccio più preciso sarebbe valutare attentamente il costo dellhard-coding rispetto alla generazione o alla generazione del codice per quella specifica situazione.È lo stesso che determinare se unattività merita di essere automatizzata invece di eseguirla manualmente. Prendi in considerazione il tempo e il costo.
Commenti
- Questo ‘ è divertente, perché lho pilotato io stesso ed è stato molto più facile, veloce e pulito per me gestire i valori in modo dinamico. Lho 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 entrata doveva essere tracciata in più punti.
- @Tom: ‘ stai dicendo che è più facile e veloce implementare (o persino riutilizzare) una libreria di ricerca della configurazione piuttosto che utilizzare un valore hard-coded? per te. Inoltre, non ‘ per vedere come la tua ultima frase si adatta alla definizione di over-engineering. Sarebbe f anguilla ovviamente disordinata, e ovviamente se ‘ è hardcoded e duplicata ‘ è anche peggio (che non era il punto domanda domanda, probabilmente ho frainteso, ma mi è sembrato che tu volessi dire che il valore non era hardcoded in posizione ogni volta, ma in un singolo punto nel programma).
- Comunque, io ‘ mi limito a segnalare i casi in cui ‘ dovrebbe essere valido. ‘ faccio anche notare che ‘ sarebbe controverso nella mia ultima frase. Non puoi ‘ accontentare tutti e i team hanno persone con diversi livelli di abilità.
- @Tom, don ‘ t venditi troppo corto. ‘ stai decisamente facendo qualcosa. Sembra più facile e richiede meno tempo scrivere un algoritmo veloce per organizzare i dati esaminando i campi Reparto e Titolo di lavoro invece di codificare a freddo
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Sarebbe anche molto più difficile mantenere larray hardcoded nel caso in cui fosse stato introdotto un nuovo dipartimento o titolo. - Puoi avere cose più complesse che sono ancora sensibili allhardcode. Uno che mi viene in mente che ho scritto qualche anno fa era tutte le possibili permutazioni di un insieme di valori. Avevo bisogno di trovare una direzione valida 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) lefficienza era importante.
Risposta
A volte va bene inserire valori hardcoded. 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 per scopi algoritmici. Consentire tali valori al configurabile non ha alcun valore e apre solo la possibilità di problemi. In altre parole, se la modifica di un valore potrebbe solo rompere le cose, probabilmente dovrebbe essere hardcoded.
Nellesempio che hai fornito, non vedo dove sarebbe utile lhard-coding. Tutto ciò che dici dovrebbe / dovrebbe già essere nel database, comprese le intestazioni. Anche le cose che guidano la presentazione (come lordinamento) possono essere aggiunte se non sono presenti.
Commenti
- Grazie. Lordinamento era lunica preoccupazione che avevo. Tuttavia, nel nostro caso non ‘ importa, e ‘ non ho nemmeno pensato che potesse essere aggiunto come unaltra tabella nel database.
- Dovrei notare che la gestione di tutto questo nel DB è unopzione. Potresti anche usare file di configurazione o altre soluzioni ma lhardcoding sembra essere una scelta sbagliata. Il DB è spesso utilizzata perché ‘ è facile creare uninterfaccia per consentire la gestione delle opzioni da parte degli utenti. Sono disponibili anche strumenti come questo che sono specificamente progettati per questo scopo.
Answer
Implementando una soluzione robusta che consente ai valori che altrimenti sarebbero stati hardcoded di essere configurabili dalle richieste degli utenti finali valida convalida di tali valori. Hanno inserito una stringa vuota? Hanno inserito qualcosa di non numerico dove avrebbe dovuto essere un numero? Stanno facendo SQL injection? Ecc.
Lhard-coding evita molti di questi rischi.
Il che non vuol dire che lhard-coding sia sempre, o anche spesso, una buona idea. Questa è solo uno dei fattori da tenere in considerazione.