Jeg er selvlært, nybegynner-koder, så jeg beklager hvis jeg ikke spikrer programmeringsmålingen.
Jeg jobber med et prosjekt der jeg leverer data, som kontinuerlig vil oppdateres, til utviklere som i det vesentlige vil lage et verktøy for å generere rapporter fra spørsmål om dataene.
Det ser ut til at alle involverte tror at de trenger å hardkode dataverdier (ikke skjemaet, men selve domenene / verdiene) til rapportgenereringsprogrammet.
Anta for eksempel at vi rapporterte om personell; rapporten ville bli delt i kategorier, med en overskrift for hver avdeling, og deretter under hver avdelingsoverskrift vil det være underoverskrifter på stillingsbetegnelser, og deretter under hver underoverskrift vil det være en liste over ansatte. på den annen side, ville jeg tro at de kunne / ville spørre ut disse tingene i løpetid, sortere poster etter dem og generere rapportoverskrifter dynamisk basert på hvilken verdi es er der.
Siden listen over potensielle verdier vil endres over tid (f.eks. blir avdelinger opprettet / omdøpt, nye jobbtitler vil bli lagt til), må koden oppdateres kontinuerlig. Det ser ut til at vi kunne hoppe over trinnene for vedlikehold av kode og dynamisk organisere rapportene.
Siden jeg ikke er en utvikler, lurer jeg på hva jeg mangler. Hvilke fordeler kan det være med hardkodende verdier til et verktøy som dette? Er det vanligvis slik programmer er designet?
Kommentarer
- mulig duplikat av Fjerning av hardkodet verdier og defensiv utforming mot YAGNI
- Er rapport tverrfaner, betyr det at verdier i rader skal vises som kolonner?
- @Brendan – Hvis du har harde kodeverdier i rapporten , du ‘ du trenger å endre listen to steder (datakilde og rapporten). Hvis rapporten er dynamisk, trenger du bare å endre den på ett sted (rapporten) .
- @Brendan hvorfor skulle du ende opp med tre steder? Kanskje min forståelse er feil, men jeg ‘ ser for meg et SQL-spørsmål for å hente data fra en database, applikasjonen vil samle / gruppere de returnerte verdiene av for eksempel avdelingen. Hvis du ‘ er villig til å ha overhead for flere db-spørsmål, kan du velge forskjellige avdelinger / rolle titler hvis du virkelig vil. På intet tidspunkt eksisterer dataene på mer enn ett sted – rapporten drives av dataene.
- @Brendan Jeg er også uenig i at din definisjon av at de er på ett sted – slik du beskriver det ‘ er på flere steder, spredt over kildekoden.
Svar
Wikipedia:
Hardt koding (også hardkoding eller hardkoding) refererer til programvareutviklingspraksis for å legge inn det som kanskje, kanskje bare i ettertid, kan betraktes som en inngangs- eller konfigurasjonsdata direkte i kildekoden til et program eller et annet kjørbart objekt, eller fast formatering av data, i stedet for å skaffe data fra eksterne kilder eller generere data eller formatering i selve programmet med den gitte inngangen.
Hardkoding betraktes som et antipattern .
Anses som en n mot mønster, hard koding krever at programmets kildekode endres når inngangsdata eller ønsket format endres, når det kan være mer praktisk for sluttbrukeren å endre detalj på noen måte utenfor programmet. p>
Noen ganger kan du ikke unngå det, men det bør være midlertidig.
Hard koding er ofte påkrevd. Programmerere har kanskje ikke en dynamisk brukergrensesnittløsning for sluttbrukeren, men må fremdeles levere funksjonen eller slippe programmet. Dette er vanligvis midlertidig, men løser, på kort sikt, presset for å levere koden. Senere blir softcoding gjort for å tillate en bruker å overføre parametere som gir sluttbrukeren en måte å endre resultatene eller resultatet på.
- Hardcoding av meldinger gjør det vanskelig å internasjonalisere et program.
- Hardkodingsstier gjør det vanskelig å tilpasse seg et annet sted.
Den eneste fordelen med hardkoding ser ut til å være rask levering av kode.
Kommentarer
- OK , men » eneste fordel » er ofte enormt viktig. Designbeslutninger i programmering handler ofte om avveining mellom fremtidig korrektur og rask levering nå, og som sådan kan hard koding være et helt akseptabelt valg. Noen ganger er ikke hard koding et dårlig designvalg.
- -1 Jeg synes ikke ‘ t synes dette er et nyttig svar. Det sier i hovedsak ‘ å legge inn verdier i kildekoden upassende ‘ er upassende. Jeg tror at OP ønsker veiledning om når ting kan høre hjemme i kildekoden og derfor faller utenfor Wikipedia-definisjonen din.
- Hard koding bør være en viktig del av prosessen din, og vurderer det som et antimønster er utdatert i alder av mikrotjenester, med Angular Tour of Heroes-opplæringen som et høyt profilert eksempel på et stort programvarehus som direkte omgir eller til og med mandat som et mellomtrinn. Hva mer er, når du går til dynamiske data, bør du fortsatt beholde noen hardkodede data som en tilbakeslag, kanskje styrt av en miljøvariabel eller til og med en boolsk bryter på selve koden, slik at feil og sikkerhetsproblemer kan isoleres riktig nedover linje.
Svar
Virkelig? Ingen mulige gyldige brukstilfeller?
Selv om jeg er enig i at hardkoding generelt er en motmønster eller i det minste en veldig dårlig kodelukt , det er mange tilfeller der det gir mening. Her er noen få.
-
Enkelhet / YAGNI .
-
Virkelige konstanter som faktisk aldri endres.
dvs. konstanten representerer en naturlig eller virksomhet konstant, eller en tilnærming av en. (f.eks. 0, PI, …)
-
Miljømessige begrensninger for maskinvare eller programvare
I innebygd programvare kommer minne- og tildelingsbegrensninger til hjernen.
-
Sikker programvare
Disse verdiene er ikke tilgjengelige og / eller enkle å dekode eller reversere, f.eks. kryptografiske tokens og salter. (Vær oppmerksom på at det å holde dem hardkodede også har åpenbare ulemper …)
-
Generert kode
Forprosessoren eller generatoren din kan konfigureres, men spytter ut kode med hardkodede verdier. Ikke uvanlig for kode som er avhengig av regelmotorer, eller hvis du har en modelldrevet arkitektur.
-
Høy ytelseskode
På en måte er dette » generert » kode , selv om det er enda mer spesialisert. f.eks. en forhåndsbestemt oppslag / beregningstabell med usannsynlige endringer. Dette er for eksempel ikke uvanlig i grafikkprogrammering.
-
Configuration and Fallbacks
Både i den faktiske koden og i konfigurasjonsfilene dine, vil du sannsynligvis ha konfigurasjonsverdier og tilbakefall i flere tilfeller (når konfigurasjonen ikke er tilgjengelig, når en komponent ikke svarer som forventet osv …). Likevel er det generelt best å holde det utenfor koden din og slå opp den, men det kan være tilfeller der du absolutt vil ha en spesifikk verdi / reaksjon på en bestemt handling / problem / situasjon.
-
Og sannsynligvis noen flere …
Fortsatt en Anti-mønster ? Så er Overteknikk ! Det handler om programvarens forventede levealder !!
Ikke det jeg sier det er alle gode grunner, og generelt vil jeg ikke ha hardkodede verdier. Men noen kan lett få et pass av gyldige grunner.
Og ikke overvåke den første angående enkelhet / YAGNI enten ved å tenke at det er trivielt: det er sannsynligvis ingen grunn til å implementere en gal parser- og verdikontroll for et enkelt skript som gjør en jobb for en smal brukstilfelle. vel.
Det er vanskelig å finne balansen ess. Noen ganger forutser du ikke at en programvare vil vokse og vare lenger enn det enkle skriptet det startet som. Ofte er det omvendt: vi overkonstruerer ting, og et prosjekt blir lagt raskere enn du kan les den pragmatiske programmereren. Du kastet bort tid og krefter på ting enn en tidlig prototype ikke trengte.
Det er de viktigste tingene med antimønstre: de er til stede i begge ytterpunktene i spekteret, og deres utseende avhenger av følsomheten til personen som vurderer koden din.
Personlig vil jeg pleie å alltid gå den generiske ruten så snart jeg ser at noe kan endres eller hvis jeg «Vi har måttet gjøre det mer enn en gang. Men en mer presis tilnærming ville være å nøye evaluere kostnadene ved hardkoding mot å generere eller generere koden din for den spesifikke situasjonen.Det er det samme som å avgjøre om en oppgave er verdt å automatisere i motsetning til å gjøre det manuelt. Bare ta hensyn til tid og kostnad.
Kommentarer
- At ‘ er morsomt, fordi jeg testet dette selv, og det var mye lettere og raskere og renere for meg å håndtere verdiene dynamisk. Jeg gjorde det i Python, mens jeg tror sluttproduktet vil bli kodet i Java – hvis dette gjør en forskjell. Det føltes overkonstruert når jeg hardkodet inn verdiene, fordi hver kommende kolonne måtte spores flere steder. / li>
- @Tom: Du ‘ sier at det var lettere og raskere å implementere (eller til og med gjenbruke) et konfigurasjonsoppslagsbibliotek enn å bruke en hardkodet verdi? for deg. Jeg ser ikke ‘ t hvordan din siste setning passer til definisjonen av over-engineering. Det ville f ål åpenbart rotete, og tydeligvis hvis den ‘ er hardkodet og duplisert, er den ‘ enda verre (som ikke var poenget med din spørsmålsspørsmål, jeg misforsto sannsynligvis, men det virket som om du mente at verdien ikke var hardkodet på plass hver gang, men på et enkelt punkt i programmet).
- I alle fall, jeg ‘ m bare påpeke tilfeller der det ‘ d er gyldig. Jeg ‘ peker også på at det ‘ d er kontroversiell i min siste setning. Du kan ‘ ikke behage alle og lag har folk med forskjellige ferdighetsnivåer.
- @Tom, ikke ‘ t selg deg selv for kort. Du ‘ er bestemt på noe. Det høres lettere og mindre tidkrevende å skrive en rask algoritme for å organisere dataene ved å se på feltene Avdeling og Jobbtittel i motsetning til hardkodning
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Det ville også være mye vanskeligere å opprettholde den hardkodede matrisen i tilfelle en ny avdeling eller tittel ble introdusert. - Du kan ha mer komplekse ting som fremdeles er fornuftige for hardcode. En som kommer til å tenke på at jeg skrev for noen år tilbake, var alle mulige permutasjoner av et sett verdier. Jeg trengte å finne en tilfeldig gyldig retning, å velge en tilfeldig permutasjon og deretter ta det første gyldige resultatet var den klart mest effektive løsningen, og siden det var i en O (N ^ 3) -løkkeffektivitet, var det viktig.
- Takk. Sorteringsrekkefølgen var den ene bekymringen jeg hadde. Imidlertid betyr det i vårt tilfelle ikke ‘ t, og jeg ‘ t engang vurderte at det kunne være lagt til som en annen tabell i databasen.
- Jeg bør være oppmerksom på at administrering av alt dette i DB er ett alternativ. Du kan også bruke konfigurasjonsfiler eller andre løsninger, men hardkoding ser ut til å være et dårlig valg. DB alternativet brukes ofte fordi det ‘ er enkelt å lage et grensesnitt for å la alternativene administreres av brukere. Det finnes også verktøy som dette som er spesielt designet for dette formålet.
>
Svar
Det er noen ganger det er OK med hardkodeverdier. For eksempel er det noen tall som 0, eller ett eller forskjellige n ^ 2-1-verdier for bitmasker som må være visse verdier for algoritmiske formål. Å tillate slike verdier til det konfigurerbare har ingen verdi og åpner bare muligheten for problemer. Med andre ord, hvis endring av en verdi bare ville ødelegge ting, det burde sannsynligvis være hardkodet.
I eksemplet du ga, ser jeg ikke hvor hardkoding vil være nyttig. Alt du nevner ville / burde allerede være i databasen inkludert overskrifter. Selv ting som driver presentasjonen (for eksempel sorteringsrekkefølge) kan legges til hvis de ikke er der.
Kommentarer
Svar
Implementering av en robust løsning som tillater verdier som ellers kan ha vært hardkodet for å i stedet kunne konfigureres av sluttbrukernes krav robust validering av disse verdiene. Har de satt i en tom streng? Satte de inn noe ikke-numerisk der det skulle ha vært et tall? Gjør de SQL-injeksjon? Etc.
Hard-coding unngår mange av disse risikoene.
Noe som ikke kan si at hard-coding alltid er, eller til og med ofte, en god idé. Dette er bare en av faktorene du må ta hensyn til.