Eu sunt un programator autodidact, novice-ish, așa că îmi cer scuze dacă nu pun limbajul programatorului.
Lucrez la un proiect în care ofer date, care vor fi actualizate continuu, dezvoltatorilor care vor crea în esență un instrument pentru a genera rapoarte din interogări cu privire la date.
Se pare că toți cei implicați cred că că au nevoie să codeze valorile datelor (nu schema, ci domeniile / valorile în sine) în programul de generare a rapoartelor.
De exemplu, să presupunem că raportăm despre personal; raportul ar fi împărțit în categorii, cu o rubrică pentru fiecare departament, iar apoi sub fiecare rubrică de departament vor fi subpoziții de titluri de posturi, iar apoi sub fiecare subpoziție va fi o listă de angajați. pe de altă parte, aș crede că ar putea / ar interoga aceste lucruri în timp de execuție, ar putea sorta înregistrările în funcție de ele și vor genera anteturi de raport dinamic în funcție de ce valoare Există acolo.
Deoarece lista valorilor potențiale se va schimba în timp (de exemplu, departamentele vor fi create / redenumite, vor fi adăugate noi titluri de posturi), codul va trebui să fie actualizat continuu. Mi se pare că am putea sări peste pașii de întreținere a codului și să organizăm dinamic rapoartele.
Deoarece nu sunt dezvoltator, „mă întreb ce îmi lipsește”. Ce avantaje ar putea avea valorile de codare dură într-un instrument ca acesta? Este de obicei modul în care sunt concepute programele?
Comentarii
- posibil duplicat al Eliminarea codului dur valorile și designul defensiv față de YAGNI
- Sunt rapoarte încrucișate, ceea ce înseamnă că valorile din rânduri ar trebui să apară sub formă de coloane?
- @Brendan – Dacă codificați valorile din raport , ‘ va trebui să schimbați lista în DOUĂ locuri (sursa de date și raportul), în timp ce dacă raportul este dinamic, trebuie să îl modificați doar într-o singură locație (raportul) .
- @Brendan, de ce ați ajunge cu trei locații? Poate că înțelegerea mea este incorectă, dar ‘ prevăd o interogare sql pentru a prelua date dintr-o bază de date, aplicația va agrega / grupa valorile returnate de, de exemplu, departamentul. Dacă ‘ sunteți dispus să aveți cheltuielile generale pentru mai multe interogări db, puteți selecta departamente / titluri de rol distincte, dacă doriți cu adevărat. Datele nu există în niciun moment în mai multe locații – raportul este condus de date.
- @Brendan De asemenea, nu sunt de acord cu definiția dvs. de a fi într-un singur loc – modul în care îl descrieți ‘ s în mai multe locații, împrăștiate în codul sursă.
Răspuns
Wikipedia:
Hard codarea (de asemenea, hard-coding sau hardcoding) se referă la practica de dezvoltare software de a încorpora ceea ce poate, poate doar retrospectiv, să fie considerat o intrare sau date de configurare direct în codul sursă al unui program sau alt obiect executabil, sau formatarea fixă a date, în loc să obțină acele date din surse externe sau să genereze date sau să formateze în programul însuși cu intrarea dată.
Hard-coding este considerat un antipattern .
Considerat a n anti-model, codarea dură necesită modificarea codului sursă al programului de fiecare dată când se modifică datele de intrare sau formatul dorit, atunci când ar putea fi mai convenabil pentru utilizatorul final să schimbe detaliile prin unele mijloace în afara programului.
Uneori nu o puteți evita, dar ar trebui să fie temporară.
Codificarea dură este deseori necesare. Este posibil ca programatorii să nu aibă o soluție de interfață dinamică pentru utilizatorul final, dar trebuie să livreze în continuare funcția sau să elibereze programul. Acest lucru este de obicei temporar, dar rezolvă, într-un sens scurt, presiunea de a furniza codul. Ulterior, softcoding-ul se face pentru a permite utilizatorului să transmită parametrii care oferă utilizatorului final o modalitate de a modifica rezultatele sau rezultatul.
- Hardcoding de mesaje face dificilă internaționalizarea unui program.
- Căile de codare dură fac dificilă adaptarea la o altă locație.
Singurul avantaj al codificării hard pare să fie livrarea rapidă a codului.
Comentarii
- OK , dar ” singurul avantaj ” este adesea extrem de important. Deciziile de proiectare în programare se referă adesea la compromisul dintre verificarea viitoare și livrarea rapidă acum și, ca atare, codificarea dură poate fi o alegere perfect acceptabilă. Uneori codarea dură nu este o alegere proastă de proiectare.
- -1 Nu cred că ‘ cred că acesta este un răspuns util. În esență, se spune că ‘ încorporarea valorilor în codul sursă în mod necorespunzător ‘ este inadecvată. Cred că PO dorește îndrumări despre momentul în care lucrurile pot aparține codului sursă și, prin urmare, nu intră în definiția dvs. Wikipedia.
- Codificarea dură ar trebui să fie o parte vitală a procesului dvs. și considerând că un anti-model este învechit în vârsta micro-serviciilor, tutorialul Angular Tour of Heroes fiind un exemplu de profil înalt al unei imense case de software care încurajează direct sau chiar impune ca etapă intermediară. Mai mult decât atât, atunci când treceți la date dinamice, ar trebui să păstrați în continuare unele date codificate ca o rezervă, probabil controlate de o variabilă de mediu sau chiar de o comutare booleană asupra codului în sine, astfel încât erorile și problemele de securitate să poată fi izolate în mod corespunzător în linie.
Răspuns
Chiar? Nu există cazuri de utilizare valabile posibile?
Deși sunt de acord că codificare dură este în general un anti-model sau cel puțin un miros de cod foarte rău , există o mulțime de cazuri în care are sens. Iată câteva.
-
Simplitate / YAGNI .
-
Constantele reale care nu se schimbă niciodată.
adică constanta reprezintă un natural sau business constantă sau o aproximare a uneia. (de ex. 0, PI, …)
-
Constrângeri de mediu hardware sau software
În software-ul încorporat, îmi vin în minte constrângerile de memorie și alocare.
-
Software securizat
Aceste valori nu sunt disponibile și / sau ușor de decodat sau de inginerie inversă, de ex. jetoane și săruri criptografice. (Rețineți că păstrarea lor codificată dur are și dezavantaje evidente …)
-
Cod generat
Preprocesorul sau generatorul dvs. este configurabil, dar scuipă cod cu valori codate în mod dur. Nu este neobișnuit pentru codul care se bazează pe motoare de reguli sau dacă aveți o arhitectură bazată pe model.
-
Cod de înaltă performanță
Într-un fel, acesta este codul ” generat ” , deși și mai specializat. de exemplu. un tabel predefinit de căutare / calcul cu modificări improbabile. Acest lucru nu este deloc neobișnuit în programarea grafică, de exemplu.
-
Configurare și alternative
Atât în codul dvs. actual, cât și în fișierele dvs. de configurare, este probabil să aveți valori de configurare și alternative pentru mai multe cazuri (când configurația nu este disponibilă, atunci când o componentă nu răspunde ca așteptat, etc …). Totuși, este în general cel mai bine să îl păstrați în afara codului dvs. și să-l căutați, dar ar putea exista cazuri în care doriți absolut să aveți o anumită valoare / reacție la o anumită acțiune / problemă / situație.
-
Și probabil încă câteva …
Încă un Anti-Pattern ? La fel este Suprainginere ! Este vorba despre speranța de viață a software-ului dvs. !!
Nu că spun există toate motive grozave și, în general, consider că valorile sunt codificate greu. Dar unii pot obține cu ușurință o trecere din motive valide.
Și nu supravegheați primul în ceea ce privește simplitatea / YAGNI fie gândindu-se că este banal: probabil că nu există niciun motiv pentru a implementa un analizor nebun și un verificator de valoare pentru un script simplu care face o treabă pentru un caz de utilizare îngust foarte bine.
Este dificil să găsești balul ance. Uneori nu prevedeți că un software va crește și va dura mai mult decât scriptul simplu pe care l-a început. Adesea, totuși, este invers: proiectăm lucruri în exces, iar un proiect este depozitat mai repede decât poți citiți Programatorul pragmatic. Ați pierdut timp și efort pe lucruri de care nu a fost nevoie de un prototip timpuriu.
Acestea sunt lucrurile rele cu Anti-Patterns: acestea sunt prezente în ambele extreme ale spectrului, iar aspectul lor depinde de sensibilitatea persoanei care vă examinează codul.
Personal, aș tinde să merg întotdeauna pe calea generică, de îndată ce văd că ceva s-ar putea schimba sau dacă „A trebuit să o fac de mai multe ori. Dar o abordare mai precisă ar fi să evalueze cu atenție costul codificării hard față de generarea sau generarea codului dvs. pentru acea situație specifică.”Este la fel ca a determina dacă o sarcină merită automatizată, în loc să o faceți manual. Doar luați în considerare timpul și costul.
Comentarii
- Acest ‘ e amuzant, deoarece am pilotat asta și eu și mi-a fost mult mai ușor, mai rapid și mai curat să gestionez valorile dinamic. Am făcut-o în Python, întrucât cred că produsul final va fi codat în Java – dacă acest lucru face diferența. S-a simțit supradimensionat atunci când codificam hard în valori, deoarece fiecare coloană care trebuia urmată trebuia urmărită în mai multe locuri.
- @Tom: ‘ spuneți că a fost mai ușor și mai rapid să implementați (sau chiar să reutilizați) o bibliotecă de căutare a configurației decât să utilizați o valoare codificată? pentru tine. De asemenea, nu ‘ nu văd cum se potrivește ultima teză cu definiția supra-ingineriei. eel, evident, dezordonat și, evident, dacă ‘ este codificat și duplicat ‘ este și mai rău (ceea ce nu era scopul tău întrebare întrebare, probabil că am înțeles greșit, dar mi s-a părut că ai vrut să spui că valoarea nu a fost codificată la locul lor de fiecare dată, ci într-un singur punct din program).
- Oricum, eu ‘ am doar să subliniez cazurile în care ‘ ar fi valid. ‘ subliniez, de asemenea, că ‘ ar fi controversat în ultima mea propoziție. Puteți ‘ să vă rog să vă rog pe toată lumea și echipele să aibă persoane cu niveluri de calificare diferite.
- @Tom, nu ‘ t vinde-te prea scurt. Sunteți ‘ cu siguranță vă referiți la ceva. Sună mai ușor și consumă mai puțin timp pentru a scrie un algoritm rapid pentru organizarea datelor, uitându-vă la câmpurile Departament și Titlu post, spre deosebire de codificarea dură
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. De asemenea, ar fi mult mai dificil să mențineți matricea codificată în caz de introducere a unui nou departament sau titlu. - Puteți avea lucruri mai complexe care sunt încă sensibile la codul dur. Unul care îmi vine în minte că am scris cu câțiva ani în urmă a fost toate permutările posibile ale unui set de valori. Aveam nevoie să găsesc o direcție validă aleatorie, alegând o permutare aleatorie și apoi luând primul rezultat valid a fost de departe cea mai eficientă soluție și, întrucât era într-o buclă O (N ^ 3), contează eficiența.
Răspuns
Uneori este OK pentru valorile hard-code. De exemplu, există unele numere precum 0, sau unul sau diferite valori n ^ 2-1 pentru măștile de biți care trebuie să fie anumite valori în scopuri algoritmice. Permiterea unor astfel de valori configurabile nu are nicio valoare și deschide doar posibilitatea apariției unor probleme. Cu alte cuvinte, dacă schimbarea unei valori ar rupe doar lucrurile, probabil ar trebui să fie hardcoded.
În exemplul pe care l-ați dat, nu văd unde ar fi utilă hard-coding. Tot ceea ce menționați ar trebui / ar trebui să fie deja în baza de date, inclusiv titluri. Chiar și lucrurile care conduc prezentarea (cum ar fi ordinea de sortare) pot fi adăugate dacă nu sunt acolo.
Comentarii
- Mulțumesc. Ordinea de sortare a fost singura îngrijorare pe care am avut-o. Cu toate acestea, în cazul nostru nu contează ‘ și nici nu am considerat ‘ că nu ar putea fi adăugat ca un alt tabel în baza de date.
- Ar trebui să rețin că gestionarea tuturor acestora în DB este o opțiune. Puteți utiliza, de asemenea, fișiere de configurare sau alte soluții, dar codul hard pare a fi o alegere slabă. DB opțiunea este adesea utilizată deoarece ‘ este ușor de creat o interfață care să permită gestionarea opțiunilor de către utilizatori. Există și instrumente precum acest care sunt special concepute în acest scop.
Răspuns
Implementarea unei soluții robuste care permite ca valorile care altfel ar fi putut fi codificate să fie configurabile în funcție de cerințele utilizatorilor finali validarea robustă a acestor valori. Au pus într-un șir gol? Au pus ceva nenumeric acolo unde ar fi trebuit să fie un număr? Fac injecție SQL? Etc.
Codificarea dură evită multe dintre aceste riscuri.
Ceea ce nu înseamnă că codificarea dură este întotdeauna, sau chiar deseori, o idee bună. Aceasta este doar unul dintre factorii de luat în calcul.