Gibt es Vorteile, Datenwerte in einem Programm fest zu codieren?

13

Ich bin ein autodidaktischer, unerfahrener Programmierer, also entschuldige ich mich, wenn ich die Programmiersprache nicht verstehe.

Ich arbeite an einem Projekt, in dem ich Entwicklern Daten zur Verfügung stelle, die kontinuierlich aktualisiert werden. Diese erstellen im Wesentlichen ein Tool zum Generieren von Berichten aus Abfragen zu den Daten.

Es scheint, dass alle Beteiligten der Meinung sind, dass sie Datenwerte (nicht das Schema, sondern die Domänen / Werte selbst) in das Berichterstellungsprogramm fest einprogrammieren müssen.

Angenommen, wir berichten über Personal. Der Bericht wird in Kategorien unterteilt, mit einer Überschrift für jede Abteilung, und unter jeder Abteilungsüberschrift werden Unterüberschriften von Jobtiteln und unter jeder Unterüberschrift wird eine Liste von Mitarbeitern angezeigt. Die Entwickler möchten die Abteilungen und Berufsbezeichnungen fest codieren. Andererseits würde ich denken, dass sie diese Dinge zur Laufzeit abfragen könnten / würden, Datensätze nach ihnen sortieren und Berichtskopfzeilen dynamisch basierend auf den vorhandenen Werten generieren.

Da sich die Liste der potenziellen Werte im Laufe der Zeit ändert (z. B. werden Abteilungen erstellt / umbenannt, neue Berufsbezeichnungen hinzugefügt), muss der Code kontinuierlich aktualisiert werden. Es scheint mir, dass wir die Code-Wartungsschritte überspringen und die Berichte dynamisch organisieren könnten.

Da ich kein Entwickler bin, frage ich mich, was ich vermisse. Welche Vorteile könnte es haben, Werte in ein solches Tool fest zu codieren? Entwerfen sich Programme normalerweise so?

design architecture architectural-patterns dynamic-data Tom
quelle
1
mögliches Duplikat von Entfernen
Mücke
Handelt es sich um Kreuztabellen für Berichte, dh Werte in Zeilen sollten als Spalten angezeigt werden?
Tulains Córdova
1
@Brendan - Wenn Sie Werte im Bericht fest codieren, müssen Sie die Liste an ZWEI Stellen (Datenquelle und Bericht) ändern. Wenn der Bericht dynamisch ist, müssen Sie ihn nur an einer Stelle (dem Bericht) ändern. .
KWAH
1
@Brendan warum würdest du am Ende drei Standorte haben? Möglicherweise ist mein Verständnis falsch, aber ich stelle mir eine SQL-Abfrage zum Abrufen von Daten aus einer Datenbank vor. Die Anwendung aggregiert / gruppiert die zurückgegebenen Werte beispielsweise nach Abteilung. Wenn Sie bereit sind, den Aufwand für mehrere Datenbankabfragen zu haben, können Sie verschiedene Abteilungen / Rollentitel auswählen, wenn Sie dies wirklich möchten. Zu keinem Zeitpunkt sind die Daten an mehr als einem Ort vorhanden - der Bericht wird von den Daten gesteuert.
KWAH
1
@Brendan Ich bin auch nicht einverstanden mit Ihrer Definition, dass es an einem Ort ist - so wie Sie es beschreiben, ist es an mehreren Orten, die über den Quellcode verstreut sind.
KWAH

Antworten:

9

Wikipedia:

Hartcodierung (auch Hartcodierung oder Hardcodierung) bezieht sich auf die Softwareentwicklungspraxis des Einbettens von möglicherweise nur im Nachhinein als Eingabe- oder Konfigurationsdaten direkt in den Quellcode eines Programms oder eines anderen ausführbaren Objekts oder des festen Formatierens von die Daten, anstatt diese Daten von externen Quellen zu beziehen oder Daten zu generieren oder im Programm selbst mit der gegebenen Eingabe zu formatieren.

Hardcodierung wird als Antimuster angesehen.

Als Antimuster-Hardcodierung muss der Quellcode des Programms bei jeder Änderung der Eingabedaten oder des gewünschten Formats geändert werden, wenn es für den Endbenutzer möglicherweise bequemer ist, die Details außerhalb des Programms zu ändern.

Manchmal kann man es nicht vermeiden, aber es sollte vorübergehend sein.

Häufig ist eine harte Codierung erforderlich. Programmierer verfügen möglicherweise nicht über eine dynamische Benutzeroberflächenlösung für den Endbenutzer, müssen jedoch die Funktion bereitstellen oder das Programm freigeben. Dies ist in der Regel vorübergehend, löst jedoch kurzfristig den Druck, den Code bereitzustellen. Später wird eine Softcodierung durchgeführt, damit ein Benutzer Parameter weitergeben kann, mit denen der Endbenutzer die Ergebnisse oder das Ergebnis ändern kann.

  • Das Hardcodieren von Nachrichten erschwert die Internationalisierung eines Programms.
  • Hardcoding-Pfade erschweren die Anpassung an einen anderen Ort.

Der einzige Vorteil der Hardcodierung scheint die schnelle Lieferung von Code zu sein.

Tulains Córdova
quelle
5
OK, aber der "einzige Vorteil" ist oft enorm wichtig. Bei Designentscheidungen in der Programmierung geht es oft um den Kompromiss zwischen Zukunftssicherheit und schneller Lieferung. Daher kann Hardcodierung eine durchaus akzeptable Wahl sein. Manchmal ist keine harte Codierung eine schlechte Wahl für das Design.
-1 Ich denke nicht, dass dies eine hilfreiche Antwort ist. Grundsätzlich heißt es, dass das unangemessene Einbetten von Werten in den Quellcode unangemessen ist. Ich denke, das OP möchte eine Anleitung, wann Dinge in den Quellcode gehören und daher außerhalb Ihrer Wikipedia-Definition liegen.
Nathan Cooper
Die harte Codierung sollte ein wesentlicher Bestandteil Ihres Prozesses sein und in Anbetracht dessen, dass ein Anti-Pattern im Zeitalter der Mikrodienste veraltet ist, ist das Angular Tour of Heroes-Tutorial ein bekanntes Beispiel für ein riesiges Software-Haus, das direkt in den Prozess eingebunden ist oder ihn sogar beauftragt ein Zwischenschritt. Wenn Sie zu dynamischen Daten wechseln, sollten Sie weiterhin einige fest codierte Daten als Ersatz behalten, die möglicherweise von einer Umgebungsvariablen oder sogar einem Booleschen Umschalter im Code selbst gesteuert werden, damit Bugs und Sicherheitsprobleme ordnungsgemäß isoliert werden können Linie.
Was ist in einer Google-Suche
24

"Ja wirklich?" Keine möglichen gültigen Use Cases?

Ich stimme zu, dass Hardcodierung im Allgemeinen ein Anti-Pattern oder zumindest ein sehr schlechter Code-Geruch ist , aber es gibt viele Fälle, in denen dies sinnvoll ist:

  • Einfachheit ( YAGNI ),
  • Die Eingabe ist tatsächlich konstant und wird sich niemals ändern (dh sie stellt eine natürliche oder geschäftliche Konstante oder eine Annäherung an eine Konstante dar. zB 0, PI, ...).
  • eingebettete Software (Speicher- und Zuordnungsbeschränkungen fallen ein),
  • sichere Software (diese Werte sind nicht verfügbar und / oder können nicht einfach dekodiert oder rückentwickelt werden, z. B. kryptografische Token und Salze),
  • generierter Code (Ihr Präprozessor oder Generator ist konfigurierbar, spuckt jedoch Code mit fest codierten Werten aus),
  • und wahrscheinlich noch ein paar mehr.

Immer noch ein Anti-Pattern ? Also ist Over-Engineering ! Es geht um die Lebenserwartung Ihrer Software !!

Nicht, dass ich behaupte, dass es alle guten Gründe gibt, und im Allgemeinen würde ich hart codierten Werten widersprechen. Einige können jedoch aus triftigen Gründen leicht einen Pass erhalten.

Und übersehen Sie auch nicht den ersten Punkt in Bezug auf Einfachheit / YAGNI, indem Sie ihn für trivial halten: Es gibt wahrscheinlich keinen Grund, einen verrückten Parser und Wertprüfer für ein einfaches Skript zu implementieren, das einen Job für einen engen Anwendungsfall sehr gut erledigt.

Es ist schwierig, das Gleichgewicht zu finden. Manchmal ist nicht abzusehen, dass eine Software wächst und länger hält als das einfache Skript, mit dem sie gestartet wurde. Oft ist es jedoch umgekehrt: Wir überentwickeln Dinge und ein Projekt wird schneller eingestellt, als Sie den Pragmatischen Programmierer lesen können. Sie haben Zeit und Mühe mit Dingen verschwendet, die ein früher Prototyp nicht benötigte.

Das ist das Schlimmste bei Anti-Patterns: Sie sind in beiden Extremen des Spektrums vorhanden, und ihr Erscheinungsbild hängt von der Sensibilität der Person ab, die Ihren Code überprüft.

Haylem
quelle
Das ist lustig, weil ich dies selbst pilotiert habe und es für mich viel einfacher und schneller und sauberer war, mit den Werten dynamisch umzugehen. Ich habe es in Python gemacht, während ich glaube, dass das Endprodukt in Java codiert wird - wenn dies einen Unterschied macht. Es fühlte sich überarbeitet an, als ich die Werte fest einprogrammierte, da jede eingehende Spalte an mehreren Stellen nachverfolgt werden musste.
Tom
@Tom: Sie sagen, es war einfacher und schneller, eine Konfigurationssuchbibliothek zu implementieren (oder sogar wiederzuverwenden), als einen fest codierten Wert zu verwenden? Toll für dich. Ich verstehe auch nicht, wie Ihr letzter Satz zur Definition von Überentwicklung passt. Es würde sich offensichtlich chaotisch anfühlen, und wenn es hartcodiert und dupliziert ist, ist es noch schlimmer (was nicht der Punkt Ihrer Frage war, habe ich wahrscheinlich falsch verstanden, aber es schien mir, als ob Sie meinen, der Wert sei nicht festcodiert jedes Mal, aber an einem einzigen Punkt im Programm).
Haylem
Wie auch immer, ich weise nur auf Fälle hin, in denen es gültig wäre. Ich weise auch darauf hin, dass es in meinem letzten Satz umstritten wäre. Man kann nicht jedem gefallen und Teams haben Leute mit unterschiedlichen Fähigkeiten.
Haylem
1
@ Tom, verkaufe dich nicht zu kurz. Du bist definitiv auf etwas. Es klingt einfacher und weniger zeitaufwendig, einen schnellen Algorithmus zum Organisieren der Daten zu schreiben, indem Sie die Felder "Abteilung" und "Jobtitel" im Gegensatz zu "Festcodierung" betrachten Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Es wäre auch viel schwieriger, das fest codierte Array beizubehalten, falls eine neue Abteilung oder ein neuer Titel eingeführt würde.
Chris G
1
Sie können komplexere Dinge haben, die für Hardcode noch sinnvoll sind. Eines, das mir in den Sinn kommt, dass ich vor ein paar Jahren geschrieben habe, waren alle möglichen Permutationen einer Reihe von Werten. Ich musste eine zufällig gültige Richtung finden, eine zufällige Permutation auswählen und dann das erste gültige Ergebnis abrufen. Dies war bei weitem die effizienteste Lösung, und da es sich um eine O (N ^ 3) -Schleifeneffizienz handelte.
Loren Pechtel
4

Es gibt Zeiten, in denen es in Ordnung ist, Werte hart zu codieren. Zum Beispiel gibt es einige Zahlen wie 0 oder einen oder mehrere n ^ 2-1-Werte für Bitmasken, die für algorithmische Zwecke bestimmte Werte sein müssen. Das Zulassen solcher Werte für das konfigurierbare Element hat keinen Wert und eröffnet nur die Möglichkeit von Problemen. Mit anderen Worten, wenn das Ändern eines Werts nur zu Problemen führen würde, sollte er wahrscheinlich fest codiert werden.

In dem Beispiel, das Sie angegeben haben, sehe ich nicht, wo Hardcodierung nützlich wäre. Alles, was Sie erwähnen, würde / sollte sich bereits in der Datenbank befinden, einschließlich Überschriften. Sogar Dinge, die die Präsentation beeinflussen (wie die Sortierreihenfolge), können hinzugefügt werden, wenn sie nicht vorhanden sind.

JimmyJames
quelle
Vielen Dank. Sortierreihenfolge war die einzige Sorge, die ich hatte. In unserem Fall spielt es jedoch keine Rolle, und ich habe nicht einmal in Betracht gezogen, dass es als weitere Tabelle in der Datenbank hinzugefügt werden könnte.
Tom
1
Ich sollte beachten, dass die Verwaltung all dies in der DB eine Option ist. Sie können auch Konfigurationsdateien oder andere Lösungen verwenden, die Hardcodierung scheint jedoch eine schlechte Wahl zu sein. Die DB-Option wird häufig verwendet, da es einfach ist, eine Schnittstelle zu erstellen, über die die Optionen von Benutzern verwaltet werden können. Es gibt auch Tools wie dieses, die speziell für diesen Zweck entwickelt wurden.
JimmyJames
-1

Die Implementierung einer robusten Lösung, die es den Endbenutzern ermöglicht, Werte zu konfigurieren, die ansonsten fest programmiert worden wären, erfordert eine robuste Validierung dieser Werte. Haben sie eine leere Zeichenfolge eingegeben? Haben sie etwas Nicht-Numerisches eingegeben, wo es eine Zahl hätte sein sollen? Tun sie SQL Injection? Etc.

Durch Hardcodierung werden viele dieser Risiken vermieden.

Was nicht heißt, dass Hardcodierung immer oder sogar oft eine gute Idee ist. Dies ist nur einer der Faktoren, die berücksichtigt werden müssen.

Topher Eliot
quelle