Cod generic sau cod ușor de înțeles?

Ar trebui să vă structurați șabloanele folosind aceleași reguli ca și când programați. Aceasta înseamnă, în esență, extragerea elementelor de proiectare comune în fișiere separate pentru a evita duplicarea și, astfel, pentru a realiza un design mai reutilizabil. Aceasta este regula # 1 ( DRY ) și metoda se numește refactoring în termeni de programare.

A doua regulă este că ar trebui să te străduiești să simplitate și claritate. Ar trebui să fie ușor să înțelegeți aspectul și unde să mergeți când trebuie să schimbați lucrurile.

Urmarea primei reguli la litera duce la descompunerea grea a gui-ului dvs. în foarte multe fragmente mici, ceea ce poate face dificilă înțelegerea modului în care este creat aspectul. Trebuie să vânezi foarte mult pentru a afla unde sunt lucrurile. Aceasta încalcă a doua regulă, așa că trebuie să găsiți un echilibru între aceste două contrarii.

Dar cea mai bună abordare este de a găsi o soluție care să evite această problemă complet. Cred că, în acest caz, ar trebui să luați în considerare o abordare mai simplă cu totul . Presupun că acesta este HTML și menționezi stări „simple și avansate” în GUI. Ați luat în considerare întotdeauna generarea câmpurilor toate și apoi gestionați logica GUI în JavaScript? Cu alte cuvinte, scrieți codul clientului care ascunde și afișează câmpurile relevante din mers în funcție de modul (starea) în care se află?

Acest lucru are, de asemenea, avantajul de a putea comuta modul la cerere fără a implica serverul și nu trebuie să compromiteți niciuna dintre reguli. Un alt lucru grozav este că puteți lăsa băieții front-end faceți aceste schimbări fără a fi nevoie să implicați programatorii de back-end care, de obicei, nu sunt prea dornici să petreacă timp modificând și lustruind designul și interacțiunea.

Comentarii

• Nu sunt de acord că JS este mai simplu, de ce? Majoritatea colegilor mei nu ‘ știu că cadrele web JS și Java vă permit tot mai mult să ignorați JS (Richfaces, GWT Aproape tuturor companiilor nu le pasă de JS (cred că mi s-a pus o întrebare JS în toate companiile în care am intervievat vreodată). Deci colegii mei nu ar atinge codul respectiv și l-ar re-scrie doar dacă ar fi avut să o schimbi. Ideea ta este bună, dar nu este realistă. plus de ce să păstrezi o parte din logica ta în Java și parte în JS? Cred că acesta este motivul pentru care procedurile stocate au murit (și am făcut ke le).
• @ 0101 ‘ nu am spus că JS este mai simplu sau mai greu decât orice. Depinde de abilitățile tale. Cu un codor html competent, aceasta nu ar fi o problemă. Am spus că amânând problemele GUI la nivelul GUI (unde aparține), de multe ori ajungeți la o soluție mult mai simplă. Acest lucru se datorează faptului că GUI-urile sunt extrem de dinamice și interactive, pentru care este creat un limbaj precum JS. Doar pentru că credeți că ” nici unei companii nu îi pasă de JS „, nu face ‘ punctul meu de vedere este mai puțin valabil.
• Cred că este un fel, întrebarea este ce să fac în situația mea și răspunsul dvs. este ca ” utilizați procedurile stocate ” și acest lucru nu este valabil deoarece nimeni nu îl folosește și ar fi greu de înțeles de ce le-aș fi folosit. ‘ mă întreb care este calea cea mai bună pentru viitor, deoarece ‘ nu sunt 100% sigur că alegerea mea este cea mai bună (acum cel mai bun mod este de a ignora colegii enervanți enervanți).
• @ 0101: Lucrul cu web și HTML implică mai mult sau mai puțin JavaScript (și HTTP și CSS și imagini …), astfel încât să puteți nu mă învinovățesc cu adevărat pentru că am presupus că JavaScript este o opțiune. ‘ nu este ca și cum ți-aș cere ‘ să îți cer să o scrii în Swing.
• ” Aproape tuturor companiilor nu le pasă de JS ” – credeți asta serios? Interfețele bogate de pe web se deplasează în direcția clientului de mulți ani. Simt că îți lipsește barca de pe aceasta.

Fără a vedea codul, pot doar speculează, dar aș presupune că în acest moment codul tău este „pe margine”.

Pentru 2 sau 3 moduri cu un număr limitat de modificări între acele moduri ceea ce ai acum este probabil OK. Cu toate acestea, dacă ar fi mai complicat, atunci se pare că ar trebui refactorizat în pagini separate.

Personal prefer codul ușor de înțeles – este mult mai ușor de întreținut, atât pentru alți dezvoltatori, cât și pentru dvs. trebuie să-l ridicați din nou 6 luni mai jos.

Cu toate acestea, nu are sens să refacem codul acum pentru a rezolva o problemă care s-ar putea să nu existe în viitor. . Spuneți că nu știți cât de mult se vor schimba cerințele – și asta nu include nicio modificare – așa că aplicarea YAGNI („Nu ai nevoie”) nu face nimic acum.

Marcă codul ca necesită atenție în viitor, astfel încât să nu-l uitați, dar să nu-l schimbați (și potențial să-l rupeți) acum.

Comentarii

• + 1 – Dacă aveți îndoieli, mergeți ușor de înțeles. Neagră din spatele minții cu privire la faptul dacă ar trebui să o faceți generică este un mod natural de a vă spune că nu ar trebui să ‘ t.

Am făcut cam același lucru. Crede-mă, după ce am implementat câteva comportamente diferite pentru fiecare mod, „pagina principală” devine o mizerie aproape imposibil de citit. Veți vedea apoi doar o grămadă de blocuri de flux de control (urmat în scurt timp de ploaia digitală Matrix). M-am trezit eliminând câteva blocuri doar pentru a avea o vedere clară a ceea ce se află într-un anumit mod.

Deci, „paginile separate” sunt calea de urmat. Cu toate acestea, atunci când faci asta, trebuie să „ luptă împotriva „problemei de duplicare a codului. Aici colegul tău ar putea greși sugerând îmbinări. Din păcate, așa am făcut și eu. Practic funcționează, dar consumă mult timp prețios și, în cele din urmă, prin îmbinarea slabă „zona comună” a paginilor nu este sincronizată, iar îmbinarea devine un adevărat coșmar. Așadar, aveți dreptate când obiectați o îmbinare ca soluție rezonabilă.

După cum puteți vedea din multe răspunsuri, abordarea corectă este extragerea unor părți cu adevărat „comune” către entități externe (fragmente de pagină JSP, fragmente JSF, orice) și includeți-le în acele pagini.

Comentarii

• adevărata problemă că codul comun este doar comenzile h: inputText + h: outputText pentru câmp unic. Simt că nu merită să lupt cu ea. plus această pagină ar putea să moară deoarece nu este cu adevărat funcțională, din cauza modurilor și este confuză chiar și pentru alți dezvoltatori (din punctul de vedere al utilizatorului).
• Deci, problema este cu adevărat când să faci tranziția. Trebuie să reconsiderați împărțirea după fiecare modificare. Când pagina începe să fie dezordonată – împărțiți-o. Cred că și colegul dvs. de muncă va fi mai confortabil dacă considerați ideea sa bună, dar nu merită încă implementată.

Duplicarea codului nu este practic niciodată un lucru bun. Acestea fiind spuse, o cantitate mică duplicată nu mai mult de două ori este acceptabilă în viața reală – este mai bine să fii pragmatic decât religios în legătură cu aceasta. În cazul dvs., sună ca o cantitate mai mare de cod și 3 locuri, așa că depășește ușor pragul meu personal. Astfel mă aplec spre versiunea generică.Și, în orice caz, dacă funcționează acum, nu este nevoie să o atingeți doar din motive teoretice.

OTOH atunci când spuneți că pot exista mai multe diferențe între pagini în viitor, acest lucru ar putea însemna că la un moment dat devine mai economic să treci la pagini separate (în timp ce te străduiești să reduci la minimum duplicarea dintre acestea prin extragerea de puncte comune cât mai mult posibil). Deci reevaluați situația înainte de fiecare schimbare viitoare.

Arată ca JSF. Fiecare randat = „…” înseamnă, în esență, că aveți un cod în if, care provoacă o complexitate suplimentară.

Am „făcut același lucru pentru că„ este aceeași pagină doar cu câteva diferențe aici și acolo „și pus foarte simplu, nu funcționează pe termen lung, deoarece isn” t aceeași pagină și va trebui să faceți trucuri din ce în ce mai elaborate pentru a o face să funcționeze corect, provocând o inutilă greutate de întreținere.

Dacă utilizați JSF cu fațete în loc de JSP (pe care dacă ai putea) atunci poți construi fragmente XML corespunzătoare unui bloc al paginii, pe care apoi le poți include acolo unde este necesar. Acest lucru îți va cumpăra modularitate și îți va permite totuși să reutilizezi conținut pe mai multe pagini.

Ascultă-l pe colegul tău de serviciu. Are dreptate.

Comentarii

• vă rugăm să consultați editarea mea
• @ 0101, bănuiam exact asta. Nu ‘ nu o faceți, este drumul spre nebunie – cel mai probabil pentru voi – un Și cu siguranță pentru viitorii întreținători.
• adevărata problemă este că calea mea este cea mai bună cale. dacă aș face 3 pagini, cineva ar putea schimba doar una dintre pagini și nu mă gândesc la celelalte. Mi-aș dori versiunea mea ca viitor întreținător.
• Cred că codul meu îl face pe viitorul menținut să se gândească la alte cazuri. Dacă ați fi un programator nou pentru proiect și în depanator ați descoperit că trebuie să schimbați codul în baseFormBasic.xhtml, l-ați schimba și în baseFormAdv și baseFormSpec? dacă doriți doar să vi se confirme opinia preconcepută?

Există vreo șansă să generați pagina folosind cod? În acest caz, ce zici de ceva de genul:

page1 = { showField1 = true; showField2 = false; showField3 = true; } page2 = { showField1 = true; showField2 = false; showField3 = false; } 

Și în codul de redare a paginilor

if page.showField1 then .... if page.showField2 then .... 

Sau în stil OOP:

class Page1 { renderField1() { ...} renderField2() {} renderField2() { ...} } class Page2 { renderField1() { ...} renderField2() {} renderField2() {} } 

Comentarii

• nu, nu există nicio modificare . Aș fi răstignit dacă aș face-o. în plus, creează exact aceeași problemă. dacă == redat.
• Nu este problema exactă, deoarece extrage logica paginii. Făcând o singură sarcină, în loc de două.
• poate, dar simt că este la fel. motivul meu este că afișarea câmpurilor este doar un lucru diferit, există și plasare diferită și, uneori, etichete. plus programarea web, așa că nu pot ‘ să o fac așa.

Esența acestei întrebări pare să fie: atunci când aveți trei pagini web foarte asemănătoare, cu câteva diferențe minore, este mai bine să copiați aceste trei pagini și să le modificați după cum este necesar sau să construiți într-o singură pagină logica pentru a reda pagina în mod dinamic în funcție de care „este vizualizat.

Pentru înregistrare, sunt un tip JSF și îmi place și folosesc redarea condiționată.

Dacă optați pentru a avea trei pagini, există riscul ca pe măsură ce se produc modificări, administratorul să nu aplice acest lucru corect tuturor celor trei pagini.

Dacă optați pentru utilizarea redării condiționate, rezolvați această problemă, dar ați mutat o anumită logică de afaceri în pagina dvs. care ar putea avea nevoie de ceva gândire.

Personal, nu aș avea nicio problemă cu utilizarea redării condiționate, dar aș vrea să văd logica modului mutată într-un bean de backing, de exemplu: în loc de:

<h:output rendered="mode=2" value="Name: " />

Îmi place:

<h:output rendered="#{myBean.advancedMode}" value="Name: " />

În cazul în care bobul manipulează logică și returnează adevărat sau fals pentru a controla redarea elementului.

Motivul este că modul vizualizat poate avea nevoie să controleze mai mult decât această pagină, poate fi necesar să o persiste dincolo de sesiunea unică a utilizatorului sau poate fi necesar să schimbați modurile complet în jos drum.

Sau, puteți accepta că oricare dintre abordări are dezavantaje potențiale și toate dezavantajele par să se refere la ameliorarea durerilor de pe drum și sunteți de acord să vă faceți griji în continuare atunci când una dintre acele lucruri „de pe drum” de fapt, veniți și apoi luați decizii mai bune acum, deoarece se știe mai multe despre modul în care cerințele s-ar putea schimba.