Ik “ben een autodidactische, beginnende coder, dus ik bied mijn excuses aan als ik het programmeer-jargon niet goed begrijp.
Ik werk aan een project waarin ik gegevens aanlever, die voortdurend worden bijgewerkt, aan ontwikkelaars die in wezen een tool zullen maken om rapporten te genereren op basis van vragen over de gegevens.
Het lijkt erop dat alle betrokkenen denken dat ze gegevenswaarden (niet het schema, maar de domeinen / waarden zelf) hard moeten coderen in het programma voor het genereren van rapporten.
Stel dat we rapporteren over personeel; het rapport zou worden opgesplitst in categorieën, met een kop voor elke afdeling, en dan onder elke afdelingskop staan subkoppen van functietitels en vervolgens onder elke subkop een lijst met werknemers. De ontwikkelaars willen de afdelingen en functietitels hard coderen. aan de andere kant zou ik denken dat ze die dingen tijdens runtime zouden kunnen / zouden opvragen, records op hen zouden kunnen sorteren en rapportkoppen dynamisch zouden kunnen genereren op basis van welke waarde es zijn er.
Aangezien de lijst met potentiële waarden in de loop van de tijd zal veranderen (bijv. afdelingen zullen worden gemaakt / hernoemd, nieuwe functietitels zullen worden toegevoegd), moet de code voortdurend worden bijgewerkt. Het lijkt mij dat we de stappen voor codeonderhoud kunnen overslaan en de rapporten dynamisch kunnen organiseren.
Aangezien ik geen ontwikkelaar ben, vraag ik me af wat ik mis. Welke voordelen zou het kunnen hebben om waarden hard te coderen in een tool als deze? Is dit typisch hoe programmas worden ontworpen?
Reacties
- mogelijk duplicaat van Hard-coded verwijderen waarden en defensief ontwerp versus YAGNI
- Zijn rapport kruistabellen, wat betekent dat waarden in rijen als kolommen moeten verschijnen?
- @Brendan – Als u waarden in het rapport hard codeert , u ‘ moet de lijst op TWEE plaatsen wijzigen (gegevensbron en het rapport), terwijl als het rapport dynamisch is, u het slechts op één locatie hoeft te wijzigen (het rapport) .
- @Brendan waarom zou je eindigen met drie locaties? Misschien is mijn begrip onjuist, maar ik ‘ m voorzie een sql-query om gegevens uit een database op te halen, de applicatie zal de geretourneerde waarden aggregeren / groeperen door bijvoorbeeld de afdeling. Als u ‘ bereid bent om de overhead van meerdere db-zoekopdrachten te hebben, kunt u verschillende afdelingen / roltitels selecteren als u dat echt wilt. De gegevens bestaan op geen enkel moment op meer dan één locatie – het rapport wordt gestuurd door de gegevens.
- @Brendan Ik ben het ook niet eens met uw definitie dat het zich op één plaats bevindt – de manier waarop u het beschrijft ‘ s op meerdere locaties, verspreid over de broncode.
Antwoord
Wikipedia:
Moeilijk codering (ook hardcoding of hardcoding) verwijst naar de softwareontwikkelingspraktijk van het inbedden van wat, misschien pas achteraf gezien, kan worden beschouwd als invoer- of configuratiegegevens rechtstreeks in de broncode van een programma of ander uitvoerbaar object, of een vaste opmaak van de gegevens, in plaats van die gegevens uit externe bronnen te halen of gegevens te genereren of in het programma zelf te formatteren met de gegeven invoer.
Hardcoderen wordt als een antipatroon beschouwd .
Beschouwd als een n anti-patroon, harde codering vereist dat de broncode van het programma wordt gewijzigd telkens wanneer de invoergegevens of het gewenste formaat veranderen, wanneer het voor de eindgebruiker handiger kan zijn om de details op een of andere manier buiten het programma te veranderen.
Soms kun je het niet vermijden, maar het moet tijdelijk zijn.
Harde codering is vaak vereist. Programmeurs hebben misschien geen dynamische gebruikersinterface-oplossing voor de eindgebruiker uitgewerkt, maar moeten de functie toch leveren of het programma vrijgeven. Dit is meestal tijdelijk, maar lost op korte termijn de druk op om de code te leveren. Later wordt softcoding uitgevoerd om een gebruiker parameters door te geven die de eindgebruiker een manier geven om de resultaten of uitkomst te wijzigen.
- Hardcoding van berichten maakt het moeilijk om een programma te internationaliseren.
- Hardcoderingspaden maken het moeilijk om zich aan een andere locatie aan te passen.
Het enige voordeel van hardcoding lijkt de snelle levering van code te zijn.
Reacties
- OK , maar het ” enige voordeel ” is vaak enorm belangrijk. Ontwerpbeslissingen bij het programmeren gaan vaak over de afweging tussen toekomstbestendig maken en snelle levering nu, en als zodanig kan harde codering een perfect acceptabele keuze zijn. Soms is niet harde codering een slechte ontwerpkeuze.
- -1 Ik denk niet dat ‘ dit een nuttig antwoord is. Het zegt in wezen dat ‘ waarden op ongepaste wijze in de broncode insluiten ‘ ongepast is. Ik denk dat het OP advies wil over wanneer dingen in de broncode thuishoren en daarom buiten uw Wikipedia-definitie vallen.
- Harde codering zou een essentieel onderdeel van uw proces moeten zijn en gezien het is een antipatroon verouderd in de tijdperk van microservices, waarbij de Angular Tour of Heroes-tutorial een spraakmakend voorbeeld is van een enorm softwarehuis dat direct codeert of zelfs verplicht stelt als tussenstap. Wat meer is, wanneer u naar dynamische gegevens gaat, moet u nog steeds enkele hard gecodeerde gegevens bewaren als een terugval, misschien gecontroleerd door een omgevingsvariabele of zelfs een booleaanse schakelaar op de code zelf, zodat bugs en beveiligingsproblemen correct kunnen worden geïsoleerd regel.
Antwoord
Echt? Geen mogelijke geldige use-cases?
Hoewel ik het ermee eens ben dat hard-coding over het algemeen een antipatroon of op zijn minst een zeer slechte codegeur , er zijn tal van gevallen waarin het logisch is. Hier zijn er een paar.
-
Eenvoud / YAGNI .
-
Echte constanten die eigenlijk nooit veranderen.
dwz de constante vertegenwoordigt een natuurlijke of zakelijke constante, of een benadering van één. (bijv. 0, PI, …)
-
Hardware of software omgevingsbeperkingen
In embedded software denk ik aan geheugen- en toewijzingsbeperkingen.
-
Beveiligde software
Deze waarden zijn niet beschikbaar en / of gemakkelijk te decoderen of reverse-engineeren, bijv. cryptografische tokens en salts. (Merk op dat het hard-coderen ervan ook duidelijke nadelen heeft …)
-
Gegenereerde code
Uw preprocessor of generator is configureerbaar, maar spuugt code uit met hardgecodeerde waarden. Niet ongebruikelijk voor code die afhankelijk is van rule engines, of als u een modelgestuurde architectuur heeft.
-
Krachtige code
In zekere zin is dit ” gegenereerde ” code , hoewel nog meer gespecialiseerd. bijv. een vooraf bepaalde opzoek- / berekeningstabel met onwaarschijnlijke wijzigingen. Dit is bijvoorbeeld helemaal niet ongebruikelijk bij grafische programmering.
-
Configuratie en terugval
Zowel in uw eigenlijke code als in uw configuratiebestanden heeft u waarschijnlijk configuratiewaarden en fallbacks voor verschillende gevallen (wanneer de configuratie niet beschikbaar is, wanneer een component niet reageert zoals verwacht, enz …). Toch is het over het algemeen het beste om het buiten je code te houden en het op te zoeken, maar er kunnen gevallen zijn waarin je absoluut een specifieke waarde / reactie op een specifieke actie / probleem / situatie wilt hebben.
-
En waarschijnlijk nog een paar …
Nog steeds een Anti-Pattern ? Dat geldt ook voor Over-engineering ! Het gaat om de levensverwachting van uw software !!
Niet dat ik dit zeg er zijn allemaal goede redenen, en over het algemeen heb ik geen zin in vastgecodeerde waarden. Maar sommigen kunnen gemakkelijk slagen om geldige redenen.
En let niet op de eerste met betrekking tot eenvoud / YAGNI door te denken dat het triviaal is: er is waarschijnlijk geen reden om een gekke parser en waardechecker te implementeren voor een eenvoudig script dat één taak uitvoert voor een beperkt gebruik. goed.
Het is moeilijk om de bal te vinden ance. Soms verwacht je niet dat een software zal groeien en langer zal meegaan dan het eenvoudige script waarmee het begon. Vaak is het echter andersom: we engineeren dingen en een project wordt sneller op de plank gelegd dan jij kunt lees de Pragmatic Programmer. Je hebt tijd en moeite verspild aan dingen die een vroeg prototype niet nodig had.
Dat zijn de gemene dingen met Anti-Patterns: ze zijn aanwezig in beide uitersten van het spectrum, en hun uiterlijk hangt af van de gevoeligheid van de persoon die uw code beoordeelt.
Persoonlijk zou ik de neiging hebben om altijd de algemene weg te gaan, zodra ik zie dat er iets zou kunnen veranderen of als ik “Ik heb het meer dan eens moeten doen. Maar een meer precieze benadering zou zijn om de kosten van hard-coding zorgvuldig te evalueren versus het genereren of genereren van uw code voor die specifieke situatie.Het is hetzelfde als bepalen of een taak de moeite waard is om te automatiseren in plaats van handmatig te doen. Houd alleen rekening met tijd en kosten.
Reacties
- Dat ‘ is grappig, omdat ik dit zelf heb uitgeprobeerd en het veel gemakkelijker, sneller en schoner voor mij was om dynamisch met de waarden om te gaan. Ik deed het in Python, terwijl ik denk dat het eindproduct in Java zal worden gecodeerd – als dit een verschil maakt. Het voelde over-engineered toen ik hard-codeerde in de waarden, omdat elke inkomende kolom op meerdere plaatsen moest worden gevolgd. / li>
- @Tom: Je ‘ zegt dat het gemakkelijker en sneller was om een configuratie-opzoekbibliotheek te implementeren (of zelfs opnieuw te gebruiken) dan om een hard-coded waarde te gebruiken? voor jou. Ik begrijp ook niet ‘ hoe je laatste zin past bij de definitie van over-engineering. Het zou f paling is duidelijk rommelig, en als het ‘ hard gecodeerd en gedupliceerd ‘ s nog erger was (wat niet het punt was van uw vraag, ik heb het waarschijnlijk verkeerd begrepen, maar het leek me alsof je bedoelde dat de waarde niet elke keer hard gecodeerd was, maar op een enkel punt in het programma).
- Hoe dan ook, ik ‘ m wees alleen op gevallen waarin het ‘ geldig zou zijn. Ik ‘ m wees er ook op dat het ‘ controversieel zou zijn in mijn laatste zin. Je kunt ‘ niet iedereen tevreden stellen en teams hebben mensen met verschillende vaardigheidsniveaus.
- @Tom, don ‘ t verkoop jezelf te kort. Je ‘ bent zeker ergens mee bezig. Het klinkt gemakkelijker en minder tijdrovend om een snel algoritme te schrijven om de gegevens te ordenen door naar de velden Afdeling en Functie te kijken, in plaats van hard coderen
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Het zou ook veel moeilijker zijn om de hard gecodeerde array te behouden in het geval dat er een nieuwe afdeling of titel werd geïntroduceerd. - Je kunt complexere dingen hebben die nog steeds gevoelig zijn om hard te coderen. Een die in me opkomt dat ik een paar jaar geleden schreef, waren alle mogelijke permutaties van een reeks waarden. Ik moest een willekeurige geldige richting vinden, een willekeurige permutatie kiezen en vervolgens het eerste geldige resultaat nemen was verreweg de meest efficiënte oplossing en aangezien het zich in een O (N ^ 3) -lus bevond, was efficiëntie van belang.
Answer
Soms is het ok om waarden hard te coderen. Er zijn bijvoorbeeld enkele getallen zoals 0, of één of verschillende n ^ 2-1 waarden voor bitmasks die bepaalde waarden moeten zijn voor algoritmische doeleinden. Het toestaan van dergelijke waarden aan de configureerbare waarde heeft geen waarde en opent alleen de mogelijkheid van problemen. Met andere woorden, als het veranderen van een waarde alleen dingen zou breken, het zou waarschijnlijk hardcoded moeten zijn.
In het voorbeeld dat je gaf, zie ik niet waar hardcoding nuttig zou zijn. Alles wat u noemt, zou al in de database moeten staan, inclusief koppen. Zelfs dingen die de presentatie aansturen (zoals sorteervolgorde) kunnen worden toegevoegd als ze er “niet zijn.
Reacties
- Bedankt. Sorteervolgorde was de enige zorg die ik had. Maar in ons geval doet het ‘ er niet toe, en ik dacht ‘ zelfs niet dat het zou kunnen zijn toegevoegd als een andere tabel in de database.
- Ik moet er rekening mee houden dat het beheren van dit alles in de database één optie is. Je zou ook configuratiebestanden of andere oplossingen kunnen gebruiken, maar hardcoding lijkt een slechte keuze. De database optie wordt vaak gebruikt omdat het ‘ eenvoudig is om een interface te maken waarmee de opties door gebruikers kunnen worden beheerd. Er zijn ook tools zoals dit die speciaal voor dit doel zijn ontworpen.
Antwoord
Implementatie van een robuuste oplossing die zorgt ervoor dat waarden die anders hard gecodeerd zouden zijn, in plaats daarvan kunnen worden geconfigureerd door de eisen van de eindgebruikers robuuste validatie van die waarden. Hebben ze een lege string ingevoegd? Hebben ze iets niet-numerieks ingevoerd waar het een getal had moeten zijn? Doen ze SQL-injectie? Enz.
Hard coderen vermijdt veel van deze risicos.
Dat wil niet zeggen dat hard coderen altijd of zelfs vaak een goed idee is. een van de factoren waarmee u rekening moet houden.