In che modo l'hard coding può essere considerato un odore di codice nell'era dei micro-servizi?

L'hard coding non è il vero problema. Se il tuo problema non ha bisogno di codice dinamico, aggiungere codice dinamico non risolve un problema.

Tuttavia, i problemi stessi sono dinamici e cambiano nel tempo. Quindi non è insolito finire con il bisogno che il codice sia dinamico.

Il vero problema è quando lasci che la conoscenza si diffonda in luoghi inappropriati. Se pensi:

• va bene con hard code, quindi
• va bene usare una soluzione statica, quindi
• va bene diffondere riferimenti a cose statiche in molti luoghi

bene ora hai causato un problema. Perché ora passare a una soluzione dinamica è un enorme dolore.

La differenza è sottile. Alcuni rifiutano di lavorare sempre staticamente perché è così facile da scivolare. Ma è la conoscenza, diffusa in modo inappropriato, a causare il vero problema. Più cose che sanno di qualcosa è più difficile che qualcosa cambi. Finché un cambiamento può essere fatto in un posto duro o morbido, in realtà non importa.

Come per i test. Non aggiungerlo in ritardo. L'eliminazione dei test lo rende più costoso e meno utile. Se riesci a testare presto ed essere statico bene. Per la maggior parte però è più semplice con soluzioni dinamiche.

Le soluzioni dinamiche possono risolvere problemi statici. I problemi possono diventare dinamici. Una soluzione dinamica può semplificare i test. Ma non si diventa dinamici gratuitamente. È un lavoro Non fidarti di nessuno che insiste che c'è solo un modo. Scopri da solo cosa ti costerà.

L'hard coding dovrebbe essere riservato agli invarianti .

Se sai che è improbabile che alcuni dati cambino, devi codificarlo con precisione.

const int numberOfStandardChessBoardSquares = 64;

Per tutto il resto, ci sono le configurazioni.

Ci sono validi motivi per scrivere su hard-code. Non calcoleresti Pi ogni volta che ne hai bisogno, perché quel calcolo è costoso. Piuttosto, decidi quale risoluzione vuoi e codifica una costante:

const double pi == 3.1415926535897;

Se si alza un sistema complesso che richiede un qualche tipo di modalità diagnostica, può essere utile disporre di una sorta di schema dati codificato nel codice di produzione in modo che sia possibile trasmettere i dati attraverso il proprio sistema con un'impronta digitale nota. Non si desidera questo tipo di dati in un file di configurazione soggetto a manomissioni e nell'improbabile caso che il modello di dati di base debba essere modificato, si dovrebbe semplicemente distribuire una nuova versione di produzione.

In assenza della necessità di una tale modalità diagnostica, i dati di test di questo tipo sono meglio conservati in un cablaggio di test o assemblaggio di test, dove possono essere tagliati dagli eseguibili di produzione prima della distribuzione.

Do people not understand that hard-coding as an intermediate step allows an additional stage of testing to be undertaken on highly scalable systems in a manner that removes outside services from the equation and/or helps isolate individual behaviours, or is there some hereforeto unconsidered problem?

Che cosa?

No, la codifica dura è un odore di codice, punto e basta.

Se possibile, farlo nei microservizi è un problema in più perché i microservizi tenderanno ad avere bisogno di maggiore configurabilità perché

1. C'è raramente un'istanza una . L'hard coding su un'istanza fallirà quando avrai due istanze / obiettivi / database / qualunque.
2. Di rado c'è una una locale. Non appena avrai hardcode stringhe / fusi orari, le cose si interromperanno una volta che sarai distribuito in quell'altra regione.
3. Raramente c'è un un host. I contenitori possono in qualche modo mitigare questo problema, ma non appena esegui l'hardcode del percorso del file o fai delle ipotesi sul tuo sistema operativo, fallirà quando cambi contenitori, server web o sistemi operativi o ...

Ma come tutti gli odori del codice - a volte segui l'odore e finisci in un posto che non è terribile. A volte un semplice valore hardcoded ha uno svantaggio molto piccolo. A volte può fornire qualcosa che non può andare storto. A volte è in un punto che dovrebbe essere completamente distrutto se l'assunzione del valore hard-coded cambia.

Anche se di solito si tratta solo di persone pigre.