Generischer Code oder leicht verständlicher Code?

Sie sollten Ihre Vorlagen nach denselben Regeln wie beim Programmieren strukturieren. Dies bedeutet im Wesentlichen, dass gemeinsame Designelemente in separate Dateien extrahiert werden, um Doppelarbeit zu vermeiden und somit ein wiederverwendbareres Design zu erzielen. Das ist Regel Nr. 1 ( DRY ) und die Methode wird programmtechnisch als Refactoring bezeichnet.

Die zweite Regel ist, dass Sie danach streben sollten Einfachheit und Klarheit. Es sollte leicht zu verstehen sein, wie das Layout ist und wohin Sie gehen müssen, wenn Sie Änderungen vornehmen müssen.

Das Befolgen der ersten Regel des Buchstabens führt zu einer starken Zerlegung Ihrer GUI in viele, viele kleine Schnipsel, die es schwierig machen können, zu verstehen, wie das Layout erstellt wird. Man muss viel herumjagen, um herauszufinden, wo sich die Dinge befinden. Dies verstößt gegen die zweite Regel. Sie müssen ein Gleichgewicht zwischen diesen beiden Gegensätzen finden.

Der beste Ansatz ist jedoch, eine Lösung zu finden, die dieses Problem vollständig vermeidet. Ich denke, in diesem Fall sollten Sie einen einfacheren Ansatz in Betracht ziehen . Ich gehe davon aus, dass dies HTML ist und Sie „einfache und fortgeschrittene“ Zustände in der GUI erwähnen. Haben Sie darüber nachgedacht, immer alle Felder zu generieren und dann die GUI-Logik in JavaScript zu verarbeiten? Mit anderen Worten, schreiben Sie clientseitigen Code, der die relevanten Felder im laufenden Betrieb verbirgt und anzeigt, je nachdem, in welchem Modus (Status) er sich befindet.

Dies hat auch den Vorteil, dass Sie den Modus bei Bedarf wechseln können, ohne den Server einzubeziehen, und Sie müssen keine der Regeln kompromittieren. Eine weitere großartige Sache ist, dass Sie die Front-End-Leute lassen können Nehmen Sie diese Änderungen vor, ohne die Back-End-Programmierer einbeziehen zu müssen, die normalerweise nicht so sehr daran interessiert sind, das Design und die Interaktion zu optimieren und zu verbessern.

Kommentare

• Ich bin nicht der Meinung, dass JS einfacher ist. Warum? Die meisten meiner Kollegen kennen ‚ nicht. JS- und Java-Webframeworks ermöglichen es Ihnen immer mehr, JS zu ignorieren (Richfaces, GWT) ) Fast alle Unternehmen interessieren sich nicht für JS (ich glaube, mir wurde in allen Unternehmen, in denen ich jemals ein Interview geführt habe, eine JS-Frage gestellt). Meine Mitarbeiter würden diesen Code also nicht berühren und ihn einfach neu schreiben, wenn sie dies getan hätten Ihre Idee ist gut, aber nicht realistisch. Und warum sollten Sie einen Teil Ihrer Logik in Java und einen Teil in JS behalten? Ich denke, das ist der Grund, warum gespeicherte Prozeduren gestorben sind (und ich habe es getan) ke sie).
• @ 0101 Ich habe nicht ‚ gesagt, dass JS einfacher oder schwieriger ist als alles andere. Es hängt von Ihren Fähigkeiten ab. Mit einem kompetenten HTML-Codierer wäre dies kein Problem. Ich sagte, wenn Sie GUI-Probleme auf die GUI-Ebene (wo sie hingehört) verschieben, erhalten Sie häufig eine viel einfachere Lösung. Dies liegt daran, dass GUIs hoch dynamisch und interaktiv sind, für welche Sprache wie JS gemacht ist. Nur weil Sie denken, dass “ kein Unternehmen sich für JS “ interessiert, macht ‚ nichts Mein Punkt ist weniger gültig.
• Ich denke, seine Art tut es, die Frage ist, was in meiner Situation zu tun ist, und Ihre Antwort lautet wie folgt: “ gespeicherte Prozeduren verwenden “ und das ist nicht gültig, da niemand es benutzt und es schwer zu verstehen ist, warum ich sie benutzt hätte. Ich ‚ frage, welcher Weg für die Zukunft besser ist, da ich ‚ nicht 100% sicher bin, dass meine Wahl die beste ist (jetzt die Der beste Weg ist, nervige Mitarbeiter zu ignorieren.
• @ 0101: Die Arbeit mit Web und HTML impliziert mehr oder weniger JavaScript (und HTTP und CSS und Bilder …), sodass Sie ‚ macht mich nicht wirklich dafür verantwortlich, dass JavaScript eine Option war. ‚ ist nicht so, als würde ich ‚ Sie bitten, es in Swing zu schreiben.
• “ Fast alle Unternehmen interessieren sich nicht für JS “ – glauben Sie das ernsthaft? Umfangreiche Schnittstellen im Web bewegen sich seit vielen Jahren in eine clientseitige Richtung. Ich habe das Gefühl, Sie vermissen das Boot in diesem Fall.

Ohne den Code zu sehen, kann ich nur Spekulieren Sie, aber ich würde vermuten, dass im Moment Ihr Code „am Rande“ ist.

Für 2 oder 3 Modi mit einer begrenzten Anzahl von Änderungen zwischen diesen Modi, was Sie haben Jetzt ist wahrscheinlich OK. Sollte es jedoch komplizierter sein, klingt es so, als ob es in separate Seiten umgestaltet werden sollte.

Ich persönlich bevorzuge leicht verständlichen Code – er ist viel wartbarer, sowohl für andere Entwickler als auch für Sie selbst, wenn Sie müssen es 6 Monate später wieder aufnehmen.

Es macht jedoch keinen Sinn, den Code jetzt umzugestalten, um ein Problem zu lösen, das in Zukunft möglicherweise nicht mehr besteht . Sie sagen, Sie wissen nicht, wie stark sich die Anforderungen ändern werden – und dazu gehört auch keine Änderung -. Wenn Sie also YAGNI anwenden (Sie werden es nicht brauchen), tun Sie jetzt nichts.

Markieren Sie den Code als Sie müssen in Zukunft darauf geachtet werden, damit Sie sie nicht vergessen, aber jetzt nicht ändern (und möglicherweise brechen).

Kommentare

• + 1 – Wenn Sie Zweifel haben, gehen Sie mit leicht zu verstehen. Der Nörgler im Hinterkopf darüber, ob Sie es generisch machen sollten, ist eine natürliche Art, Ihnen zu sagen, dass Sie ‚ t.

Ich habe so ziemlich das Gleiche getan. Glauben Sie mir, nachdem Sie für jeden Modus einige unterschiedliche Verhaltensweisen implementiert haben, wird die „Hauptseite“ zu einem Chaos, das kaum mehr zu lesen ist. Sie würden dann nur eine Reihe von Kontrollflussblöcken sehen (kurz gefolgt von Matrix Digital Rain). Ich habe einige Blöcke entfernt, um einen klaren Überblick darüber zu erhalten, was sich in einem bestimmten Modus befindet.

Die „separaten Seiten“ sind also der richtige Weg. Wenn Sie dies jedoch tun, müssen Sie “ Problem der Code-Duplizierung bekämpfen. Hier könnte Ihr Kollege falsch liegen, wenn er Zusammenführungen vorschlägt. Leider habe ich das auch getan. Grundsätzlich funktioniert es, aber es verbraucht viel wertvolle Zeit und schließlich ist durch schlechte Zusammenführung der „gemeinsame Bereich“ der Seiten nicht synchron und das Zusammenführen wird zu einem echten Albtraum. Sie haben also Recht, wenn Sie eine Zusammenführung als vernünftige Lösung ablehnen.

Wie Sie aus vielen Antworten ersehen können, besteht der richtige Ansatz darin, wirklich „gemeinsame“ Teile an externe Entitäten zu extrahieren (JSP-Seitenfragmente, JSF-Snippets, was auch immer) und fügen Sie sie in diese Seiten ein.

Kommentare

• das eigentliche Problem, dass allgemeiner Code nur die Steuerelemente h: inputText + h: outputText für ist einzelnes Feld. Ich denke, es lohnt sich nicht, dagegen anzukämpfen. Außerdem könnte diese Seite sterben, da sie aufgrund der Modi nicht wirklich funktioniert und selbst für andere Entwickler (aus Anwendersicht) verwirrend ist.
• Das Problem ist also wirklich, wann der Übergang durchgeführt werden muss. Sie müssen die Aufteilung nach jeder Änderung überdenken. Wenn die Seite unordentlich wird, teilen Sie sie auf. Ich denke, Ihr Mitarbeiter wird sich auch wohler fühlen, wenn Sie seine Idee für gut halten, aber noch nicht umsetzenswert.

Dies sieht aus wie JSF. Jedes gerenderte = „…“ bedeutet im Wesentlichen, dass Sie ein Wenn in Ihrem Code haben, was zusätzliche Komplexität verursacht.

Ich habe dasselbe getan, weil „es dieselbe Seite ist, nur mit ein paar Unterschieden hier und dort „und ganz einfach ausgedrückt, funktioniert auf lange Sicht nicht, weil es nicht“ t dieselbe Seite, und Sie müssen immer ausgefeiltere Tricks ausführen, damit sie ordnungsgemäß funktioniert, was die Wartung unnötig erschwert.

Wenn Sie JSF mit Facelets anstelle von JSP verwenden (was Sie auch tun) Wenn Sie könnten, können Sie XML-Fragmente erstellen, die einem Block der Seite entsprechen, die Sie dann bei Bedarf einfügen können. Dadurch erhalten Sie Modularität und können Inhalte weiterhin seitenübergreifend wiederverwenden.

Hören Sie auf Ihren Kollegen. Er hat Recht.

Kommentare

• Bitte beachten Sie meine Bearbeitung
• @ 0101, vermutete ich genau das. Tu es nicht ‚, es ist der Weg zum Wahnsinn – höchstwahrscheinlich für dich – a Und sicherlich für zukünftige Betreuer.
• Das eigentliche Problem ist, dass mein Weg der beste ist. Wenn ich 3 Seiten machen würde, könnte jemand nur eine der Seiten ändern und nicht an die anderen denken. Ich möchte meine Version als zukünftiger Betreuer.
• Ich denke, mein Code lässt die zukünftige Wartung über andere Fälle nachdenken. Wenn Sie ein neuer Programmierer des Projekts wären und im Debugger festgestellt hätten, dass Sie den Code in baseFormBasic.xhtml ändern müssen, würden Sie ihn auch in baseFormAdv und baseFormSpec ändern?
• @ 0101, warum fragen Sie, was am besten ist? Wenn Sie nur Ihre vorgefasste Meinung bestätigen lassen möchten?

Gibt es eine Möglichkeit, die Seite zu generieren Code verwenden? Wie wäre es in diesem Fall mit:

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

Und im Code zum Rendern der Seite

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

Oder im OOP-Stil:

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

Kommentare

• Nein, es gibt keine Änderung . Ich würde gekreuzigt werden, wenn ich es tun würde. Außerdem schafft es genau das gleiche Problem. if == gerendert.
• Es ist nicht das genaue Problem, da es die Seitenlogik extrahiert. Ich mache nur eine Aufgabe anstatt zwei.
• vielleicht, aber ich fühle, dass es das gleiche ist. Mein Grund ist, dass das Anzeigen von Feldern nur eine Sache ist, die sich unterscheidet. Es gibt auch unterschiedliche Platzierungen und manchmal Beschriftungen. Außerdem ist es die Webprogrammierung, so dass ich ‚ es nicht so machen kann.

Das Wesentliche dieser Frage scheint zu sein: Wenn Sie drei sehr ähnliche Webseiten mit ein paar kleinen Unterschieden haben, ist es besser, diese drei Seiten zu duplizieren und nach Bedarf zu ändern, oder die Logik zum dynamischen Rendern der Seite gemäß welchem „Modus“ in eine einzelne Seite zu integrieren „wird angesehen.

Für die Aufzeichnung bin ich ein JSF-Typ und ich mag es, und ich benutze bedingtes Rendern.

Wenn Sie sich für drei Seiten entscheiden, besteht das Risiko, dass der Betreuer diese bei Änderungen möglicherweise nicht auf alle drei Seiten korrekt anwendet.

Wenn Sie sich für das bedingte Rendern entscheiden, lösen Sie dieses Problem, haben jedoch eine Geschäftslogik in Ihre Seite verschoben, die möglicherweise einige Überlegungen erfordert.

Ich persönlich hätte kein Problem mit der Verwendung des bedingten Renderns, möchte aber wirklich, dass die Moduslogik auf eine Backing Bean verschoben wird, z. B.: anstelle von:

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

Ich mag:

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

Wo die Bean das handhabt Logik und gibt true oder false zurück, um das Rendern des Elements zu steuern.

Der Grund dafür ist, dass der angezeigte Modus möglicherweise mehr als nur diese eine Seite steuern muss, dass er möglicherweise auch über die einzelne Sitzung des Benutzers hinaus bestehen muss, oder dass Sie die Modi möglicherweise vollständig ändern müssen Straße.

Oder Sie können akzeptieren, dass jeder Ansatz potenzielle Nachteile hat und alle Nachteile darin bestehen, die Schmerzen auf der Straße zu lindern, und sich bereit erklären, sich darüber weitere Sorgen zu machen, wenn eines dieser Dinge „auf der Straße“ ist Kommen Sie tatsächlich und treffen Sie dann bessere Entscheidungen, da tatsächlich mehr darüber bekannt ist, wie sich die Anforderungen ändern könnten.