Code générique ou code facile à comprendre?

Vous devez structurer vos modèles en utilisant les mêmes règles que lors de la programmation. Cela signifie essentiellement lextraction des éléments de conception communs dans des fichiers séparés pour éviter la duplication et ainsi obtenir une conception plus réutilisable. Cest la règle n ° 1 ( DRY ) et la méthode est appelée refactoring en termes de programmation.

La deuxième règle est que vous devez vous efforcer dobtenir simplicité et clarté. Il devrait être facile de comprendre la mise en page et où aller quand vous devez changer les choses.

Suivre la première règle à la lettre conduit à une forte décomposition de votre interface graphique en de nombreux petits extraits qui peuvent rendre difficile la compréhension de la création de la mise en page. Il faut beaucoup chercher pour savoir où se trouvent les choses. Cela enfreint la deuxième règle, donc vous devez trouver un équilibre entre ces deux opposés.

Mais la meilleure approche est de trouver une solution qui évite complètement ce problème. Je pense que, dans ce cas, vous devriez envisager une approche plus simple, . Je suppose que cest du HTML et que vous mentionnez des états « simples et avancés » dans linterface graphique. Avez-vous envisagé de toujours générer tous les champs, puis gérer la logique de linterface graphique en JavaScript? En dautres termes, écrire du code côté client qui masque et affiche les champs pertinents à la volée en fonction du mode (état) dans lequel il se trouve?

Cela a également lavantage de pouvoir changer de mode à la demande sans impliquer le serveur et vous navez à compromettre aucune des règles. Une autre bonne chose est que vous pouvez laisser les gars du front-end effectuez ces changements sans avoir à impliquer les programmeurs back-end qui ne sont généralement pas trop désireux de passer du temps à peaufiner et peaufiner la conception et linteraction.

Commentaires

• Je ne suis pas daccord pour dire que JS est plus simple, pourquoi? la plupart de mes collègues ne ‘ ne connaissent pas de plus en plus les frameworks Web JS et Java vous permettent dignorer JS (Richfaces, GWT ). Presque toutes les entreprises ne se soucient pas de JS (je pense quon ma posé une question JS dans toutes les entreprises dans lesquelles jai jamais interviewé). Ainsi, mes collègues ne toucheraient pas à ce code et ils le réécriraient simplement sils avaient pour le changer. Votre idée est bonne, mais ce n’est pas réaliste. Et pourquoi garder une partie de votre logique en java et une partie en JS? Je pense que c’est la raison pour laquelle les procédures stockées sont mortes (et je ke eux).
• @ 0101 Je nai ‘ pas dit que JS est plus simple ou plus difficile que tout. Cela dépend de vos compétences. Avec un codeur html compétent, ce ne serait pas un problème. Jai dit quen reportant les problèmes dinterface graphique à la couche GUI (à sa place), vous vous retrouvez souvent avec une solution beaucoup plus simple. En effet, les interfaces graphiques sont hautement dynamiques et interactives, pour quel langage comme JS est fait. Tout simplement parce que vous pensez que  » aucune entreprise ne se soucie de JS « , ne fait ‘ mon point est moins valable.
• Je pense que cest le cas, la question est de savoir quoi faire dans ma situation et votre réponse est comme  » utiliser des procédures stockées  » et ce nest pas valide car personne ne lutilise et il serait difficile de comprendre pourquoi je les aurais utilisés. Je ‘ m demande quel chemin est le meilleur pour le futur car je ‘ ne suis pas sûr à 100% que mon choix est le meilleur (maintenant le le meilleur moyen est dignorer les collègues ennuyeux).
• @ 0101: Travailler avec le Web et HTML implique plus ou moins JavaScript (et HTTP et CSS et images …), donc vous pouvez ‘ Je ne veux vraiment pas me blâmer davoir supposé que JavaScript était une option. Il ‘ nest pas comme si je ‘ vous demande de lécrire en Swing.
•  » Presque toutes les entreprises ne se soucient pas de JS  » – le croyez-vous sérieusement? Les interfaces riches sur le Web évoluent dans une direction côté client depuis de nombreuses années maintenant. Je pense que vous manquez le bateau sur celui-ci.

Sans voir le code, je ne peux que spéculer, mais je suppose que pour le moment votre code est « sur le bord ».

Pour 2 ou 3 modes avec un nombre limité de changements entre ces modes, ce que vous avez maintenant est probablement OK. Cependant, si cela devait être plus compliqué, il semblerait quil devrait être refactorisé dans des pages séparées.

Personnellement, je préfère un code facile à comprendre – il est beaucoup plus facile à gérer, à la fois pour les autres développeurs et pour vous-même lorsque vous devez le reprendre 6 mois plus tard.

Cependant, il ny a aucun sens à refactoriser le code maintenant pour résoudre un problème qui pourrait ne pas exister dans le futur . Vous dites que vous ne savez pas à quel point les exigences vont changer – et cela ninclut aucun changement – donc en appliquant YAGNI (You Ain « t Gonna Need It) ne faites rien maintenant.

Marquez le code comme nécessitant une attention particulière à lavenir pour ne pas loublier, mais ne le modifiez pas (et ne le cassez pas) maintenant.

Commentaires

• + 1 – En cas de doute, allez-y avec facile à comprendre. Le problème qui vous vient à lesprit pour savoir si vous devriez le rendre générique est une façon naturelle de vous dire que vous ne devriez pas ‘ t.

Jai fait à peu près la même chose. Croyez-moi, après avoir implémenté quelques comportements différents pour chaque mode, la «page principale» devient un désordre presque impossible à lire. Vous ne verriez alors quun groupe de blocs de flux de contrôle (peu de temps suivis par Matrix Digital Rain). Je me suis retrouvé à supprimer quelques blocs juste pour avoir une vue claire de ce qui se trouve dans un certain mode.

Donc, les « pages séparées » sont la voie à suivre. Cependant, lorsque vous faites cela, vous devez  » combattre « le problème de duplication de code. Cest là que votre collègue pourrait se tromper en suggérant des fusions. Malheureusement, je lai fait aussi. En gros ça marche, mais ça consomme beaucoup de temps précieux et finalement par une mauvaise fusion « la zone commune » des pages est désynchronisée et la fusion devient un véritable cauchemar. Vous avez donc raison de vous opposer à une fusion comme solution raisonnable.

Comme vous pouvez le voir dans de nombreuses réponses, la bonne approche consiste à extraire des parties vraiment « communes » à des entités externes (fragments de page JSP, extraits de code JSF, peu importe) et les inclure dans ces pages.

Commentaires

• le vrai problème que le code commun est juste les contrôles h: inputText + h: outputText pour champ unique. Je pense que ça ne vaut pas la peine de le combattre. De plus, cette page pourrait mourir car elle nest pas vraiment fonctionnelle, à cause des modes et de sa confusion même pour les autres développeurs (du point de vue de lutilisateur).
• Le problème est donc vraiment de savoir quand faire la transition. Vous devez reconsidérer le fractionnement après chaque modification. Lorsque la page commence à être désordonnée, divisez-la. Je pense que votre collègue sera également plus à laise si vous considérez que son idée est bonne, mais quelle ne vaut pas la peine dêtre mise en œuvre.

La duplication de code nest pratiquement jamais une bonne chose. Cela dit, une petite quantité dupliquée pas beaucoup plus de deux fois est acceptable dans la vraie vie – il vaut mieux être pragmatique que religieux à ce sujet. Dans votre cas, cela ressemble à une plus grande quantité de code et 3 places, donc cest légèrement au-dessus de mon seuil personnel. Ainsi je penche vers la version générique.Et en tout cas, si cela fonctionne maintenant, il nest pas nécessaire de le toucher uniquement pour des raisons théoriques.

OTOH quand vous dites quil peut y avoir plus de différences entre les pages à lavenir, cela pourrait signifier que à un moment donné, il devient plus économique de passer à des pages distinctes (tout en sefforçant de minimiser la duplication entre elles en extrayant autant que possible les points communs). Réévaluez donc la situation avant chaque changement futur.

Cela ressemble à JSF. Chaque rendu = « … » signifie essentiellement que vous avez un if dans votre code, ce qui entraîne une complexité supplémentaire.

Jai « fait la même chose parce que » cest la même page avec quelques différences ici et là « et en termes simples, cela ne fonctionne pas à long terme car il nest pas » t la même page et vous devrez faire des astuces de plus en plus élaborées pour le faire fonctionner correctement, ce qui le rendra inutilement difficile à maintenir.

Si vous utilisez JSF avec des facelets au lieu de JSP (que vous devrait si vous le pouvez), vous pouvez créer des fragments XML correspondant à un bloc de la page, que vous pouvez ensuite inclure si nécessaire. Cela vous achètera de la modularité et vous permettra toujours de réutiliser le contenu entre les pages.

Écoutez votre collègue. Il a raison.

Commentaires

• sil vous plaît voir ma modification
• @ 0101, je soupçonne exactement ceci. Ne le faites pas ‘, cest le chemin de la folie – probablement pour vous – un Et certainement pour les futurs responsables.
• le vrai problème est que mon chemin est le meilleur. si je faisais 3 pages, quelquun pourrait changer une seule des pages et ne pas penser aux autres. Je voudrais ma version comme futur mainteneur.
• Je pense que mon code fait réfléchir le futur maintaine à dautres cas. Si vous étiez un nouveau programmeur du projet et que le débogueur trouviez que vous devez changer le code dans baseFormBasic.xhtml, le changeriez-vous également dans baseFormAdv et baseFormSpec?
• @ 0101, pourquoi demander ce qui est le mieux, si vous voulez juste faire confirmer votre opinion préconçue?

Y a-t-il une chance de générer la page en utilisant le code? Dans ce cas, que diriez-vous de quelque chose comme:

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

Et dans le code de rendu de page

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

Ou dans le style POO:

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

Commentaires

• non, il ny a pas de changement . Je serais crucifié si je le faisais. de plus, cela crée exactement le même problème. if == rendu.
• Ce nest pas le problème exact puisquil extrait la logique de page. Faire une seule tâche, au lieu de deux.
• peut-être, mais je pense que cest la même chose. ma raison est que laffichage des champs nest quune chose qui est différente, il y a aussi des emplacements différents et parfois des étiquettes. plus cest la programmation Web, donc je peux ‘ le faire comme ça.

le code modal ne peut quempirer . Classez et décidez une fois au début, et branchez pour nettoyer les implémentations sans modes.

Commentaires

• isn ‘ t pire? tout le code doit toujours être synchronisé les uns avec les autres (si vous changez simple, pensez à changer davance et que faire si vous oubliez?)
• isoler le code commun dans les sous-programmes, les fonctions, les classes dassistance / de base, et al ; en POO, le code modal est une indication des classes manquantes …

Lessence de cette question semble être: lorsque vous avez trois pages Web très similaires avec quelques différences mineures, est-il préférable de dupliquer ces trois pages et de modifier chacune au besoin, ou dintégrer dans une seule page la logique pour rendre dynamiquement la page selon quel « mode » « est en cours de visualisation.

Pour mémoire, je suis un gars JSF et jaime ça, et jutilise le rendu conditionnel.

Si vous choisissez davoir trois pages, il y a un risque que, à mesure que des changements se produisent, le responsable ne lapplique pas correctement aux trois pages.

Si vous optez pour le rendu conditionnel, vous résolvez ce problème, mais vous avez déplacé une logique métier dans votre page, ce qui pourrait nécessiter une réflexion.

Personnellement, je naurais aucun problème avec lutilisation du rendu conditionnel, mais jaimerais vraiment voir la logique du mode déplacée vers un bean de sauvegarde, par exemple: au lieu de:

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

Jaime:

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

Où le bean gère le logique et renvoie true ou false pour contrôler le rendu de lélément.

La raison en est que le mode affiché peut avoir besoin de contrôler plus que cette seule page, il peut être nécessaire de le conserver au-delà même de la session unique de lutilisateur, ou vous devrez peut-être changer complètement de mode route.

Ou bien, vous pouvez accepter que lune ou lautre approche présente des inconvénients potentiels, et que tous les inconvénients semblent concerner le soulagement des douleurs sur la route, et acceptez de vous en inquiéter davantage lorsque lune de ces choses «sur la route» en fait, puis prendre de meilleures décisions maintenant quon en sait plus sur la façon dont les exigences pourraient changer.