Generieke code of gemakkelijk te begrijpen code?

Je moet je sjablonen structureren met dezelfde regels als bij het programmeren. Dit betekent in wezen dat gemeenschappelijke ontwerpelementen in afzonderlijke bestanden worden geëxtraheerd om duplicatie te voorkomen en zo een meer herbruikbaar ontwerp te verkrijgen. Dat is regel # 1 ( DRY ) en de methode heet refactoring in programmeertermen.

De tweede regel is dat je moet streven naar eenvoud en duidelijkheid. Het moet gemakkelijk zijn om de lay-out te begrijpen en waar u heen moet wanneer u dingen moet veranderen.

Het tot op de letter volgen van de eerste regel leidt tot een zware ontbinding van je gui in heel veel kleine fragmenten die het moeilijk kunnen maken om te begrijpen hoe de lay-out is gemaakt. Je moet veel jagen om te ontdekken waar de dingen zijn. Dit is in strijd met de tweede regel, dus moet je een balans vinden tussen deze twee tegenpolen.

Maar de beste aanpak is om een oplossing te vinden die dit probleem volledig vermijdt. Ik denk dat je in dit geval een eenvoudigere benadering zou moeten overwegen . Ik neem aan dat dit HTML is en je noemt “eenvoudige en geavanceerde” staten in de GUI. Heeft u overwogen om altijd alle velden te genereren en vervolgens de GUI-logica in JavaScript af te handelen? Met andere woorden, schrijf client-side code die de relevante velden on-the-fly verbergt en toont, afhankelijk van in welke modus (toestand) het zich bevindt?

Dit heeft ook het voordeel dat je op verzoek van modus kunt wisselen zonder de server erbij te betrekken en dat je geen regels hoeft te compromitteren. Een ander groot voordeel is dat je de front-end-jongens voer deze veranderingen uit zonder de back-end programmeurs erbij te betrekken, die meestal niet zo enthousiast zijn over het aanpassen en polijsten van het ontwerp en de interactie.

Opmerkingen

• Ik ben het er niet mee eens dat JS eenvoudiger is, waarom? De meeste van mijn collegas weten ‘ niet dat JS en Java-webframeworks u steeds vaker toestaan om JS te negeren (Richfaces, GWT Bijna alle bedrijven geven niet om JS (ik denk dat mij één JS-vraag is gesteld in alle bedrijven waarin ik ooit heb geïnterviewd). Dus mijn collegas zouden die code niet aanraken en ze zouden hem gewoon herschrijven als ze dat wel hadden gedaan. om het te veranderen. Uw idee is goed, maar niet realistisch. plus waarom zou u een deel van uw logica in Java en een deel in JS bewaren? Ik denk dat dat de reden is waarom opgeslagen procedures ke hen).
• @ 0101 Ik heb ‘ niet gezegd dat JS eenvoudiger of moeilijker is dan wat dan ook. Het hangt af van uw vaardigheden. Met een bekwame html-coder zou dit geen probleem zijn. Ik zei dat door GUI-problemen uit te stellen naar de GUI-laag (waar deze thuishoort), je vaak een veel eenvoudigere oplossing krijgt. Dit komt omdat GUIs zeer dynamisch en interactief zijn, waarvoor taal zoals JS is gemaakt. Alleen omdat u denkt dat ” geen enkel bedrijf geeft om JS “, maakt ‘ niet mijn punt is niet zo geldig.
• Ik denk dat het zo is, de vraag is wat ik in mijn situatie moet doen en je antwoord is als ” gebruik opgeslagen procedures ” en dat is niet geldig aangezien niemand het gebruikt en het zou moeilijk te begrijpen zijn waarom ik ze zou hebben gebruikt. Ik ‘ m vroeg welke manier beter is voor de toekomst, aangezien ik ‘ niet 100% zeker weet dat mijn keuze de beste is (nu de de beste manier is om vervelende collegas te negeren).
• @ 0101: Werken met web en HTML impliceert min of meer JavaScript (en HTTP en CSS en afbeeldingen …), dus je kunt ‘ kan mij niet echt kwalijk nemen dat ik aannam dat JavaScript een optie was. Het ‘ is niet zoals ik ‘ m vraag om het in Swing te schrijven.
• ” Bijna alle bedrijven geven niets om JS ” – geloof je dat echt? Rijke interfaces op het web gaan al jaren in de richting van de klant. Ik heb het gevoel dat je hier de boot mist.

Zonder de code te zien, kan ik alleen speculeren, maar ik vermoed dat op dit moment je code “on the edge” is.

Voor 2 of 3 modi met een beperkt aantal veranderingen tussen die modi wat je hebt nu is waarschijnlijk OK. Als het echter ingewikkelder zou zijn, dan klinkt het alsof het moet worden geherstructureerd in afzonderlijke paginas.

Persoonlijk geef ik de voorkeur aan gemakkelijk te begrijpen code – het is veel beter te onderhouden, zowel voor andere ontwikkelaars als voor uzelf wanneer je moet het zes maanden later weer oppakken.

Het heeft echter geen zin om de code nu te herstructureren om een probleem op te lossen dat in de toekomst misschien niet bestaat . U zegt dat u niet weet hoeveel de vereisten zullen veranderen – en dat omvat geen verandering – dus het toepassen van YAGNI (You Ain “t Gonna Need It) doe nu niets.

Markeer de code als aandacht nodig hebben in de toekomst zodat je het niet vergeet, maar het nu niet verandert (en mogelijk breekt).

Reacties

• + 1 – Als je twijfelt, ga dan gemakkelijk te begrijpen. De zeur in je achterhoofd of je het generiek moet maken, is een natuurlijke manier om je te vertellen dat je het niet ‘ t. / li>

Ik heb ongeveer hetzelfde gedaan. Geloof me, na het implementeren van een paar verschillende gedragingen voor elke modus, wordt de “hoofdpagina” een puinhoop die bijna onmogelijk te lezen is. Je zou dan alleen een aantal regelstroomblokken zien (kort gevolgd door Matrix digitale regen). Ik merkte dat ik enkele blokken verwijderde om een duidelijk beeld te krijgen van wat er in een bepaalde modus zit.

Dus de “aparte paginas” is de juiste keuze. Maar als je dat doet, moet je ” vecht tegen “code duplicatie probleem. Dit is waar je collega het mis kan hebben door samenvoegingen voor te stellen. Helaas heb ik dat ook gedaan. In principe werkt het, maar het kost veel kostbare tijd en uiteindelijk, door een slechte samenvoeging, loopt de “gemeenschappelijke ruimte” van de paginas niet synchroon en wordt het samenvoegen een echte nachtmerrie. Je hebt dus gelijk als je bezwaar maakt tegen een samenvoeging als een redelijke oplossing.

Zoals je uit veel reacties kunt zien, is de juiste benadering om echt gewone delen naar externe entiteiten te extraheren (fragmenten van JSP-paginas, JSF-fragmenten, wat dan ook) en neem ze op in die paginas.

Reacties

• het echte probleem dat gemeenschappelijke code alleen de controles h: inputText + h: outputText voor enkel veld. Ik voel dat het niet de moeite waard is om ertegen te vechten. Bovendien kan deze pagina doodgaan omdat het niet echt functioneel is, vanwege de modi en het is zelfs verwarrend voor andere ontwikkelaars (vanuit het oogpunt van de gebruiker).
• Het probleem is dus echt wanneer de overgang moet worden uitgevoerd. U moet de splitsing na elke wijziging heroverwegen. Als de pagina rommelig begint te worden, moet je hem splitsen. Ik denk dat je collega zich ook meer op zijn gemak zal voelen als je zijn idee goed vindt, maar nog niet de moeite waard om te implementeren.

Duplicatie van code is praktisch nooit een goede zaak. Dat gezegd hebbende, een kleine hoeveelheid, niet veel meer dan twee keer gedupliceerd, is acceptabel in het echte leven – het is beter om pragmatisch dan religieus te zijn. In jouw geval klinkt het als een grotere hoeveelheid code en 3 plaatsen, dus het is iets boven mijn persoonlijke drempel. Dus neig ik naar de generieke versie.En in ieder geval, als het nu werkt, is het niet nodig om het alleen om theoretische redenen aan te raken.

OTOH als je zegt dat er in de toekomst meer verschillen tussen de paginas kunnen zijn, kan dit betekenen dat op een bepaald moment wordt het economischer om over te schakelen naar afzonderlijke paginas (terwijl wordt gestreefd naar het minimaliseren van duplicatie tussen de paginas door zoveel mogelijk overeenkomsten te extraheren). Dus evalueer de situatie opnieuw voor elke toekomstige wijziging.

Dit lijkt op JSF. Elke render = “…” betekent in wezen dat je een if in je code hebt, wat extra complexiteit veroorzaakt.

Ik “heb hetzelfde gedaan omdat” het dezelfde pagina is met een paar verschillen hier en daar “en heel eenvoudig gezegd, het werkt op de lange termijn niet omdat het niet” t dezelfde pagina en je zult steeds meer ingewikkelde trucs moeten doen om het correct te laten werken, waardoor het onnodig moeilijk te onderhouden is.

Als je JSF met faceletten gebruikt in plaats van JSP (wat je zou als je zou kunnen), dan kun je XML-fragmenten bouwen die overeenkomen met een blok van de pagina, die je vervolgens kunt toevoegen waar nodig. Hierdoor krijg je modulariteit en kun je toch inhoud op verschillende paginas hergebruiken.

Luister naar je collega. Hij heeft gelijk.

Reacties

• zie mijn bewerking
• @ 0101, vermoedde ik precies dit. Don ‘ doe het niet, het is de weg naar waanzin – hoogstwaarschijnlijk voor jou – een zeker voor toekomstige beheerders.
• het echte probleem is dat mijn manier de beste manier is. als ik 3 paginas heb gemaakt, kan iemand slechts één van de paginas veranderen en niet aan de andere denken. Ik zou graag mijn versie willen hebben als toekomstige onderhouder.
• Ik denk dat mijn code de toekomstige onderhoudsmedewerker aan andere zaken doet denken. Als je een nieuwe programmeur van het project was en in debugger ontdekte dat je code in baseFormBasic.xhtml moest veranderen, zou je dat dan ook veranderen in baseFormAdv en baseFormSpec?
• @ 0101, waarom zou je je afvragen wat het beste is, als je gewoon je vooropgezette mening wilt laten bevestigen?

Is er een kans om de pagina te genereren code gebruiken? In dit geval, wat dacht je van zoiets als:

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

En in de paginaweergavecode

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

Of in OOP-stijl:

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

Reacties

• nee, er is geen verandering . Ik zou gekruisigd worden als ik het deed. plus het schept precies hetzelfde probleem. if == weergegeven.
• Het is niet het exacte probleem aangezien het de paginalogica extraheert. Slechts één taak uitvoeren in plaats van twee.
• misschien, maar ik denk dat het hetzelfde is. mijn reden is dat het tonen van velden slechts één ding is dat anders is, er is ook een andere plaatsing en soms labels. plus het is de webprogrammering, dus ik kan ‘ het niet zo doen.

modale code kan alleen maar erger worden . Classificeer en beslis een keer aan het begin, en vertak om implementaties zonder modi op te schonen.

Reacties

• isn ‘ t code duplicatie ergste? alle code moet altijd met elkaar worden gesynchroniseerd (als u simple verandert, vergeet dan niet om advance te wijzigen en wat als u het vergeet?)
• isoleer de gemeenschappelijke code in subroutines, functies, helper / basisklassen, et al ; in OOP is modale code een indicatie van ontbrekende klassen …

De essentie van deze vraag lijkt te zijn: als u drie zeer vergelijkbare webpaginas heeft met een paar kleine verschillen, is het dan beter om die drie paginas te dupliceren en ze naar behoefte aan te passen, of de logica in een enkele pagina in te bouwen om de pagina dynamisch weer te geven volgens welke modus “wordt bekeken.

Voor de goede orde, ik ben een JSF-man en ik vind het leuk, en ik maak gebruik van voorwaardelijke weergave.

Als u ervoor kiest om drie paginas te hebben, bestaat het risico dat als er wijzigingen plaatsvinden, de beheerder dat niet correct toepast op alle drie de paginas.

Als u ervoor kiest om voorwaardelijke weergave te gebruiken, lost u dat probleem op, maar heeft u wat bedrijfslogica naar uw pagina verplaatst, wat wellicht wat aandacht vereist.

Persoonlijk zou ik geen probleem hebben met het gebruik van voorwaardelijke weergave, maar zou graag zien dat de moduslogica wordt verplaatst naar een ondersteunende bean, bijvoorbeeld: in plaats van:

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

Ik hou van:

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

Waar de bean de logic en retourneert true of false om de weergave van het element te regelen.

De reden hiervoor is dat de modus die wordt bekeken, mogelijk meer moet besturen dan alleen deze ene pagina, het misschien zelfs na de enkele sessie van de gebruiker moet behouden, of het kan zijn dat u de modi helemaal naar beneden moet wijzigen. weg.

Of u kunt accepteren dat beide benaderingen potentiële nadelen hebben, en alle nadelen lijken te zijn in het verlichten van pijn op de weg, en u gaat ermee akkoord dat u zich er verder zorgen over maakt wanneer een van die “verderop” -dingen naar boven komen, en dan betere beslissingen nemen nu er eigenlijk meer bekend is over hoe de vereisten kunnen veranderen.