Jeg er selvlært, nybegynderkoder, så jeg undskylder, hvis jeg ikke sømmer programmørens lingo.
Jeg arbejder på et projekt, hvor jeg leverer data, som løbende opdateres, til udviklere, der i det væsentlige opretter et værktøj til at generere rapporter fra forespørgsler om dataene.
Det ser ud til, at alle involverede tænker at de har brug for at hardcode dataværdier (ikke skemaet, men selve domænerne / værdierne) i rapportgenereringsprogrammet.
Antag for eksempel, at vi rapporterede om personale; rapporten ville blive delt i kategorier, med en overskrift for hver afdeling, og derefter under hver afdeling overskrift vil der være underoverskrifter på jobtitler, og derefter under hver underoverskrift vil der være en liste over medarbejdere. Udviklerne ønsker at hårdkode afdelinger og jobtitler. På på den anden side ville jeg tro, at de kunne / ville spørge disse ting ved kørsel, sortere poster efter dem og generere rapportoverskrifter dynamisk baseret på hvilken værdi der er der.
Da listen over potentielle værdier vil ændre sig over tid (f.eks. oprettes / omdøbes afdelinger, nye jobtitler tilføjes), skal koden opdateres løbende. Det ser ud til, at vi kunne springe over vedligeholdelsestrinene og dynamisk organisere rapporterne.
Da jeg ikke er udvikler, spekulerer jeg på, hvad jeg mangler. Hvilke fordele kan der være ved hårdkodende værdier til et værktøj som dette? Er dette typisk, hvordan programmer er designet?
Kommentarer
- mulig duplikat af Fjernelse af hardkodet værdier og defensivt design i forhold til YAGNI
- Er rapport tværfaner, hvilket betyder, at værdier i rækker skal vises som kolonner?
- @Brendan – Hvis du har hårde kodeværdier i rapporten , du ‘ skal ændre listen to steder (datakilde og rapporten), mens hvis rapporten er dynamisk, behøver du kun at ændre den ét sted (rapporten) .
- @Brendan hvorfor skulle du ende med tre placeringer? Måske er min forståelse forkert, men jeg ‘ forestiller mig en sql-forespørgsel for at hente data fra en database, applikationen samler / grupperer de returnerede værdier af f.eks. Afdelingen. Hvis du ‘ er villig til at have overhead på flere db-forespørgsler, kan du vælge forskellige afdelinger / rolle titler, hvis du virkelig vil. På intet tidspunkt findes dataene på mere end et sted – rapporten drives af dataene.
- @Brendan Jeg er også uenig i, at din definition af, at de er ét sted – som du beskriver det ‘ s flere steder spredt over kildekoden.
Svar
Wikipedia:
Hård kodning (også hårdkodning eller hardkodning) henviser til softwareudviklingspraksis ved at indlejre det, der måske måske kun i eftertid kan betragtes som en input- eller konfigurationsdata direkte i kildekoden til et program eller et andet eksekverbart objekt eller en fast formatering af data i stedet for at få disse data fra eksterne kilder eller generere data eller formatering i selve programmet med det givne input.
Hårdkodning betragtes som et antipattern .
betragtes som en n anti-mønster, hård kodning kræver, at programmets kildekode ændres, hver gang inputdataene eller det ønskede format ændres, når det kan være mere praktisk for slutbrugeren at ændre detaljen på en eller anden måde uden for programmet.
Nogle gange kan du ikke undgå det, men det skal være midlertidigt.
Hård kodning er ofte krævet. Programmører har muligvis ikke en dynamisk brugergrænsefladesløsning til slutbrugeren, men de skal stadig levere funktionen eller frigive programmet. Dette er normalt midlertidigt, men løser på kort sigt presset for at levere koden. Senere udføres softcoding for at give brugeren mulighed for at videregive parametre, der giver slutbrugeren en måde at ændre resultaterne eller resultatet på.
- Hardcoding af meddelelser gør det svært at internationalisere et program.
- Hardcoding-stier gør det svært at tilpasse sig et andet sted.
Den eneste fordel ved hardcoding synes at være hurtig levering af kode.
Kommentarer
- OK , men den eneste fordel ” ” er ofte meget vigtig. Designbeslutninger i programmering handler ofte om kompromis mellem fremtidig korrektur og hurtig levering nu, og som sådan kan hårdkodning være et helt acceptabelt valg. Nogle gange er ikke hård kodning et dårligt designvalg.
- -1 Jeg synes ikke ‘ det er et nyttigt svar. Det siger i bund og grund ‘ at integrere værdier i kildekoden uhensigtsmæssigt ‘ er upassende. Jeg tror, at OP ønsker vejledning om, hvornår ting kan høre hjemme i kildekoden og derfor falder uden for din Wikipedia-definition.
- Hård kodning bør være en vital del af din proces, og i betragtning af det er et antimønster forældet i alder af mikrotjenester, hvor Angular Tour of Heroes-tutorialen er et højt profileret eksempel på et kæmpe softwarehus, der direkte omslutter eller endda mandaterer som et mellemliggende trin. Hvad mere er, når du flytter til dynamiske data, skal du stadig beholde nogle hårdt kodede data som en tilbagefald, måske styret af en miljøvariabel eller endda en boolsk skifte på selve koden, så fejl og sikkerhedsproblemer kan isoleres korrekt ned ad linje.
Svar
Virkelig? Ingen mulige gyldige brugstilfælde?
Mens jeg er enig i, at hardkodning generelt er en antimønster eller i det mindste en meget dårlig kodelugt , der er masser af tilfælde, hvor det giver mening. Her er nogle få.
-
Enkelhed / YAGNI .
-
Reelle konstanter, der faktisk aldrig ændres.
dvs. konstanten repræsenterer en naturlig eller forretning konstant eller en tilnærmelse af en. (f.eks. 0, PI, …)
-
Miljømæssige begrænsninger for hardware eller software
I indlejret software kommer hukommelse og tildelingsbegrænsninger i tankerne.
-
Sikker software
Disse værdier er ikke tilgængelige og / eller lette at afkode eller reverse-engineering, f.eks. kryptografiske tokens og salte. (Bemærk at det også er åbenlyst at have dem med hårdkodede …)
-
Genereret kode
Din forprocessor eller generator kan konfigureres, men spytter kode med hårdkodede værdier. Ikke usædvanligt for kode, der er afhængig af regelmotorer, eller hvis du har en modeldrevet arkitektur.
-
Højtydende kode
På en måde er dette ” genereret ” kode , selvom det er endnu mere specialiseret. for eksempel. en forudbestemt opslag / beregningstabel med usandsynlige ændringer. Dette er overhovedet ikke usædvanligt i grafisk programmering.
-
Konfiguration og tilbagefald
Både i din faktiske kode og i dine konfigurationsfiler har du sandsynligvis konfigurationsværdier og tilbagefald i flere tilfælde (når konfigurationen ikke er tilgængelig, når en komponent ikke reagerer som forventet osv …). Alligevel er det generelt bedst at holde det uden for din kode og slå det op, men der kan være tilfælde, hvor du absolut vil have en bestemt værdi / reaktion på en bestemt handling / problem / situation.
-
Og sandsynligvis et par mere …
Stadig et Anti-mønster ? Så er Over-Engineering ! Det handler om din softwares forventede levetid !!
Ikke det jeg siger der er alle gode grunde, og generelt tænker jeg på hårdkodede værdier. Men nogle kan let få adgang til gyldige grunde.
Og ikke overvåge den første med hensyn til enkelhed / YAGNI enten ved at tænke det er trivielt: der er sandsynligvis ingen grund til at implementere en skør parser og værdikontrol til et simpelt script, der gør et job til en smal brug godt.
Det er svært at finde bal ance. Nogle gange forudser du ikke, at en software vil vokse og vare længere end det enkle script, det startede som. Ofte er det dog omvendt: vi overingenerer ting, og et projekt bliver lagt på plads hurtigere, end du kan læse den pragmatiske programmør. Du spildte tid og kræfter på tingene, end en tidlig prototype ikke havde brug for.
Det er de almindelige ting med antimønstre: de er til stede i begge ekstremer af spektret, og deres udseende afhænger af følsomhed hos den person, der gennemgår din kode.
Personligt vil jeg have tendens til altid at gå den generiske rute, så snart jeg ser, at noget kan ændre sig eller hvis jeg “Vi var nødt til at gøre det mere end én gang. Men en mere præcis tilgang ville være at nøje evaluere omkostningerne ved hårdkodning versus generering eller generering af din kode til den specifikke situation.Det er det samme som at afgøre, om en opgave er værd at automatisere i modsætning til at gøre det manuelt. Bare tag tid og omkostninger i betragtning.
Kommentarer
- At ‘ er sjovt, fordi jeg selv styrede dette, og det var meget lettere og hurtigere og renere for mig at håndtere værdierne dynamisk. Jeg gjorde det i Python, hvorimod jeg tror, at slutproduktet vil blive kodet i Java – hvis dette gør en forskel. Det føltes overudviklet, da jeg hårdkodede værdierne, fordi hver indkommende kolonne skulle spores flere steder. / li>
- @Tom: Du ‘ siger, at det var nemmere og hurtigere at implementere (eller endda genbruge) et konfigurationsopslagsbibliotek end at bruge en hårdkodet værdi? for dig. Jeg ser heller ikke ‘ hvordan din sidste sætning passer til definitionen af over-engineering. Det ville f ål åbenlyst rodet, og selvfølgelig hvis det ‘ er hårdkodet og duplikeret, er det ‘ endnu værre (hvilket ikke var meningen med din spørgsmålsspørgsmål, jeg misforstod sandsynligvis, men det syntes for mig, som om du mente, at værdien ikke var hårdkodet på plads hver gang, men i et enkelt punkt i programmet).
- Anyways, I ‘ Jeg påpeger bare tilfælde, hvor det ‘ d er gyldigt. Jeg ‘ m påpeger også, at det ‘ d er kontroversielt i min sidste sætning. Du kan ‘ ikke behage alle og hold har folk med forskellige færdighedsniveauer.
- @Tom, don ‘ t sælge dig selv for kort. Du ‘ fortsætter bestemt med noget. Det lyder lettere og mindre tidskrævende at skrive en hurtig algoritme til at organisere dataene ved at se på felterne Afdeling og Jobtitel i modsætning til hårdkodning
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Det ville også være meget sværere at vedligeholde det hårdkodede array, hvis en ny afdeling eller titel blev introduceret. - Du kan have mere komplekse ting, der stadig er fornuftige for hardcode. En, der kommer til at tænke på, at jeg skrev for et par år tilbage, var alle mulige permutationer af et sæt værdier. Jeg havde brug for at finde en tilfældig gyldig retning, at vælge en tilfældig permutation og derefter tage det første gyldige resultat var langt den mest effektive løsning, og da det var i en O (N ^ 3) -sløjfe, var effektiviteten vigtig.
Svar
Der er tidspunkter, det er OK for værdier med hård kode. F.eks. er der nogle tal som 0 eller et eller forskellige n ^ 2-1-værdier til bitmasker, der skal være visse værdier til algoritmiske formål. At tillade sådanne værdier til det konfigurerbare har ingen værdi og åbner kun muligheden for problemer. Med andre ord, hvis ændring af en værdi kun ville bryde ting, det skulle sandsynligvis være hårdkodet.
I det eksempel, du gav, kan jeg ikke se, hvor hårdkodning ville være nyttigt. Alt, hvad du nævner, ville / burde allerede være i databasen inklusive overskrifter. Selv ting, der driver præsentationen (såsom sorteringsrækkefølge), kan tilføjes, hvis de ikke er der.
Kommentarer
- Tak. Sorteringsrækkefølge var den ene bekymring, jeg havde. I vores tilfælde betyder det dog ikke ‘ t, og jeg har ikke ‘ t engang overvejet, at det kunne være tilføjet som en anden tabel i databasen.
- Jeg skal bemærke, at styring af alt dette i DB er en mulighed. Du kan også bruge konfigurationsfiler eller andre løsninger, men hardcoding ser ud til at være et dårligt valg. DB indstilling bruges ofte, fordi det ‘ er let at oprette en grænseflade, så brugerne kan administrere indstillingerne. Der er også værktøjer som dette , som er specielt designet til dette formål.
Svar
Implementering af en robust løsning, der muliggør, at værdier, der ellers måske er blevet hårdkodet, i stedet kan konfigureres af slutbrugernes krav robust validering af disse værdier. Satte de en tom streng i? Indsatte de noget ikke-numerisk, hvor det skulle have været et tal? Gør de SQL-injektion? Etc.
Hårdkodning undgår mange af disse risici.
Hvilket ikke kan sige, at hårdkodning altid eller endda ofte er en god idé. Dette er bare en af de faktorer, der skal tages i betragtning.