Generisk kod eller kod lätt att förstå?

Du bör strukturera dina mallar med samma regler som vid programmering. Detta innebär i huvudsak att extrahera vanliga designelement i separata filer för att undvika dubbelarbete och därmed uppnå mer återanvändbar design. Det är regel nr 1 ( TORR ) och metoden kallas refactoring i programmeringstermer.

Den andra regeln är att du ska sträva efter enkelhet och tydlighet. Det ska vara lätt att förstå layouten och vart du ska gå när du behöver ändra saker.

Att följa den första regeln till punkt och pricka leder till kraftig sönderdelning av din gui i massor av små utdrag som kan göra det svårt att förstå hur layouten skapas. Du måste jaga mycket för att hitta var saker är. Detta bryter mot den andra regeln, så du måste hitta en balans mellan dessa två motsatser.

Men det bästa sättet är att hitta en lösning som helt undviker denna fråga. Jag tror att i detta fall bör du överväga ett enklare tillvägagångssätt helt och hållet . Jag antar att detta är HTML och du nämner ”enkla och avancerade” tillstånd i GUI. Har du funderat på att alltid skapa alla fält och sedan hantera GUI-logiken i JavaScript? Med andra ord, skriv klientkod som döljer och visar relevanta fält i farten beroende på vilket läge (tillstånd) det är i?

Detta har också fördelen att kunna byta läge på begäran utan att involvera servern och du behöver inte kompromissa med någon av reglerna. En annan bra sak är att du kan låta front-end-killarna gör dessa förändringar utan att behöva involvera backend-programmerare som vanligtvis inte är så alltför angelägna om att spendera tid på att finjustera och polera designen och interaktionen.

Kommentarer

• Jag håller inte med att JS är enklare, varför? De flesta av mina medarbetare vet inte ’ för att JS- och Java-webbramar mer och mer tillåter dig att ignorera JS (Richfaces, GWT Nästan alla företag bryr sig inte om JS (jag tror att jag fick en JS-fråga i alla företag som jag någonsin har intervjuat i.) Så mina medarbetare skulle inte röra den koden och de skulle bara skriva om den hade att ändra den. Din idé är bra, men den är inte realistisk. plus varför behålla en del av din logik i java och en del i JS? Jag tror det är anledningen till att lagrade procedurer hade dött (och jag gjorde ke dem).
• @ 0101 Jag sa inte ’ Jag sa att JS är enklare eller svårare än någonting. Det beror på dina färdigheter. Med en kompetent html-kodare skulle det inte vara något problem. Jag sa att genom att skjuta upp GUI-problem till GUI-lagret (där det hör hemma), slutar du ofta med en mycket enklare lösning. Detta beror på att GUI är mycket dynamiska och interaktiva vilket språk som JS är skapat för. Bara för att du tror att ” inga företag bryr sig om JS ”, gör inte ’ t min poäng något mindre giltig.
• Jag tror att det gör det, frågan är vad jag ska göra i min situation och ditt svar är som ” använder lagrade procedurer ” och det är inte giltigt eftersom ingen använder det och det skulle vara svårt att förstå varför jag skulle ha använt dem. Jag ’ jag frågar vilken väg som är bättre för framtiden eftersom jag ’ är inte 100% säker på att mitt val är det bästa (nu bästa sättet är att ignorera irriterande medarbetare).
• @ 0101: Att arbeta med webb och HTML innebär mer eller mindre JavaScript (och HTTP och CSS och bilder …), så du kan ’ klandrar mig inte för att jag antar att JavaScript var ett alternativ. Det ’ är inte som jag ’ jag ber dig skriva det i gunga.
• ” Nästan alla företag bryr sig inte om JS ” – tror du det på allvar? Rika gränssnitt på webben har gått i en klientsida i många år nu. Jag känner att du saknar båten på den här.

Utan att se koden kan jag bara spekulera, men jag skulle gissa att just nu din kod är ”på kanten”.

För 2 eller 3 lägen med ett begränsat antal ändringar mellan dessa lägen vad du har nu är förmodligen OK. Men om det skulle bli mer komplicerat låter det som om det borde omformas till separata sidor.

Personligen föredrar jag lätt att förstå koden – den är mycket mer underhållbar, både för andra utvecklare och för dig själv när du måste plocka upp det igen sex månader längre fram.

Det är dock ingen mening att refaktorisera koden nu för att lösa ett problem som kanske inte finns i framtiden . Du säger att du inte vet hur mycket kraven kommer att förändras – och det inkluderar ingen förändring – så att tillämpa YAGNI (du kommer inte behöva det) gör inte någonting nu.

Markera koden som kräver uppmärksamhet i framtiden så att du inte glömmer det, men ändrar inte (och eventuellt bryter) det nu.

Kommentarer

• + 1 – Om du är i tvivel, är det lätt att förstå. Vaggen bakom dig om huruvida du ska göra det generiskt är naturens sätt att säga att du inte ’ t.

Jag har gjort ungefär samma sak. Tro mig, efter att ha genomfört några olika beteenden för varje läge blir ”huvudsidan” en röra nästan omöjlig att läsa. Du skulle då bara se ett gäng kontrollflödesblock (kort följt av Matrix digitala regn). Jag befann mig att ta bort några block bara för att få en tydlig bild av vad som finns i ett visst läge.

Så de ”separata sidorna” är vägen att gå. Men när du gör det måste du ” bekämpa ”kodkopieringsproblem. Det är här din kollega kan ha fel genom att föreslå sammanslagningar. Tyvärr så har jag gjort det också. I grund och botten fungerar det, men det tar mycket dyrbar tid och så småningom av dålig sammanslagning är ”gemensamt område” på sidorna inte synkroniserade och sammanslagning blir en riktig mardröm. Så du har rätt i att invända en sammanslagning som en rimlig lösning.

Som du kan se från många svar är det korrekta tillvägagångssättet att extrahera riktigt ”vanliga” delar till externa enheter (JSP-sidfragment, JSF-utdrag, vad som helst) och inkludera dem på dessa sidor.

Kommentarer

• det verkliga problemet att vanlig kod bara är kontrollerna h: inputText + h: outputText for enda fält. Jag känner att det inte är värt att bekämpa det. plus den här sidan kan dö eftersom den inte är riktigt funktionell på grund av lägena och förvirrande även för andra utvecklare (ur användarsynpunkt).
• Så problemet är egentligen när man ska göra övergången. Du måste ompröva splittring efter varje modifiering. När sidan börjar bli rörig – dela den. Jag tror att din kollega också kommer att vara bekvämare om du anser att hans idé är bra, men ännu inte värt att genomföra.

Kopiering av kod är praktiskt taget aldrig bra. Med det sagt är en liten mängd duplicerad inte mycket mer än två gånger acceptabel i verkliga livet – det är bättre att vara pragmatisk än religiös om det. I ditt fall låter det som en större mängd kod och tre platser, så det är lite över min personliga tröskel. Således lutar jag mig mot den generiska versionen.Och i alla fall, om det fungerar nu, finns det inget behov av att röra det bara av teoretiska skäl.

OTOH när du säger att det kan finnas fler skillnader mellan sidorna i framtiden, kan det betyda att vid någon tidpunkt blir det mer ekonomiskt att byta till separata sidor (samtidigt som man strävar efter att minimera dubbelarbete mellan dem genom att extrahera gemensamma drag så mycket som möjligt). Så omvärdera situationen före varje framtida förändring.

Detta ser ut som JSF. Varje renderad = ”…” betyder i huvudsak att du har en if i din kod, vilket orsakar ytterligare komplexitet.

Jag har gjort samma sak eftersom ”det är samma sida bara med några skillnader här och där ”och uttryckt mycket enkelt fungerar inte på lång sikt eftersom det inte är” t samma sida och du kommer att behöva göra mer och mer detaljerade knep för att få det att fungera ordentligt vilket gör att det blir onödigt svårt att underhålla.

Om du använder JSF med facelets istället för JSP (som du om du kunde) kan du bygga XML-fragment som motsvarar ett block på sidan, som du sedan kan inkludera där det behövs. Detta kommer att ge dig modularitet och ändå låta dig återanvända innehåll över sidor.

Lyssna på din kollega. Han har rätt.

Kommentarer

• se min redigering
• @ 0101, misstänkte jag exakt detta. Gör det inte ’, det är vägen till galenskap – troligen för dig – en och säkert för framtida underhållare.
• det verkliga problemet är att mitt sätt är det bästa sättet. om jag gjorde 3 sidor än skulle någon bara kunna ändra en av sidorna och inte tänka på de andra. Jag skulle vilja ha min version som en framtida underhållare.
• Jag tror att min kod gör att framtida underhållare tänker på andra fall. Om du var en ny programmerare för projektet och i felsökaren fann att du måste ändra kod i baseFormBasic.xhtml, skulle du också ändra den i baseFormAdv och baseFormSpec?
• @ 0101, varför fråga vad som är bäst, om du bara vill få din förutfattade åsikt bekräftad?

Finns det en chans att skapa sidan använder du kod? I det här fallet, vad sägs om något liknande:

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

Och i sidrenderingskoden

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

Eller i OOP-stil:

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

Kommentarer

• nej, det finns ingen förändring . Jag skulle korsfästas om jag gjorde det. plus det skapar exakt samma problem. om == återges.
• Det är inte det exakta problemet eftersom det extraherar sidlogiken. Gör bara en uppgift istället för två.
• kanske, men jag känner att det är detsamma. min anledning är att visa fält bara är en sak som är annorlunda, det finns också olika placeringar och ibland etiketter. plus dess webbprogrammering, så jag kan ’ t göra det så här.

Kärnan i denna fråga verkar vara: när du har tre mycket likartade webbsidor med några mindre skillnader, är det bättre att duplicera de tre sidorna och ändra var och en efter behov, eller bygga in i en enda sida logiken för att dynamiskt återge sidan enligt vilket ”läge ”ses.

För ordens skull är jag en JSF-kille och jag gillar det, och jag använder villkorlig återgivning.

Om du väljer att ha tre sidor, finns det en risk att underhållet kanske inte tillämpar det korrekt på alla tre sidorna.

Om du väljer att använda villkorlig återgivning löser du problemet men du har flyttat en del affärslogik till din sida som kan behöva tänka på.

Jag personligen skulle inte ha några problem med användningen av villkorlig återgivning, men skulle verkligen vilja se lägeslogiken flyttas till en stödböna, t.ex.: istället för:

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

Jag gillar:

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

Där bönan hanterar logik och returnerar true eller false för att styra återgivningen av elementet.

Anledningen är att det visade läget kan behöva styra mer än bara den här sidan, kan behöva bestå det utöver ens användarens enda session, eller så kan du behöva ändra lägena helt nedåt väg.

Eller så kan du acceptera att båda metoderna har potentiella nackdelar, och alla nackdelar verkar handla om att lindra smärtor på vägen, och går med på att oroa dig för det ytterligare när en av dessa ”vägar” saker faktiskt komma upp och sedan fatta bättre beslut nu när mer faktiskt är känt om hur kraven kan förändras.