Generisk kode eller kode let at forstå?

Du skal strukturere dine skabeloner ved hjælp af de samme regler som ved programmering. Dette betyder i det væsentlige at udtrække almindelige designelementer i separate filer for at undgå dobbeltarbejde og dermed opnå mere genanvendeligt design. Det er regel nr. 1 ( TØR ), og metoden kaldes refactoring i programmeringsbetingelser.

Den anden regel er, at du skal stræbe efter enkelhed og klarhed. Det skal være let at forstå layoutet, og hvor man skal hen, hvornår skal man ændre ting.

At følge den første regel til punkt og prikke fører til kraftig nedbrydning af din gui i masser og masser af små uddrag, som kan gøre det svært at forstå, hvordan layoutet oprettes. Du er nødt til at jage meget for at finde, hvor tingene er. Dette overtræder den anden regel, så skal du finde en balance mellem disse to modsætninger.

Men den bedste tilgang er at finde en løsning, der helt undgår dette problem. Jeg tror, i dette tilfælde skal du overveje en enklere tilgang helt . Jeg antager, at dette er HTML, og du nævner “enkle og avancerede” tilstande i GUI. Har du overvejet altid at generere alle felter og derefter håndtere GUI-logikken i JavaScript? Skriv med andre ord kode på klientsiden, der skjuler og viser de relevante felter i farten afhængigt af hvilken tilstand (tilstand) den er i?

Dette har også fordelen ved at kunne skifte tilstand efter behov uden at involvere serveren, og du behøver ikke at gå på kompromis med nogen af reglerne. En anden god ting er, at du kan lade frontendens fyre udfør disse ændringer uden at skulle involvere backend-programmørerne, som normalt ikke er så alt for ivrige efter at bruge tid på at finjustere og polere designet og interaktionen.

Kommentarer

• Jeg er uenig i, at JS er enklere, hvorfor? De fleste af mine medarbejdere kender ‘ ikke JS og Java webrammer mere og mere giver dig mulighed for at ignorere JS (Richfaces, GWT Næsten alle virksomheder er ligeglade med JS (jeg tror, jeg blev bedt om et JS-spørgsmål i alle virksomheder, jeg nogensinde har interviewet i). Så mine kolleger ville ikke røre ved den kode, og de ville bare omskrive den, hvis de havde for at ændre det. Din idé er god, men den er ikke realistisk plus hvorfor beholde en del af din logik i java og del i JS? Jeg tror, det er grunden til, at lagrede procedurer var død (og jeg gjorde li ke dem).
• @ 0101 Jeg sagde ikke ‘ Jeg sagde, at JS er enklere eller sværere end noget andet. Det afhænger af dine færdigheder. Med en kompetent html-koder ville dette ikke være noget problem. Jeg sagde, at ved at udskyde GUI-problemer til GUI-laget (hvor det hører hjemme) ender du ofte med en meget enklere løsning. Dette skyldes, at GUIer er meget dynamiske og interaktive, hvilket sprog som JS er lavet til. Bare fordi du tror, at ” ingen virksomheder bryr sig om JS “, gør det ikke ‘ t mit punkt er noget mindre gyldigt.
• Jeg tror, det gør det, spørgsmålet er, hvad jeg skal gøre i min situation, og dit svar er som ” brug lagrede procedurer ” og det er ikke gyldigt, da ingen bruger det, og det ville være svært at forstå, hvorfor jeg ville have brugt dem. Jeg ‘ spørger, hvilken vej der er bedre for fremtiden, da jeg ‘ er ikke 100% sikker på, at mit valg er det bedste (nu bedste måde er at ignorere irriterende kollegaer.
• @ 0101: At arbejde med web og HTML betyder mere eller mindre JavaScript (og HTTP og CSS og billeder …), så du kan ‘ giver mig ikke skylden for at antage, at JavaScript var en mulighed. Det ‘ er ikke som jeg ‘ beder dig om at skrive det i gynge.
• ” Næsten alle virksomheder er ligeglade med JS ” – tror du virkelig på det? Rige grænseflader på nettet har bevæget sig i en klientside i mange år nu. Jeg føler at du mangler båden på denne.

Uden at se koden kan jeg kun spekulere, men jeg vil gætte, at i øjeblikket din kode er “på kanten”.

For 2 eller 3 tilstande med et begrænset antal ændringer mellem disse tilstande, hvad du har nu er sandsynligvis OK. Men hvis det skulle være mere kompliceret, lyder det som om det skal omformuleres til separate sider.

Personligt foretrækker jeg let at forstå kode – det er meget mere vedligeholdeligt, både for andre udviklere og dig selv, når du er nødt til at hente den igen 6 måneder senere.

Der er dog ingen mening i at omlægge koden nu for at løse et problem, der muligvis ikke eksisterer i fremtiden . Du siger, at du ikke ved, hvor meget kravene vil ændre sig – og det inkluderer ingen ændringer – så anvendelse af YAGNI (du har ikke brug for det) gør ikke noget nu.

Marker koden som kræver opmærksomhed i fremtiden, så du ikke glemmer det, men ikke ændre (og muligvis bryde) det nu.

Kommentarer

• + 1 – Hvis du er i tvivl, er det let at forstå. Munden bag på dit sind om, hvorvidt du skal gøre det generisk, er naturens måde at fortælle dig, at du ikke skal ‘ t.

Jeg har gjort stort set det samme. Tro mig, efter at have implementeret få forskellige adfærd for hver tilstand, bliver “hovedsiden” et rod næsten umuligt at læse. Du vil så kun se en flok kontrolflowblokke (kort efterfulgt af Matrix digital regn). Jeg befandt mig ved at fjerne nogle blokke bare for at få et klart overblik over, hvad der er i en bestemt tilstand.

Så de “separate sider” er vejen at gå. Men når du gør det, skal du ” bekæmp “problem med duplikering af kode. Det er her, din kollega kan være forkert ved at foreslå fusioner. Desværre har jeg også gjort det. Dybest set fungerer det, men det bruger meget dyrebar tid og til sidst ved dårlig fletning er “fælles område” på siderne ude af synkronisering, og fletning bliver et rigtigt mareridt. Så du har ret i at gøre indsigelse mod en fusion som en rimelig løsning.

Som du kan se fra mange svar, er den korrekte tilgang at udtrække virkelig “fælles” dele til eksterne enheder (JSP-sidefragmenter, JSF-uddrag, uanset hvad) og inkluder dem på disse sider.

Kommentarer

• det virkelige problem, at almindelig kode bare er kontrolelementerne h: inputText + h: outputText for enkelt felt. Jeg føler, at det ikke er værd at bekæmpe det. plus denne side kan dø, da den ikke rigtig fungerer, på grund af tilstande og dens forvirrende selv for andre udviklere (fra brugerens synspunkt).
• Så problemet er virkelig, hvornår man skal foretage overgangen. Du er nødt til at genoverveje splittelse efter hver ændring. Når siden begynder at være rodet – del den. Jeg tror, at din kollega også vil være mere behagelig, hvis du finder hans idé god, men endnu ikke værd at implementere.

Kopiering af kode er praktisk taget aldrig en god ting. Når det er sagt, er en lille mængde duplikeret ikke mange mere end to gange acceptabel i det virkelige liv – det er bedre at være pragmatisk end religiøs om det. I dit tilfælde lyder det som en større mængde kode og 3 steder, så det er lidt over min personlige tærskel. Således læner jeg mig mod den generiske version.Og under alle omstændigheder, hvis det fungerer nu, er der ingen grund til at røre ved det kun af teoretiske grunde.

OTOH når du siger, at der kan være flere forskelle mellem siderne i fremtiden, kan det betyde, at på et eller andet tidspunkt bliver det mere økonomisk at skifte til separate sider (mens man stræber efter at minimere dobbeltarbejde mellem dem ved at udtrække fælles så meget som muligt). Så revurder situationen inden hver fremtidig ændring.

Dette ligner JSF. Hver gengivet = “…” betyder i det væsentlige, at du har en hvis i din kode, hvilket forårsager yderligere kompleksitet.

Jeg har gjort det samme, fordi “det er den samme side med nogle få forskelle her og der “og sagt meget enkelt, fungerer det ikke i det lange løb, fordi det ikke er” t den samme side, og du bliver nødt til at gøre flere og mere detaljerede tricks for at få det til at fungere korrekt, hvilket får det unødvendigt svært at vedligeholde.

Hvis du bruger JSF med faceletter i stedet for JSP (som du hvis du kunne) så kan du opbygge XML-fragmenter svarende til en blok på siden, som du derefter kan medtage hvor det er nødvendigt. Dette vil købe dig modularitet og stadig give dig mulighed for at genbruge indhold på tværs af sider.

Lyt til din kollega. Han har ret.

Kommentarer

• se min redigering
• @ 0101, formodede jeg netop dette. Gør det ikke ‘, det er vejen til galskab – sandsynligvis for dig – en og bestemt for fremtidige vedligeholdere.
• det virkelige problem er, at min måde er den bedste måde. hvis jeg gjorde 3 sider, end nogen kunne ændre bare en af siderne og ikke tænke på de andre. Jeg vil gerne have min version som fremtidig vedligeholder.
• Jeg tror, at min kode får den fremtidige vedligeholdelse til at tænke over andre sager. Hvis du var en ny programmør til projektet og i debugger fandt ud af, at du har brug for at ændre kode i baseFormBasic.xhtml, ville du også ændre den i baseFormAdv og baseFormSpec?
• @ 0101, hvorfor spørge hvad der er bedst, hvis du bare vil have din forudfattede mening bekræftet?

Er der en chance for at generere siden bruger kode? I dette tilfælde, hvad med noget som:

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

Og i sidegengivelseskoden

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

Eller i OOP-stil:

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

Kommentarer

• nej, der er ingen ændring . Jeg ville blive korsfæstet, hvis jeg gjorde det. plus det skaber nøjagtigt det samme problem. hvis == gengivet.
• Det er ikke det nøjagtige problem, da det ekstraherer sidelogikken. Gør kun en opgave i stedet for to.
• måske, men jeg føler, at det er det samme. min grund er, at visning af felter kun er en ting, der er anderledes, der er også forskellige placeringer og undertiden etiketter. plus det er webprogrammeringen, så jeg kan ‘ ikke gøre det sådan.

Essensen af dette spørgsmål synes at være: når du har tre meget ens websider med et par mindre forskelle, er det bedre at duplikere disse tre sider og ændre hver efter behov, eller opbygge logikken til en enkelt side for dynamisk at gengive siden i henhold til hvilken “mode “ses.

For ordens skyld er jeg en JSF-fyr, og jeg kan lide det, og jeg bruger betinget gengivelse.

Hvis du vælger at have tre sider, er der risiko for, at vedligeholdelse muligvis ikke anvender det korrekt på alle tre sider, når der sker ændringer.

Hvis du vælger at bruge betinget gengivelse, løser du problemet, men du har flyttet en forretningslogik ind på din side, som muligvis har brug for en overvejelse.

Jeg personligt ville ikke have noget problem med brugen af betinget gengivelse, men vil meget gerne se tilstandslogikken flyttet til en bagbønne, fx: i stedet for:

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

Jeg kan lide:

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

Hvor bønnen håndterer logik og returnerer sand eller falsk for at kontrollere gengivelsen af elementet.

Årsagen er, at den tilstand, der vises, muligvis behøver at kontrollere mere end bare denne ene side, skal muligvis fortsætte den ud over selv brugerens enkelt session, eller du skal muligvis ændre tilstande helt ned i vej.

Eller du kan acceptere, at begge tilgange har potentielle ulemper, og alle ulemper synes at være angående lindring af smerter langs vejen, og er enige om at bekymre dig om det yderligere, når en af disse “ned ad vejen” ting faktisk komme op, og tag derefter bedre beslutninger nu, hvor mere faktisk er kendt om, hvordan kravene kan ændre sig.