Codice generico o codice di facile comprensione?

Dovresti strutturare i tuoi modelli usando le stesse regole della programmazione. Ciò significa essenzialmente estrarre elementi di progettazione comuni in file separati per evitare duplicazioni e quindi ottenere un design più riutilizzabile. Questa è la regola n. 1 ( DRY ) e il metodo si chiama refactoring in termini di programmazione.

La seconda regola è che dovresti sforzarti di semplicità e chiarezza. Dovrebbe essere facile capire il layout e dove andare quando devi cambiare le cose.

Seguire la prima regola alla lettera porta a una pesante scomposizione della tua interfaccia grafica in moltissimi piccoli snippet che possono rendere difficile capire come viene creato il layout. Devi cacciare molto per scoprire dove sono le cose. Ciò viola la seconda regola, quindi devi trovare un equilibrio tra questi due opposti.

Ma lapproccio migliore è trovare una soluzione che eviti completamente questo problema. Penso che, in questo caso, dovresti considerare un approccio più semplice del tutto . Presumo che questo sia HTML e tu menzioni stati “semplici e avanzati” nella GUI. Hai considerato di generare sempre tutti i campi e quindi gestire la logica della GUI in JavaScript? In altre parole, scrivere codice lato client che nasconda e mostri al volo i campi rilevanti a seconda della modalità (stato) in cui si trova?

Questo ha anche il vantaggio di poter cambiare modalità su richiesta senza coinvolgere il server e non devi compromettere nessuna delle regole. Unaltra cosa grandiosa è che puoi lasciare che i ragazzi del front-end fare queste modifiche senza dover coinvolgere i programmatori di back-end che di solito non sono particolarmente entusiasti di perdere tempo a modificare e perfezionare il design e linterazione.

Commenti

• Non sono daccordo sul fatto che JS sia più semplice, perché? la maggior parte dei miei colleghi non ‘ non conosce JS e i framework web Java sempre più consentono di ignorare JS (Richfaces, GWT ). Quasi tutte le aziende non si preoccupano di JS (penso che mi sia stata posta una domanda JS in tutte le aziende in cui ho intervistato). Quindi i miei colleghi non toccherebbero quel codice e lo riscriverebbero semplicemente se lo avessero per cambiarlo. La tua idea è buona, ma non è realistica. inoltre perché mantenere parte della logica in java e parte in JS? Penso che questo sia il motivo per cui le stored procedure erano morte (e ho fatto li ke li).
• @ 0101 Non ‘ ho detto che JS è più semplice o più difficile di qualsiasi altra cosa. Dipende dalle tue capacità. Con un programmatore HTML competente, questo non sarebbe un problema. Ho detto che rimandando i problemi della GUI al livello della GUI (a cui appartiene), spesso si finisce con una soluzione molto più semplice. Questo perché le GUI sono altamente dinamiche e interattive, per cui è fatto il linguaggio come JS. Solo perché pensi che ” nessuna azienda si interessi di JS “, ‘ non fa il mio punto di vista è meno valido.
• Penso che sia così, la domanda è cosa fare nella mia situazione e la tua risposta è come ” usa stored procedure ” e questo non è valido poiché nessuno lo sta usando e sarebbe difficile capire perché li avrei usati. ‘ sto chiedendo quale sia la strada migliore per il futuro poiché ‘ non sono sicuro al 100% che la mia scelta sia la migliore (ora il il modo migliore è ignorare il fastidioso collega).
• @ 0101: Lavorare con web e HTML più o meno implica JavaScript (e HTTP, CSS e immagini …), quindi puoi ‘ Non mi biasimo davvero per aver supposto che JavaScript fosse unopzione. ‘ non è come se ‘ ti chiedessi di scriverlo in Swing.
• ” Quasi tutte le aziende non si preoccupano di JS ” – lo credi seriamente? Ricche interfacce sul Web si stanno muovendo in una direzione lato client ormai da molti anni. Sento che ti manca la barca su questo.

Senza vedere il codice, posso solo speculare, ma immagino che al momento il tuo codice sia “al limite”.

Per 2 o 3 modalità con un numero limitato di modifiche tra quelle modalità ciò che hai ora probabilmente va bene. Tuttavia, se dovesse essere più complicato, allora sembrerebbe che dovrebbe essere riformattato in pagine separate.

Personalmente preferisco un codice facile da capire – è molto più gestibile, sia per gli altri sviluppatori che per te stesso quando devi riprenderlo dopo 6 mesi.

Tuttavia, non ha senso refactoring del codice ora per risolvere un problema che potrebbe non esistere in futuro . Dici che non sai quanto cambieranno i requisiti – e questo non include alcun cambiamento – quindi applicando YAGNI (You Ain “t Gonna Need It) non fare nulla ora.

Contrassegna il codice come richiede attenzione in futuro in modo da non dimenticarlo, ma non cambiarlo (e potenzialmente romperlo) ora.

Commenti

• + 1 – In caso di dubbio vai con facilità di comprensione. Il fastidio in fondo alla tua mente sul fatto che dovresti renderlo generico è il modo naturale per dirti che non dovresti ‘ t.

Ho fatto più o meno la stessa cosa. Credetemi, dopo aver implementato pochi comportamenti diversi per ciascuna modalità, la “pagina principale” diventa un pasticcio quasi impossibile da leggere. Vedresti quindi solo una serie di blocchi di flusso di controllo (seguiti a breve da Matrix digital rain). Mi sono ritrovato a rimuovere alcuni blocchi solo per avere una visione chiara di cosa cè allinterno di una certa modalità.

Quindi le “pagine separate” sono la strada da percorrere. Tuttavia, quando lo fai, devi ” combatti il “problema della duplicazione del codice. È qui che il tuo collega potrebbe sbagliarsi suggerendo unioni. Purtroppo lho fatto anche io”. Fondamentalmente funziona, ma consuma molto tempo prezioso e alla fine a causa di una scarsa fusione “area comune” delle pagine non è sincronizzata e lunione diventa un vero incubo. Quindi hai ragione nellobiezione di ununione come soluzione ragionevole.

Come puoi vedere da molte risposte, lapproccio corretto è estrarre parti veramente “comuni” a entità esterne (frammenti di pagina JSP, snippet JSF, qualunque cosa) e includerli in quelle pagine.

Commenti

• il vero problema che il codice comune è solo i controlli h: inputText + h: outputText per singolo campo. Sento che non vale la pena combatterlo. in più questa pagina potrebbe morire poiché non è realmente funzionale, a causa delle modalità e la sua confusione anche per gli altri sviluppatori (dal punto di vista dellutente).
• Quindi il problema è davvero quando fare la transizione. Devi riconsiderare la divisione dopo ogni modifica. Quando la pagina inizia a essere disordinata, dividila. Penso che anche il tuo collega si sentirà più a suo agio se consideri buona la sua idea, ma non vale ancora la pena implementarla.

La duplicazione del codice non è praticamente mai una buona cosa. Detto questo, una piccola quantità duplicata non molte più del doppio è accettabile nella vita reale – è meglio essere pragmatici che religiosi al riguardo. Nel tuo caso, suona come una quantità maggiore di codice e 3 posizioni, quindi è leggermente al di sopra della mia soglia personale, quindi mi avvicino alla versione generica.E in ogni caso, se funziona ora, non è necessario toccarlo solo per motivi teorici.

OTOH quando dici che ci possono essere più differenze tra le pagine in futuro, questo potrebbe significare che a un certo punto nel tempo diventa più economico passare a pagine separate (cercando di ridurre al minimo la duplicazione tra di loro estraendo il più possibile le parti comuni). Quindi rivaluta la situazione prima di ogni cambiamento futuro.

Questo sembra JSF. Ogni render = “…” essenzialmente significa che hai un if nel tuo codice, che causa ulteriore complessità.

Ho “fatto la stessa cosa perché” è la stessa pagina solo con alcune differenze qui e lì “e in parole povere, non” funziona a lungo termine perché non è “t la stessa pagina e dovrai eseguire trucchi sempre più elaborati per farlo funzionare correttamente, rendendolo inutilmente difficile da mantenere.

Se usi JSF con facelets invece di JSP (che tu se potessi), puoi creare frammenti XML corrispondenti a un blocco della pagina, che puoi quindi includere dove necessario. Questo ti acquisterà modularità e ti consentirà comunque di riutilizzare il contenuto tra le pagine.

Ascolta il tuo collega. Ha ragione.

Commenti

• vedi la mia modifica
• @ 0101, sospettavo esattamente questo. Non ‘ farlo, è la strada verso la follia, molto probabilmente per te, un e sicuramente per i futuri manutentori.
• il vero problema è che il mio modo è il migliore. se facessi 3 pagine, qualcuno potrebbe cambiare solo una delle pagine e non pensare alle altre. Vorrei la mia versione come futuro manutentore.
• Penso che il mio codice stia facendo riflettere il futuro maintaine su altri casi. Se fossi un nuovo programmatore del progetto e nel debugger scoprissi che devi modificare il codice in baseFormBasic.xhtml, lo cambieresti anche in baseFormAdv e baseFormSpec?
• @ 0101, perché chiedere cosa è meglio, se vuoi solo che la tua opinione preconcetta venga confermata?

Cè la possibilità di generare la pagina usando il codice? In questo caso, che ne dici di qualcosa del tipo:

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

E nel codice di rendering della pagina

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

O in stile OOP:

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

Commenti

• no, non ci sono modifiche . Sarei crocifisso se lo facessi. in più crea esattamente lo stesso problema. if == rendering.
• Non è il problema esatto poiché estrae la logica della pagina. Sto facendo un solo compito, invece di due.
• forse, ma credo sia lo stesso. la mia ragione è che mostrare i campi è solo una cosa che è diversa, cè anche un posizionamento diverso e talvolta etichette. inoltre è la programmazione web, quindi posso ‘ non farlo in questo modo.

codice modale può solo peggiorare . Classifica e decidi una volta allinizio e ramifica per pulire le implementazioni senza modalità.

Commenti

• isn ‘ t la duplicazione del codice peggiore? tutto il codice dovrebbe essere sempre sincronizzato tra loro (se si cambia semplice, ricordarsi di cambiare in anticipo e cosa succede se lo si dimentica?)
• isolare il codice comune in subroutine, funzioni, classi di supporto / base, ecc. ; in OOP, il codice modale è unindicazione delle classi mancanti …

Lessenza di questa domanda sembra essere: quando hai tre pagine web molto simili con alcune piccole differenze, è meglio duplicare quelle tre pagine e modificarle ognuna secondo necessità, o costruire in una singola pagina la logica per rendere dinamicamente la pagina in base a quale modalità ” “è visualizzato.

Per la cronaca, sono un tipo JSF e mi piace, e utilizzo il rendering condizionale.

Se scegli di avere tre pagine, cè il rischio che quando avvengono i cambiamenti il manutentore potrebbe non applicarli correttamente a tutte e tre le pagine.

Se scegli di utilizzare il rendering condizionale, risolvi il problema ma hai spostato alcune logiche di business nella tua pagina che potrebbero richiedere qualche riflessione.

Personalmente non avrei alcun problema con luso del rendering condizionale, ma mi piacerebbe davvero vedere la logica della modalità spostata su un backing bean, ad esempio: invece di:

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

Mi piace:

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

Dove il bean gestisce il logica e restituisce true o false per controllare il rendering dellelemento.

Il motivo è che la modalità visualizzata potrebbe dover controllare più di una sola pagina, potrebbe essere necessario mantenerla anche oltre la singola sessione dellutente, oppure potrebbe essere necessario modificare completamente le modalità strada.

In alternativa, puoi accettare che entrambi gli approcci hanno potenziali svantaggi e tutti gli svantaggi sembrano riguardare lalleviamento dei dolori lungo la strada e accettare di preoccuparti ulteriormente quando una di quelle cose “lungo la strada” emergono effettivamente e poi prendono decisioni migliori ora che si sa di più su come potrebbero cambiare i requisiti.