Olen itseoppinut, aloittelija-koodaaja, joten pyydän anteeksi, jos en naulaa ohjelmoijan sanaa.
Työskentelen projektissa, jossa tarjoan jatkuvasti päivitettäviä tietoja kehittäjille, jotka luovat pohjimmiltaan työkalun raporttien luomiseen datakyselyistä.
Vaikuttaa siltä, että kaikki asianosaiset ajattelevat että heidän on koodattava tietoarvot (ei skeema, vaan verkkotunnukset / arvot itse) raportinluontiohjelmaan.
Oletetaan esimerkiksi, että raportoimme henkilöstöstä; raportti jaetaan luokkiin, joissa on otsikko kullekin osastolle, ja sitten kunkin osaston otsikon alla ovat työnimikkeiden alaotsikot ja sitten kussakin alaotsikossa on luettelo työntekijöistä. Kehittäjät haluavat koodata osastot ja työnimikkeet. Toisaalta luulisin, että he voisivat / voisivat kysyä näitä asioita ajon aikana, lajitella tietueet niiden mukaan ja luoda raportin otsikot dynaamisesti sen perusteella, mikä arvo Ne ovat siellä.
Koska mahdollisten arvojen luettelo muuttuu ajan myötä (esim. osastoja luodaan / nimetään uudelleen, lisätään uusia tehtävänimikkeitä), koodia on päivitettävä jatkuvasti. Minusta tuntuu, että voimme ohittaa koodin ylläpitovaiheet ja järjestää raportit dynaamisesti.
Koska en ole kehittäjä, ihmettelen, mitä puuttuu. Mitä hyötyä arvojen koodaamisesta tällaiseen työkaluun voi olla? Onko ohjelmat tyypillisesti näin suunniteltu?
Kommentit
- mahdollinen kopio -koodattujen tiedostojen poistamisesta arvot ja puolustava muotoilu vs YAGNI
- Ovatko raportin välilehdet, mikä tarkoittaa, että rivien arvojen pitäisi näkyä sarakkeina?
- @Brendan – Jos määrität raportissa kovakoodiarvoja , ’ sinun on muutettava luetteloa kahdessa paikassa (tietolähde ja raportti), kun taas jos raportti on dynaaminen, sinun on muutettava sitä vain yhdessä paikassa (raportti) .
- @Brendan miksi päätyisit kolmeen sijaintiin? Ehkä ymmärrykseni on väärä, mutta ’ m kuvittelen sql-kyselyn hakemaan tietoja tietokannasta, sovellus yhdistää / ryhmittää palautetut arvot esim. Osastolta. Jos ’ haluaisit saada useita db-kyselyitä, voit valita erilliset osastot / roolinimikkeet, jos todella haluat. Tietoja ei ole missään vaiheessa useammassa kuin yhdessä paikassa – tiedot ohjaavat raporttia.
- @Brendan En myöskään ole samaa mieltä siitä, että määrität sen olevan yhdessä paikassa – tapaa, jolla kuvaat sitä ’ s useissa sijainneissa, hajallaan lähdekoodissa.
Vastaa
Wikipedia:
Kova koodaus (myös kovakoodaus tai kovakoodaus) viittaa ohjelmistokehityskäytäntöön, jonka mukaan upotusta voidaan ehkä vain jälkikäteen pitää syötteenä tai kokoonpanotietoina suoraan ohjelman tai muun suoritettavan objektin lähdekoodina tai tietoja sen sijaan, että saisit näitä tietoja ulkoisista lähteistä tai tuottaisit tietoja tai muotoilisi itse ohjelmassa annetulla syötteellä.
Kovakoodausta pidetään anti-mallina. .
Pidetään a n kuvionvastainen, kova koodaus edellyttää, että ohjelman lähdekoodia muutetaan aina, kun syötetiedot tai haluttu muoto muuttuu, kun loppukäyttäjälle saattaa olla helpompaa muuttaa yksityiskohtia jollain tavalla ohjelman ulkopuolella.
Joskus et voi välttää sitä, mutta sen pitäisi olla väliaikaista.
Kova koodaus on usein vaaditaan. Ohjelmoijilla ei ehkä ole dynaamista käyttöliittymäratkaisua loppukäyttäjälle, mutta heidän on silti toimitettava ominaisuus tai vapautettava ohjelma. Tämä on yleensä väliaikaista, mutta ratkaisee lyhyellä aikavälillä paineen koodin toimittamiseksi. Myöhemmin pehmokoodauksen avulla käyttäjä voi välittää parametrit, jotka antavat loppukäyttäjälle tavan muokata tuloksia tai lopputulosta.
- Hardcoding viestien tekeminen vaikeuttaa ohjelman kansainvälistämistä.
- Kovakoodauspolut vaikeuttavat mukautumista toiseen sijaintiin.
Kovakoodauksen ainoa etu näyttää olevan koodin nopea toimittaminen.
Kommentit
- OK , mutta ” ainoa etu ” on usein erittäin tärkeä. Suunnittelupäätökset ohjelmoinnissa koskevat usein tulevaisuuden varmennuksen ja nopean toimituksen välistä kompromissia, ja kovana koodauksena voi sellaisenaan olla täysin hyväksyttävä valinta. Joskus ei kovakoodaus on huono suunnitteluvaihtoehto.
- -1 En ’ usko, että tämä on hyödyllinen vastaus. Pohjimmiltaan sanotaan, että ’ arvojen upottaminen lähdekoodiin sopimattomasti ’ on sopimaton. Luulen, että OP haluaa ohjeita siitä, milloin asiat voivat kuulua lähdekoodiin ja jäävät siten Wikipedia-määritelmän ulkopuolelle.
- Kovan koodauksen pitäisi olla tärkeä osa prosessiasi ja pitää sitä anti-mallina vanhentuneena. mikropalvelujen ikä, kun Angular Tour of Heroes -opetusohjelma on korkean profiilin esimerkki valtavasta ohjelmistotalosta, joka suoraan kumoaa tai jopa valtuuttaa välivaiheen. Lisäksi kun siirryt dynaamiseen dataan, sinun on silti säilytettävä joitain kovakoodattuja tietoja varalla, jota ehkä ohjaa ympäristömuuttuja tai jopa looginen kytkentä itse koodiin, jotta virheet ja tietoturvaongelmat voidaan eristää kunnolla. rivi.
Vastaa
Todella? Ei mahdollisia kelvollisia käyttötapauksia?
Vaikka olen samaa mieltä siitä, että -koodaus on yleensä anti-pattern tai ainakin erittäin huono koodihaju , on paljon tapauksia, joissa se on järkevää. Tässä on muutama.
-
Yksinkertaisuus / YAGNI .
-
Todelliset vakiot, jotka eivät todellakaan koskaan muutu.
eli vakio edustaa luonnollista tai liike vakio tai niiden arvio . (esim. 0, PI, …)
-
Laitteiston tai ohjelmiston ympäristörajoitukset
Upotetuissa ohjelmistoissa muistin ja allokoinnin rajoitukset tulevat mieleen.
-
Suojattu ohjelmisto
Nämä arvot eivät ole käytettävissä, ja / tai niitä on helppo purkaa tai kääntää, esimerkiksi salausmerkit ja suolat. (Huomaa, että niiden pitämisellä kovakoodattuina on myös ilmeisiä haittapuolia …)
-
Luettu koodi
Esiprosessori tai generaattori on määritettävissä, mutta sylkii koodin kovakoodatuilla arvoilla. Ei epätavallista koodikoodissa, joka perustuu sääntömoottoreihin, tai jos sinulla on mallipohjainen arkkitehtuuri.
-
Suorituskykyinen koodi
Tämä on tavallaan ” luotu ” -koodi , vaikka vielä erikoistuneempi. esimerkiksi. ennalta määrätty haku / laskentataulukko, jossa on epätodennäköisiä muutoksia. Tämä ei ole lainkaan epätavallista esimerkiksi grafiikan ohjelmoinnissa.
-
Määritykset ja palautukset
Sekä todellisessa koodissasi että määritystiedostoissasi todennäköisesti on määritysarvoja ja varaukseja useissa tapauksissa (kun kokoonpano ei ole käytettävissä, kun komponentti ei vastaa odotettavissa jne …). Silti on yleensä parasta pitää se koodisi ulkopuolella ja etsiä se, mutta saattaa olla tapauksia, joissa haluat ehdottomasti saada tietyn arvon / reaktion tiettyyn toimintoon / ongelmaan / tilanteeseen.
-
Ja todennäköisesti vielä muutama …
Silti Anti-Pattern ? Joten ylisuunnittelu ! Se kertoo ohjelmiston elinajanodotteesta!
Ei, että sanoisin kaikilla on suuria syitä, ja yleensä minä kiistän kovasti koodatuista arvoista. Mutta jotkut voivat helposti saada passin pätevistä syistä.
Ja älä valvo ensimmäistä yksinkertaisuudesta / YAGNI joko ajattelemalla sen olevan triviaali: ei todennäköisesti ole syytä toteuttaa hullua jäsennintä ja arvon tarkistusta yksinkertaiselle komentosarjalle, joka tekee yhden työn kapeassa käyttötapauksessa hyvin hyvin.
Balin löytäminen on vaikeaa ance. Joskus et ennakoi, että ohjelmisto kasvaa ja kestää kauemmin kuin yksinkertainen komentosarja, jolla se alkoi. Usein se on kuitenkin päinvastoin: me suunnittelemme asioita yli, ja projekti hyllytetään nopeammin kuin pystyt lue käytännönläheinen ohjelmoija. Tuhlait aikaa ja vaivaa asioihin, joita varhainen prototyyppi ei tarvinnut.
Se tarkoittaa tarkasti Anti-Patterns: niitä esiintyy taajuuksien molemmissa ääripäissä, ja niiden ulkonäkö riippuu Koodiasi tarkistavan henkilön herkkyys.
Henkilökohtaisesti minulla olisi tapana mennä aina yleistä reittiä heti, kun huomaan, että jokin saattaa muuttua tai jos ”Meidän oli tehtävä se useammin kuin kerran. Mutta tarkempi lähestymistapa olisi arvioida huolellisesti kovakoodauksen kustannukset verrattuna koodin luomiseen tai luomiseen kyseiseen tilanteeseen.Se on sama kuin sen määrittäminen, onko tehtävä automatisoitava sen sijaan, että tekisit sen manuaalisesti. Ota huomioon vain aika ja kustannukset.
Kommentit
- Se on ’ hauskaa, koska pilotoin tätä itse, ja minulle oli paljon helpompaa, nopeampaa ja puhtaampaa käsitellä arvoja dynaamisesti. Tein sen Python, vaikka uskon, että lopputuote koodataan Java – jos tällä on merkitystä. Se tuntui ylisuunnitellulta, kun koodasin arvot kovasti, koska jokaista tulevaa saraketta oli seurattava useissa paikoissa. / li>
- @Tom: Sanot ’ uudelleen, että kokoonpanohakukirjaston toteuttaminen (tai jopa uudelleenkäyttö) on helpompaa ja nopeampaa kuin kovakoodatun arvon käyttö? sinulle. En myöskään näe ’, kuinka viimeinen lauseesi sopii ylisuunnittelun määritelmään. Se olisi ankerias on selvästi sotkuinen, ja ilmeisesti jos se ’ s koodataan ja kopioidaan sitä ’ vielä pahemmaksi (mikä ei ollut sinun kysymyskysymys, luultavasti ymmärsin väärin, mutta minusta tuntui siltä, että tarkoitit, että arvo ei ole koodattu kovalla paikalla joka kerta, vaan yhdessä kohdassa ohjelmassa).
- Joka tapauksessa minä ’ m huomauttaa vain tapauksista, joissa se ’ d on kelvollinen. ’ m huomautan myös, että se ’ on kiistanalainen viimeisessä lauseessani. Et voi ’ t miellyttää kaikkia ja tiimejä, joilla on vaihtelevia taitotasoja.
- @Tom, älä ’ t myy itsesi liian lyhyeksi. ’ jatkat ehdottomasti jotain. Kuulostaa helpommalta ja vähemmän aikaa vievältä kirjoittaa nopea algoritmi tietojen järjestämiseksi katsomalla osasto- ja työnimikenttiä kovakoodauksen sijaan
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Olisi myös paljon vaikeampaa ylläpitää kovakoodattua taulukkoa siinä tapauksessa, että uusi osasto tai otsikko otettaisiin käyttöön. - Sinulla voi olla monimutkaisempia asioita, jotka ovat silti järkeviä kovakoodata. Yksi, joka tulee mieleen, jonka kirjoitin muutama vuosi sitten, oli kaikki arvoryhmän mahdolliset permutaatiot. Minun täytyi löytää satunnainen kelvollinen suunta, valita satunnainen permutaatio ja sitten saada ensimmäinen kelvollinen tulos oli ylivoimaisesti tehokkain ratkaisu ja koska se oli O (N ^ 3) -silmukassa, tehokkuudella oli merkitystä.
Vastaa
On mahdollista, että kovakoodiarvot ovat hyviä. Esimerkiksi on joitain numeroita, kuten 0 tai yksi tai erilaisia n ^ 2-1-arvoja bittimaskeille, joiden on oltava tiettyjä arvoja algoritmisessa tarkoituksessa. Tällaisten arvojen sallimisella konfiguroitaville ei ole arvoa, ja vain avautuu ongelmien mahdollisuus. Toisin sanoen, jos arvon muuttaminen vain rikkoa asioita, sen pitäisi todennäköisesti olla kovakoodattu.
Antamasi esimerkissä en näe, missä kovakoodaus olisi hyödyllistä. Kaikki mainitsemasi olisi / pitäisi jo olla tietokannassa, otsikot mukaan lukien. Jopa esitystä ajavat asiat (kuten lajittelujärjestys) voidaan lisätä, jos niitä ei ole siellä.
Kommentit
- Kiitos. Lajittelujärjestys oli yksi huoleni, joka minulla oli. Meidän tapauksessamme sillä ei kuitenkaan ole merkitystä ’, enkä ’ edes ajatellut, että se voisi lisätty toisena taulukkona tietokantaan.
- Huomaa, että kaiken tämän hallinta DB: ssä on yksi vaihtoehto. Voit käyttää myös määritystiedostoja tai muita ratkaisuja, mutta kovakoodaus näyttää olevan huono valinta. Vaihtoehtoa käytetään usein, koska ’ on helppo luoda käyttöliittymä, jotta käyttäjät voivat hallita asetuksia. On myös työkaluja, kuten tämä , jotka on erityisesti suunniteltu tähän tarkoitukseen.
Vastaa
Vankka ratkaisu, joka mahdollistaa sen, että arvot, jotka muuten olisi ehkä koodattu, voidaan sen sijaan konfiguroida loppukäyttäjien vaatimusten mukaan näiden arvojen vankka validointi. Laittivatko he tyhjän merkkijonon? Laittivatko he jotain ei-numeerista paikkaan, jossa sen olisi pitänyt olla numero? Tekevätkö he SQL-injektiota? Jne.
Kovakoodauksella vältetään monet näistä riskeistä.
Mikä ei sano, että kovakoodaus on aina tai jopa usein hyvä idea. Tämä on vain yksi huomioon otettavista tekijöistä.