Ich bin ein autodidaktischer, unerfahrener Programmierer, daher entschuldige ich mich, wenn ich den Programmierjargon nicht nagle.
Ich arbeite an einem Projekt, in dem ich Entwicklern, die im Wesentlichen ein Tool zum Generieren von Berichten aus Abfragen zu den Daten erstellen, Daten zur Verfügung stelle, die kontinuierlich aktualisiert werden.
Es scheint, dass alle Beteiligten denken dass sie Datenwerte (nicht das Schema, sondern die Domänen / Werte selbst) in das Berichterstellungsprogramm fest codieren müssen.
Angenommen, wir berichten über Personal, der Bericht würde aufgeteilt in Kategorien mit einer Überschrift für jede Abteilung und dann unter jeder Abteilungsüberschrift werden Unterüberschriften von Berufsbezeichnungen und dann unter jeder Unterüberschrift 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 Berichtsheader dynamisch basierend auf welchem Wert generieren könnten Es gibt sie.
Da sich die Liste der potenziellen Werte im Laufe der Zeit ändert (z. B. werden Abteilungen erstellt / umbenannt, neue Jobtitel hinzugefügt), muss der Code kontinuierlich aktualisiert werden. Es scheint mir, dass wir die Schritte zur Codepflege überspringen und die Berichte dynamisch organisieren könnten.
Da ich kein Entwickler bin, frage ich mich, was mir fehlt. Welche Vorteile könnte es haben, Werte in ein solches Tool fest zu codieren? Ist dies normalerweise die Art und Weise, wie Programme entworfen werden?
Kommentare
- mögliches Duplikat von Entfernen von fest codierten Programmen Werte und defensives Design im Vergleich zu YAGNI
- Sind Berichtskreuztabellen, dh Werte in Zeilen sollten als Spalten angezeigt werden?
- @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 einem Ort (dem Bericht) ändern. .
- @Brendan, warum sollten Sie drei Standorte haben? Vielleicht ist mein Verständnis falsch, aber ich ‚ stelle mir eine SQL-Abfrage vor, um Daten aus einer Datenbank abzurufen. Die Anwendung aggregiert / gruppiert die zurückgegebenen Werte beispielsweise nach der Abteilung. Wenn Sie ‚ bereit sind, den Overhead mehrerer 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.
- @Brendan Ich bin auch nicht damit einverstanden, dass Sie ihn an einem Ort definieren – so wie Sie ihn beschreiben ‚ s an mehreren Stellen, verteilt über den Quellcode.
Antwort
Wikipedia:
Schwer Codierung (auch Hardcodierung oder Hardcodierung) bezieht sich auf die Softwareentwicklungspraxis des Einbettens von Daten, die möglicherweise nur im Nachhinein als Eingabe- oder Konfigurationsdaten betrachtet werden können, direkt in den Quellcode eines Programms oder eines anderen ausführbaren Objekts oder auf eine feste Formatierung des Daten, anstatt diese Daten aus externen Quellen zu erhalten oder Daten zu generieren oder im Programm selbst mit der angegebenen Eingabe zu formatieren.
Hardcodierung wird als Antimuster angesehen
Betrachtet a Bei einer Anti-Pattern-Hardcodierung muss der Quellcode des Programms jedes Mal geändert werden, wenn sich die Eingabedaten oder das gewünschte Format ändern, wenn es für den Endbenutzer möglicherweise bequemer ist, die Details auf irgendeine Weise außerhalb des Programms zu ändern.
Manchmal kann man es nicht vermeiden, aber es sollte vorübergehend sein.
Harte Codierung ist oft erforderlich. Programmierer haben möglicherweise keine dynamische Benutzeroberflächenlösung für den Endbenutzer ausgearbeitet, müssen jedoch die Funktion bereitstellen oder das Programm freigeben. Dies ist normalerweise nur vorübergehend, löst jedoch kurzfristig den Druck, den Code zu liefern. Später wird eine Softcodierung durchgeführt, damit ein Benutzer Parameter weitergeben kann, mit denen der Endbenutzer die Ergebnisse oder Ergebnisse ändern kann.
- Hardcodierung Die Anzahl der Nachrichten erschwert die Internationalisierung eines Programms.
- Hardcodierungspfade erschweren die Anpassung an einen anderen Speicherort.
Der einzige Vorteil der Hardcodierung scheint die schnelle Bereitstellung von Code zu sein.
Kommentare
- OK , aber der einzige Vorteil von “ “ ist oft enorm wichtig. Bei Entwurfsentscheidungen in der Programmierung geht es häufig um den Kompromiss zwischen Zukunftssicherheit und schneller Lieferung. Daher kann Hardcoding eine durchaus akzeptable Wahl sein. Manchmal ist nicht harte Codierung eine schlechte Wahl für das Design.
- -1 Ich halte ‚ nicht für eine hilfreiche Antwort. Es heißt im Wesentlichen, dass ‚ das unangemessene Einbetten von Werten in den Quellcode ‚ unangemessen ist. Ich denke, das OP möchte eine Anleitung dazu, wann Dinge in den Quellcode gehören und daher außerhalb Ihrer Wikipedia-Definition liegen.
- Harte Codierung sollte ein wesentlicher Bestandteil Ihres Prozesses sein, und wenn man bedenkt, dass sie ein Anti-Pattern ist, ist sie in der Zeitalter der Mikrodienste, wobei das Angular Tour of Heroes-Tutorial ein bekanntes Beispiel für ein riesiges Softwarehaus ist, das direkt als Zwischenschritt fungiert oder sogar beauftragt. Wenn Sie zu dynamischen Daten wechseln, sollten Sie dennoch einige fest codierte Daten als Ersatz behalten, die möglicherweise von einer Umgebungsvariablen oder sogar einem booleschen Umschalten des Codes selbst gesteuert werden, damit Fehler und Sicherheitsprobleme ordnungsgemäß isoliert werden können Zeile.
Antwort
Wirklich? Keine möglichen gültigen Anwendungsfälle?
Obwohl ich damit einverstanden bin, dass Hardcodierung im Allgemeinen eine Anti-Pattern oder zumindest ein sehr schlechter Code-Geruch gibt es viele Fälle, in denen dies sinnvoll ist. Hier einige Beispiele.
-
Einfachheit / YAGNI .
-
Reale Konstanten, die sich eigentlich nie ändern.
dh die Konstante repräsentiert ein natürliches oder Geschäftskonstante oder eine Annäherung von eins. (zB 0, PI, …)
-
Hardware- oder Software-Umgebungsbedingungen
In eingebetteter Software fallen Speicher- und Zuordnungsbeschränkungen ein.
-
Sichere Software
Diese Werte sind nicht verfügbar und / oder einfach zu dekodieren oder zurückzuentwickeln, z kryptografische Token und Salze. (Beachten Sie, dass die Festcodierung auch offensichtliche Nachteile hat …)
-
Generierter Code
Ihr Präprozessor oder Generator ist konfigurierbar, spuckt jedoch Code mit fest codierten Werten aus. Nicht ungewöhnlich für Code, der auf Regelengines basiert, oder wenn Sie eine modellgetriebene Architektur haben.
-
Hochleistungscode
In gewisser Weise wird “ “ Code generiert , obwohl noch spezialisierter. z.B. eine vordefinierte Such- / Berechnungstabelle mit unwahrscheinlichen Änderungen. Dies ist beispielsweise in der Grafikprogrammierung überhaupt nicht ungewöhnlich.
-
Konfiguration und Fallbacks
Sowohl in Ihrem eigentlichen Code als auch in Ihren Konfigurationsdateien haben Sie wahrscheinlich Konfigurationswerte und Fallbacks für mehrere Fälle (wenn die Konfiguration nicht verfügbar ist, wenn eine Komponente nicht als reagiert erwartet, etc …). Trotzdem ist es im Allgemeinen am besten, es außerhalb Ihres Codes zu halten und nachzuschlagen, aber es kann Fälle geben, in denen Sie unbedingt einen bestimmten Wert / eine bestimmte Reaktion auf eine bestimmte Aktion / ein bestimmtes Problem / eine bestimmte Situation haben möchten.
-
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 das sage Es gibt alle gute Gründe, und im Allgemeinen würde ich mich gegen fest codierte Werte sträuben. Aber einige können aus triftigen Gründen leicht einen Pass bekommen.
Und beaufsichtigen Sie nicht den ersten in Bezug auf Einfachheit / YAGNI , entweder indem man es für trivial hält: 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 erledigt gut.
Es ist schwierig, den Bal zu finden Ance. Manchmal sieht man nicht voraus, dass eine Software wächst und länger hält als das einfache Skript, als das sie gestartet wurde. Oft ist es jedoch umgekehrt: Wir überarbeiten Dinge, und ein Projekt wird schneller eingestellt, als Sie können Lesen Sie den Pragmatischen Programmierer. Sie haben Zeit und Mühe mit Dingen verschwendet, die ein früher Prototyp nicht brauchte.
Das sind die gemeinen Dinge mit Anti-Patterns: Sie sind in beiden Extremen des Spektrums vorhanden, und ihr Aussehen hängt von der ab Sensibilität der Person, die Ihren Code überprüft.
Persönlich würde ich immer den generischen Weg gehen, sobald ich sehe, dass sich etwas ändern könnte oder wenn ich „Wir mussten es mehr als einmal tun. Ein genauerer Ansatz wäre jedoch, die Kosten für die Hardcodierung sorgfältig zu bewerten und den Code für diese spezielle Situation zu generieren oder zu generieren.Dies entspricht der Feststellung, ob es sich lohnt, eine Aufgabe zu automatisieren, anstatt sie manuell auszuführen. Berücksichtigen Sie einfach Zeit und Kosten.
Kommentare
- Das ‚ ist lustig, weil ich dies selbst pilotiert habe und es für mich viel einfacher und schneller und sauberer war, dynamisch mit den Werten umzugehen. Ich habe es in gemacht Python, während ich glaube, dass das Endprodukt in Java codiert wird – wenn dies einen Unterschied macht. Es fühlte sich überentwickelt an, wenn ich die Werte hart codierte, da jede eingehende Spalte an mehreren Stellen verfolgt werden musste.
- @Tom: Sie ‚ sagen, es sei einfacher und schneller gewesen, eine Konfigurationssuchbibliothek zu implementieren (oder sogar wiederzuverwenden), als einen fest codierten Wert zu verwenden? Außerdem sehe ich ‚ nicht, wie Ihr letzter Satz zur Definition von Überentwicklung passt. Es würde f Aal ist offensichtlich chaotisch, und wenn es ‚ fest codiert und dupliziert ist, ist es ‚ noch schlimmer (was nicht der Punkt von Ihnen war Frage Frage, die ich wahrscheinlich falsch verstanden habe, aber es schien mir, als ob Sie meinten, dass der Wert nicht jedes Mal fest codiert wurde, sondern an einem einzelnen Punkt im Programm.
- Wie auch immer, ich ‚ Ich möchte nur auf Fälle hinweisen, in denen ‚ gültig wäre. Ich ‚ weise auch darauf hin, dass es ‚ in meinem letzten Satz umstritten wäre. Sie können ‚ nicht allen gefallen und Teams haben Leute mit unterschiedlichen Fähigkeiten.
- @Tom, ‚ t verkaufe dich zu kurz. Sie ‚ sind definitiv auf etwas. Es klingt einfacher und weniger zeitaufwendig, einen schnellen Algorithmus zum Organisieren der Daten zu schreiben, indem die Felder Abteilung und Jobtitel betrachtet werden, im Gegensatz zur harten Codierung
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 wird. - Sie können komplexere Dinge haben, die für den Hardcode noch sinnvoll sind. Eines, das mir vor einigen Jahren in den Sinn kam, 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 nehmen. Dies war bei weitem die effizienteste Lösung, und da es sich um eine O (N ^ 3) -Schleife handelte, war die Effizienz von Bedeutung.
Antwort
Es gibt Zeiten, in denen Hardcode-Werte in Ordnung sind. Beispielsweise gibt es einige Zahlen wie 0 oder eins oder verschiedene n ^ 2-1-Werte für Bitmasken, die für algorithmische Zwecke bestimmte Werte sein müssen. Das Zulassen solcher Werte für die Konfigurierbarkeit hat keinen Wert und eröffnet nur die Möglichkeit von Problemen. Mit anderen Worten, wenn das Ändern eines Werts nur Dinge kaputt machen würde, Es sollte wahrscheinlich fest codiert sein.
In dem von Ihnen angegebenen Beispiel sehe ich nicht, wo eine Hardcodierung nützlich wäre. Alles, was Sie erwähnen, würde / sollte bereits in der Datenbank enthalten sein, einschließlich Überschriften. Sogar Dinge, die die Präsentation steuern (wie die Sortierreihenfolge), können hinzugefügt werden, wenn sie nicht vorhanden sind.
Kommentare
- Danke. Die 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 dies möglich ist Als weitere Tabelle in der Datenbank hinzugefügt.
- Ich sollte beachten, dass die Verwaltung all dieser Elemente in der Datenbank eine Option darstellt. Sie können auch Konfigurationsdateien oder andere Lösungen verwenden, aber die Hardcodierung scheint eine schlechte Wahl zu sein. Die Datenbank Die 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 dies , die speziell für diesen Zweck entwickelt wurden.
Antwort
Implementierung einer robusten Lösung, die ermöglicht, dass Werte, die ansonsten möglicherweise hartcodiert wurden, stattdessen von den Anforderungen des Endbenutzers konfiguriert werden können robuste Validierung dieser Werte. Haben sie eine leere Zeichenfolge eingegeben? Haben sie etwas Nicht-Numerisches eingegeben, wo es eine Zahl hätte sein sollen? Machen sie SQL-Injection? Usw.
Hardcodierung vermeidet viele dieser Risiken.
Das heißt nicht, dass Hardcodierung immer oder sogar oft eine gute Idee ist. Dies ist gerecht einer der zu berücksichtigenden Faktoren.