Jag är en självlärd, nybörjarkodare, så jag ber om ursäkt om jag inte spikar programmeringslingan.
Jag arbetar med ett projekt där jag tillhandahåller data, som kontinuerligt kommer att uppdateras, till utvecklare som i huvudsak skapar ett verktyg för att generera rapporter från frågor om data.
Det verkar som alla inblandade tycker att de behöver hårdkoda datavärden (inte schemat, utan själva domänerna / värdena) i rapportgenereringsprogrammet.
Antag till exempel att vi rapporterade om personal; rapporten skulle delas upp i kategorier, med en rubrik för varje avdelning och sedan under varje avdelningsrubrik kommer underrubriker till jobbtitlar och sedan under varje underrubrik kommer en lista över anställda. Utvecklarna vill hårdkoda avdelningar och jobbtitlar. å andra sidan skulle jag tro att de kunde / skulle fråga ut dessa saker under körning, sortera poster efter dem och generera rapportrubriker dynamiskt baserat på vilket värde es finns där.
Eftersom listan över potentiella värden kommer att förändras över tid (t.ex. avdelningar skapas / byts namn, nya jobbtitlar kommer att läggas till), måste koden uppdateras kontinuerligt. Det verkar för mig som om vi kunde hoppa över kodunderhållsstegen och organisera rapporterna dynamiskt.
Eftersom jag inte är utvecklare undrar jag vad jag saknar. Vilka fördelar kan det ha med hårdkodande värden i ett sådant verktyg? Är det här typiskt hur program utformas?
Kommentarer
- möjlig duplikat av Ta bort hårdkodad värden och defensiv design jämfört med YAGNI
- Är rapportkorsflikar, vilket innebär att värden i rader ska visas som kolumner?
- @Brendan – Om du har hårda kodvärden i rapporten , du ’ måste ändra listan på TVÅ platser (datakälla och rapporten) medan om rapporten är dynamisk behöver du bara ändra den på en plats (rapporten) .
- @Brendan varför skulle du hamna på tre platser? Kanske min förståelse är felaktig men jag ’ tänker mig en SQL-fråga för att hämta data från en databas, applikationen kommer att aggregera / gruppera de returnerade värdena, t.ex. avdelningen. Om du ’ är villig att ha kostnaden för flera db-frågor kan du välja olika avdelningar / rolltitlar om du verkligen vill. Uppgifterna finns inte vid något tillfälle på mer än en plats – rapporten drivs av uppgifterna.
- @Brendan Jag håller inte med om att din definition av att den finns på ett ställe – hur du beskriver det ’ s på flera platser, utspridda över källkoden.
Svar
Wikipedia:
Hårt kodning (även hårdkodning eller hårdkodning) avser mjukvaruutvecklingsmetoden för att bädda in vad som, kanske bara i efterhand, kan betraktas som en inmatnings- eller konfigurationsdata direkt i källkoden för ett program eller annat körbart objekt, eller fast formatering av data istället för att erhålla data från externa källor eller generera data eller formatera i själva programmet med den angivna ingången.
Hårdkodning anses vara ett antipattern .
Anses som en n mot mönster, hård kodning kräver att programmets källkod ändras närhelst ingångsdata eller önskat format ändras, när det kan vara bekvämare för slutanvändaren att ändra detalj på något sätt utanför programmet.
Ibland kan du inte undvika det men det borde vara tillfälligt.
Hård kodning är ofta krävs. Programmerare kanske inte har en dynamisk lösning för användargränssnittet för slutanvändaren, men måste fortfarande leverera funktionen eller släppa programmet. Detta är vanligtvis tillfälligt men löser på kort sikt trycket att leverera koden. Senare görs mjukkodning för att tillåta en användare att vidarebefordra parametrar som ger slutanvändaren ett sätt att ändra resultaten eller resultatet.
- Hårdkodning av meddelanden gör det svårt att internationalisera ett program.
- Hardcoding-banor gör det svårt att anpassa sig till en annan plats.
Den enda fördelen med hårdkodning verkar vara snabb leverans av kod.
Kommentarer
- OK , men ” enda fördel ” är ofta enormt viktigt. Designbeslut i programmering handlar ofta om avvägningen mellan framtida korrektur och snabb leverans nu, och som sådan kan hårdkodning vara ett helt acceptabelt val. Ibland är inte hård kodning ett dåligt designval.
- -1 Jag tycker inte ’ det är inte ett bra svar. Det säger i huvudsak ’ att bädda in värden i källkoden olämpligt ’ är olämpligt. Jag tror att OP vill ha vägledning om när saker kan höra till i källkoden och därför faller utanför din Wikipedia-definition.
- Hård kodning bör vara en viktig del av din process och med tanke på att ett antimönster är föråldrat i åldern för mikrotjänster, med Angular Tour of Heroes-handboken som ett framträdande exempel på ett enormt programvaruhus som direkt omsluter eller till och med mandat som ett mellansteg. Vad mer är, när du flyttar till dynamisk data bör du fortfarande behålla vissa hårdkodade data som en back-back, kanske styrs av en miljövariabel eller till och med en boolesk växling på själva koden så att buggar och säkerhetsfrågor kan isoleras ordentligt ner i rad.
Svar
Verkligen? Inga möjliga giltiga användningsfall?
Även om jag håller med om att hårdkodning i allmänhet är en motmönster eller åtminstone en mycket dålig kodlukt , det finns många fall där det är vettigt. Här är några.
-
Enkelhet / YAGNI .
-
Verkliga konstanter som faktiskt aldrig förändras.
dvs konstanten representerar en naturlig eller affärer konstant, eller en approximation av en. (t.ex. 0, PI, …)
-
Miljöbegränsningar för maskinvara eller programvara
I inbäddad programvara kommer minnes- och allokeringsbegränsningar att tänka på.
-
Säker programvara
Dessa värden är inte tillgängliga och / eller enkla att avkoda eller omarbeta, t.ex. kryptografiska tokens och salter. (Observera att det är också uppenbara nackdelar att hålla dem hårdkodade …)
-
Genererad kod
Din förprocessor eller generator är konfigurerbar men spottar ut kod med hårdkodade värden. Inte ovanligt för kod som är beroende av regelmotorer eller om du har en modelldriven arkitektur.
-
Högpresterande kod
På ett sätt är detta ” genererad ” -kod , även om det är ännu mer specialiserat. t.ex. en förutbestämd uppslags- / beräkningstabell med osannolika förändringar. Detta är inte ovanligt alls i grafisk programmering till exempel.
-
Configuration and Fallbacks
Både i din faktiska kod och i dina konfigurationsfiler har du sannolikt konfigurationsvärden och fallbackar i flera fall (när konfigurationen inte är tillgänglig, när en komponent inte svarar som förväntas osv …). Ändå är det i allmänhet bäst att hålla den utanför din kod och slå upp den, men det kan finnas fall där du absolut vill ha ett specifikt värde / reaktion på en specifik åtgärd / fråga / situation.
-
Och förmodligen några fler …
Fortfarande en Antimönster ? Så är Överteknik ! Det handlar om programvarans livslängd !!
Inte för att jag säger det finns alla bra anledningar, och i allmänhet skulle jag hålla fast vid hårdkodade värden. Men vissa kan lätt få ett pass av giltiga skäl.
Och övervaka inte det första angående enkelhet / YAGNI antingen genom att tro att det är trivialt: det finns antagligen ingen anledning att implementera en galen parser- och värdekontroll för ett enkelt skript som gör ett jobb för en smal användning väl.
Det är svårt att hitta balansen ance. Ibland förutspår du inte att en programvara kommer att växa och hålla längre än det enkla skriptet som det började som. Ofta är det dock tvärtom: vi överkonstruerar saker och ett projekt lagras snabbare än du kan läs den pragmatiska programmeraren. Du slösade bort tid och ansträngning på saker än vad en tidig prototyp inte behövde.
Det är de vanliga sakerna med Anti-Patterns: de finns i båda ytterligheterna i spektrumet, och deras utseende beror på känsligheten hos den person som granskar din kod.
Personligen skulle jag alltid vilja gå den allmänna vägen så snart jag ser att något kan förändras eller om jag ”Vi var tvungna att göra det mer än en gång. Men ett mer exakt tillvägagångssätt skulle vara att noggrant utvärdera kostnaden för hårdkodning jämfört med att generera eller generera din kod för den specifika situationen.Det är detsamma som att avgöra om en uppgift är värd att automatisera i motsats till att göra den manuellt. Ta bara hänsyn till tid och kostnad.
Kommentarer
- Att ’ är roligt eftersom jag själv testade detta och det var mycket lättare och snabbare och renare för mig att hantera värdena dynamiskt. Jag gjorde det i Python, medan jag tror att slutprodukten kommer att kodas i Java – om detta gör skillnad. Det kändes överkonstruerat när jag hårdkodade värdena, eftersom varje inkommande kolumn måste spåras på flera ställen. / li>
- @Tom: Du ’ säger att det var lättare och snabbare att implementera (eller till och med återanvända) ett konfigurationssökningsbibliotek än att använda ett hårdkodat värde? för dig. Jag ser inte heller ’ hur din sista mening passar definitionen av överteknik. Det skulle f ål uppenbarligen rörigt, och uppenbarligen om den ’ är hårdkodad och duplicerad är den ’ ännu värre (vilket inte var poängen med din frågeställning, jag missförstod förmodligen, men det verkade för mig som om du menade att värdet inte var hårdkodat på plats varje gång utan i en enda punkt i programmet).
- Hur som helst, jag ’ jag pekar bara på fall där det ’ d är giltigt. Jag ’ pekar också på att det ’ skulle vara kontroversiellt i min sista mening. Du kan ’ inte behaga alla och team har människor med olika skicklighetsnivåer.
- @Tom, don ’ t sälj dig själv för kort. Du ’ är definitivt på väg åt något. Det låter lättare och mindre tidskrävande att skriva en snabb algoritm för att organisera data genom att titta på fälten Avdelning och Jobbtitel i motsats till hårdkodning
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Det skulle också vara mycket svårare att behålla den hårdkodade matrisen i händelse av att en ny avdelning eller titel infördes. - Du kan ha mer komplexa saker som fortfarande är förnuftiga för hårddisk. En som kommer att tänka på att jag skrev för några år tillbaka var alla möjliga permutationer av en uppsättning värden. Jag behövde hitta en slumpmässig giltig riktning, att välja en slumpmässig permutation och sedan ta det första giltiga resultatet var den överlägset mest effektiva lösningen och eftersom det var i en O (N ^ 3) slingeffektivitet var viktigt.
Svar
Det är ibland OK för hårda kodvärden. Det finns till exempel några siffror som 0, eller en eller olika n ^ 2-1-värden för bitmasker som måste vara vissa värden för algoritmiska ändamål. Att tillåta sådana värden till det konfigurerbara har inget värde och öppnar bara upp möjligheten till problem. Med andra ord, om att ändra ett värde bara skulle bryta saker, det borde antagligen vara hårdkodat.
I exemplet du gav ser jag inte var hårdkodning skulle vara användbar. Allt du nämner skulle / borde redan finnas i databasen inklusive rubriker. Även saker som driver presentationen (som sorteringsordning) kan läggas till om de inte finns där.
Kommentarer
- Tack. Sorteringsordningen var den enda oro jag hade. Men i vårt fall betyder det inte ’ t, och jag tänkte inte ens ’ att det kunde vara läggs till som en annan tabell i databasen.
- Jag bör notera att hantering av allt detta i DB är ett alternativ. Du kan också använda konfigurationsfiler eller andra lösningar men hårdkodning verkar vara ett dåligt val. DB alternativet används ofta eftersom det ’ är enkelt att skapa ett gränssnitt så att användarna kan hantera alternativen. Det finns också verktyg som detta som är specifikt utformade för detta ändamål.
Svar
Implementera en robust lösning som möjliggör värden som annars kan ha varit hårdkodade för att istället kunna konfigureras av slutanvändarnas krav robust validering av dessa värden. Satte de i en tom sträng? Satte de in något icke-numeriskt där det borde ha varit ett nummer? Gör de SQL-injektion? Etc.
Hårdkodning undviker många av dessa risker.
Vilket inte betyder att hårdkodning alltid eller till och med ofta är en bra idé. Detta är bara en av de faktorer att ta hänsyn till.