Generisk kode eller kode lett å forstå?

Du bør strukturere malene dine ved å bruke de samme reglene som når du programmerer. Dette betyr i hovedsak å trekke ut vanlige designelementer i separate filer for å unngå duplisering, og dermed oppnå mer gjenbrukbar design. Det er regel nr. 1 ( TØRK ), og metoden kalles refactoring i programmeringsbetingelser.

Den andre regelen er at du skal strebe etter enkelhet og klarhet. Det skal være enkelt å forstå oppsettet og hvor du skal dra når du trenger å endre ting.

Å følge den første regelen til punkt og prikke fører til kraftig nedbrytning av guien din i mange og mange små utdrag som kan gjøre det vanskelig å forstå hvordan oppsettet blir opprettet. Du må jakte mye for å finne ut hvor ting er. Dette bryter med den andre regelen, så du må finne en balanse mellom disse to motsetningene.

Men den beste tilnærmingen er å finne en løsning som helt unngår dette problemet. Jeg tror, i dette tilfellet bør du vurdere en enklere tilnærming helt . Jeg antar at dette er HTML og du nevner «enkle og avanserte» tilstander i GUI. Har du vurdert å alltid generere alle felt og deretter håndtere GUI-logikken i JavaScript? Med andre ord, skriv klientside-kode som skjuler og viser de aktuelle feltene i farten, avhengig av hvilken modus (tilstand) den er i?

Dette har også fordelen av å kunne bytte modus etter behov uten å involvere serveren, og du trenger ikke å gå på akkord med noen av reglene. En annen flott ting er at du kan la frontguttene gjør disse endringene uten å måtte involvere backend-programmererne som vanligvis ikke er så altfor opptatt av å bruke tid på å finjustere og polere designet og interaksjonen.

Kommentarer

• Jeg er uenig i at JS er enklere, hvorfor? De fleste av mine medarbeidere vet ikke ‘ vet ikke JS og Java nettrammer mer og mer lar deg ignorere JS (Richfaces, GWT Nesten alle selskaper bryr seg ikke om JS (jeg tror jeg ble spurt om et JS-spørsmål i alle selskaper jeg noensinne har intervjuet i.) Så mine medarbeidere ville ikke berøre den koden, og de ville bare skrive den om de hadde for å endre det. Ideen din er god, men den er ikke realistisk. pluss hvorfor holde en del av logikken din i java og en del i JS? Jeg tror det er grunnen til at lagrede prosedyrer hadde dødd (og jeg gjorde ke dem).
• @ 0101 Jeg sa ikke ‘ t JS er enklere eller vanskeligere enn noe annet. Det avhenger av ferdighetene dine. Med en kompetent html-koder vil dette ikke være noe problem. Jeg sa at ved å utsette GUI-problemer til GUI-laget (der det hører hjemme), ender du ofte opp med en mye enklere løsning. Dette er fordi GUI er svært dynamiske og interaktive, hvilket språk som JS er laget for. Bare fordi du tror at » ingen selskaper bryr seg om JS «, gjør ikke ‘ t poenget mitt er noe mindre gyldig.
• Jeg tror det gjør det, spørsmålet er hva jeg skal gjøre i min situasjon, og svaret ditt er som » bruk lagrede prosedyrer » og det er ikke gyldig siden ingen bruker det og det ville være vanskelig å forstå hvorfor jeg ville ha brukt dem. Jeg ‘ jeg spør hvilken vei som er bedre for fremtiden siden jeg ‘ er ikke 100% sikker på at valget mitt er det beste (nå beste måten er å ignorere irriterende medarbeidere).
• @ 0101: Å jobbe med web og HTML innebærer mer eller mindre JavaScript (og HTTP og CSS og bilder …), slik at du kan ‘ klandrer meg ikke for å anta at JavaScript var et alternativ. Det ‘ er ikke slik at jeg ‘ ber deg skrive det i sving.
• » Nesten alle selskaper bryr seg ikke om JS » – tror du det seriøst? Rike grensesnitt på nettet har beveget seg i en klientside i mange år nå. Jeg føler at du mangler båten på denne.

Uten å se koden, kan jeg bare spekulere, men jeg vil gjette at for øyeblikket koden din er «på kanten».

For 2 eller 3 modus med et begrenset antall endringer mellom disse modusene hva du har nå er sannsynligvis OK. Skulle det imidlertid være mer komplisert, høres det ut som om det bør omformes til separate sider.

Personlig foretrekker jeg lett å forstå koden – den er mye mer vedlikeholdbar, både for andre utviklere og deg selv når du må plukke den opp igjen seks måneder på linjen.

Det er imidlertid ingen mening i å omorganisere koden nå for å løse et problem som kanskje ikke eksisterer i fremtiden . Du sier at du ikke vet hvor mye kravene vil endres – og det inkluderer ingen endring – så å bruke YAGNI (Du kommer ikke til å trenge det) ikke gjør noe nå.

Merk koden som krever oppmerksomhet i fremtiden, slik at du ikke glemmer det, men ikke endrer (og potensielt bryter) det nå.

Kommentarer

• + 1 – Hvis du er i tvil, er det lett å forstå. Det som er bak i tankene dine om du skal gjøre det generisk, er naturens måte å fortelle deg at du ikke skal ‘ t.

Jeg har gjort stort sett det samme. Tro meg, etter å ha implementert noen forskjellige atferd for hver modus, blir «hovedsiden» et rot nesten umulig å lese. Du vil da bare se en haug med kontrollstrømblokker (kort tid etterfulgt av Matrix digital regn). Jeg fant meg selv å fjerne noen blokker bare for å få et klart bilde av hva som er i en bestemt modus.

Så de «separate sidene» er veien å gå. Men når du gjør det, må du » bekjempe «kode dupliseringsproblem. Det er her kollegaen din kan være galt ved å foreslå fusjoner. Dessverre har jeg også gjort det. I utgangspunktet fungerer det, men det bruker mye dyrebar tid og til slutt ved dårlig sammenslåing er «fellesareal» på sidene ute av synkronisering og sammenslåing blir et virkelig mareritt. Så du har rett i å protestere mot en sammenslåing som en rimelig løsning.

Som du kan se fra mange svar, er den riktige tilnærmingen å trekke ut virkelig «vanlige» deler til eksterne enheter (JSP-sidefragmenter, JSF-utdrag, hva som helst) og inkluder dem på disse sidene.

Kommentarer

• det virkelige problemet med at vanlig kode bare er kontrollene h: inputText + h: outputText for enkelt felt. Jeg føler at det ikke er verdt å bekjempe det. pluss at denne siden kan dø siden den ikke er veldig funksjonell, på grunn av modusene og den er forvirrende til og med andre utviklere (fra brukerens synspunkt).
• Så problemet er egentlig når du skal gjøre overgangen. Du må revurdere splitting etter hver endring. Når siden begynner å bli rotete – del den. Jeg tror kollegaen din også vil være mer komfortabel hvis du anser ideen hans som god, men ennå ikke verdt å implementere den.

Duplisering av kode er praktisk talt aldri noe bra. Når det er sagt, er en liten mengde duplisert ikke mange mer enn to ganger akseptabelt i det virkelige liv – det er bedre å være pragmatisk enn religiøs om det. I ditt tilfelle høres det ut som en større mengde kode og tre steder, så det er litt over min personlige terskel. Dermed lener jeg meg mot den generiske versjonen.Og i alle fall, hvis det fungerer nå, er det ikke nødvendig å berøre det bare av teoretiske grunner.

OTOH når du sier at det kan være flere forskjeller mellom sidene i fremtiden, kan dette bety at på et tidspunkt blir det mer økonomisk å bytte til separate sider (mens vi prøver å minimere duplisering mellom dem ved å trekke ut fellestrekk så mye som mulig). Så revurder situasjonen før hver fremtidige endring.

Dette ser ut som JSF. Hver gjengitt = «…» betyr egentlig at du har en hvis i koden din, noe som gir ekstra kompleksitet.

Jeg har gjort det samme fordi «det er den samme siden bare med noen få forskjeller her og der «og sagt veldig enkelt, fungerer det ikke i det lange løp fordi det ikke er» t samme side, og du må gjøre mer og mer forseggjorte triks for å få den til å fungere skikkelig, slik at den blir unødvendig vanskelig å vedlikeholde.

Hvis du bruker JSF med fasetter i stedet for JSP (som du Hvis du kunne) kan du bygge XML-fragmenter som tilsvarer en blokk på siden, som du deretter kan inkludere der det er nødvendig. Dette vil gi deg modulærhet og fremdeles tillate deg å gjenbruke innhold på tvers av sider.

Hør på kollegaen din. Han har rett.

Kommentarer

• vennligst se min redigering
• @ 0101, mistenkte jeg akkurat dette. Ikke ‘ ikke gjør det, det er veien til galskap – mest sannsynlig for deg – en og absolutt for fremtidige vedlikeholdere.
• det virkelige problemet er at min vei er den beste måten. hvis jeg gjorde 3 sider enn noen kunne endre bare en av sidene og ikke tenke på de andre. Jeg ønsker min versjon som fremtidig vedlikeholder.
• Jeg tror at koden min får fremtidig vedlikehold til å tenke på andre saker. Hvis du var en ny programmerer for prosjektet og i feilsøkingsprogrammet fant ut at du trenger å endre kode i baseFormBasic.xhtml, vil du også endre den i baseFormAdv og baseFormSpec?
• @ 0101, hvorfor spørre hva som er best, hvis du bare vil få bekreftet din forutinntatte mening?

Er det en sjanse til å generere siden bruker du kode? I dette tilfellet, hva med noe som:

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

Og i gjengivelseskoden

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

Eller i OOP-stil:

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

Kommentarer

• nei, det er ingen endring . Jeg ville bli korsfestet hvis jeg gjorde det. pluss at det skaper nøyaktig det samme problemet. hvis == gjengitt.
• Det er ikke det eksakte problemet siden det trekker ut sidelogikken. Gjør bare en oppgave, i stedet for to.
• kanskje, men jeg føler det er det samme. grunnen min er at å vise felt bare er en ting som er annerledes. Det er også forskjellige plasseringer og noen ganger etiketter. pluss det er nettprogrammeringen, så jeg kan ‘ t gjøre det slik.

Essensen av dette spørsmålet ser ut til å være: når du har tre like websider med noen mindre forskjeller, er det bedre å duplisere de tre sidene og endre hver etter behov, eller bygge inn på en enkelt side logikken for å dynamisk gjengi siden i henhold til hvilken «modus «blir sett på.

For ordens skyld er jeg en JSF-fyr, og jeg liker det, og jeg bruker betinget gjengivelse.

Hvis du velger å ha tre sider, er det en risiko for at vedlikehold ikke vil bruke riktig på alle tre sidene.

Hvis du velger å bruke betinget gjengivelse, løser du problemet, men du har flyttet litt forretningslogikk inn på siden din, som kanskje trenger litt tanke.

Jeg personlig ville ikke hatt noe problem med bruk av betinget gjengivelse, men vil virkelig se moduslogikken flyttet til en bønner, f.eks: i stedet for:

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

Jeg liker:

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

Hvor bønnen håndterer logikk og returnerer sant eller usant for å kontrollere gjengivelsen av elementet.

Årsaken er at modusen som vises, kan ha behov for å kontrollere mer enn bare denne siden, kan være nødvendig å vedvare den utover til og med brukerens eneste økt, eller du må kanskje endre modus helt nedover vei.

Eller du kan akseptere at begge tilnærmingene har potensielle ulemper, og alle ulempene ser ut til å være angående lindrende smerter langs veien, og er enige om å bekymre deg for det ytterligere når en av de «nedover veien» tingene faktisk komme opp, og deretter ta bedre avgjørelser nå som mer faktisk er kjent om hvordan kravene kan endres.