¿Código genérico o código fácil de entender?

Debes estructurar tus plantillas usando las mismas reglas que cuando programabas. Básicamente, esto significa extraer elementos de diseño comunes en archivos separados para evitar la duplicación y así lograr un diseño más reutilizable. Esa es la regla # 1 ( DRY ) y el método se llama refactorización en términos de programación.

La segunda regla es que debes esforzarte por sencillez y claridad. Debe ser fácil comprender el diseño y adónde ir cuando necesite cambiar las cosas.

Seguir la primera regla al pie de la letra conduce a una gran descomposición de su interfaz gráfica de usuario en montones y montones de pequeños fragmentos que pueden dificultar la comprensión de cómo se crea el diseño. Tienes que buscar mucho para encontrar dónde están las cosas. Esto viola la segunda regla, por lo que necesitas encontrar un equilibrio entre estos dos opuestos.

Pero el mejor enfoque es encontrar una solución que evite este problema por completo. Creo que, en este caso, debería considerar un enfoque más simple en conjunto . Supongo que esto es HTML y mencionas estados «simples y avanzados» en la GUI. ¿Ha considerado siempre generar todos campos y luego manejar la lógica GUI en JavaScript? En otras palabras, escriba un código del lado del cliente que oculte y muestre los campos relevantes sobre la marcha dependiendo del modo (estado) en el que se encuentre.

Esto también tiene la ventaja de poder cambiar de modo bajo demanda sin involucrar al servidor y no tiene que comprometer ninguna de las reglas. Otra gran cosa es que puede dejar que los chicos del front-end Realice estos cambios sin tener que involucrar a los programadores de back-end que, por lo general, no están demasiado interesados en dedicar tiempo a ajustar y pulir el diseño y la interacción.

Comentarios

• No estoy de acuerdo con que JS sea más simple, ¿por qué? La mayoría de mis compañeros de trabajo no ‘ no conocen JS y los frameworks web de Java, cada vez más te permiten ignorar JS (Richfaces, GWT Casi todas las empresas no se preocupan por JS (creo que me hicieron una pregunta de JS en todas las empresas en las que he entrevistado). Por lo tanto, mis compañeros de trabajo no tocarían ese código y simplemente lo volverían a escribir si tuvieran para cambiarlo. Tu idea es buena, pero no realista. Además, ¿por qué mantener parte de tu lógica en java y parte en JS? Creo que esa es la razón por la que los procedimientos almacenados habían muerto (y yo no ke ellos).
• @ 0101 No ‘ t dije que JS es más simple o más difícil que cualquier otra cosa. Depende de tus habilidades. Con un codificador html competente, esto no sería un problema. Dije que al diferir los problemas de GUI a la capa de GUI (donde pertenece), a menudo terminas con una solución mucho más simple. Esto se debe a que las GUI son altamente dinámicas e interactivas, para lo que está hecho un lenguaje como JS. Solo porque crea que » ninguna empresa se preocupa por JS «, no ‘ mi punto es menos válido.
• Creo que sí, la pregunta es qué hacer en mi situación y su respuesta es como » usar procedimientos almacenados » y eso no es válido ya que nadie lo está usando y sería difícil entender por qué los habría usado. Estoy ‘ preguntando qué camino es mejor para el futuro, ya que ‘ no estoy 100% seguro de que mi elección sea la mejor (ahora el La mejor manera es ignorar al compañero de trabajo molesto).
• @ 0101: Trabajar con web y HTML implica más o menos JavaScript (y HTTP y CSS e imágenes …), por lo que puede ‘ Realmente no me culpo por suponer que JavaScript era una opción. ‘ no es como si ‘ le pida que lo escriba en Swing.
• » Casi todas las empresas no se preocupan por JS «. ¿Lo cree en serio? Las interfaces ricas en la web se han estado moviendo en una dirección del lado del cliente durante muchos años. Siento que estás perdiendo el barco en este caso.

Sin ver el código, solo puedo especular, pero supongo que en este momento su código está «al límite».

Para 2 o 3 modos con un número limitado de cambios entre esos modos, lo que tiene ahora probablemente esté bien. Sin embargo, si fuera más complicado, parece que debería ser refactorizado en páginas separadas.

Personalmente prefiero el código fácil de entender – es mucho más fácil de mantener, tanto para otros desarrolladores como para usted cuando tienes que retomarlo 6 meses después.

Sin embargo, no tiene sentido refactorizar el código ahora para resolver un problema que podría no existir en el futuro . Dice que no sabe cuánto cambiarán los requisitos, y eso no incluye ningún cambio, por lo que al aplicar YAGNI (No lo va a necesitar) no haga nada ahora.

Marque el código como que requiera atención en el futuro para que no lo olvide, pero no lo cambie (y posiblemente lo rompa) ahora.

Comentarios

• + 1 – En caso de duda, opte por lo fácil de entender. La queja en el fondo de su mente acerca de si debe hacerlo genérico es la forma en que la naturaleza le dice que no debe ‘ t.

He hecho más o menos lo mismo. Créame, después de implementar algunos comportamientos diferentes para cada modo, la «página principal» se vuelve un desastre casi imposible de leer. Entonces vería solo un grupo de bloques de flujo de control (poco seguido por lluvia digital Matrix). Me encontré quitando algunos bloques solo para tener una visión clara de lo que hay dentro de un modo determinado.

Así que las «páginas separadas» son el camino a seguir. Sin embargo, cuando lo haces, tienes que hacerlo » luchar «contra el problema de duplicación de código. Aquí es donde su colega podría estar equivocado al sugerir fusiones. Lamentablemente, yo también he hecho eso. Básicamente funciona, pero consume una gran cantidad de tiempo precioso y, finalmente, debido a una combinación deficiente, el «área común» de las páginas no está sincronizada y la combinación se convierte en una verdadera pesadilla. Así que tiene razón al objetar una fusión como una solución razonable.

Como puede ver en muchas respuestas, el enfoque correcto es extraer partes verdaderamente «comunes» de entidades externas (fragmentos de página JSP, fragmentos JSF, lo que sea) e incluirlos en esas páginas.

Comentarios

• el problema real de que el código común son solo los controles h: inputText + h: outputText para campo único. Siento que no vale la pena luchar contra él. además, esta página podría morir porque no es realmente funcional, debido a los modos y es confusa incluso para otros desarrolladores (desde el punto de vista del usuario).
• Entonces el problema es realmente cuándo hacer la transición. Tienes que reconsiderar la división después de cada modificación. Cuando la página comience a estar desordenada, divídala. Creo que su compañero de trabajo también se sentirá más cómodo si considera que su idea es buena, pero aún no vale la pena implementarla.

La duplicación de código prácticamente nunca es algo bueno. Dicho esto, una pequeña cantidad duplicada no más de dos veces es aceptable en la vida real; es mejor ser pragmático que religioso al respecto. En su caso, suena como una mayor cantidad de código y 3 lugares, por lo que está un poco por encima de mi umbral personal. Por lo tanto, me inclino hacia la versión genérica.Y en cualquier caso, si funciona ahora, no es necesario tocarlo solo por razones teóricas.

OTOH cuando dices que puede haber más diferencias entre las páginas en el futuro, esto podría significar que en algún momento se vuelve más económico cambiar a páginas separadas (mientras se esfuerza por minimizar la duplicación entre ellas extrayendo puntos en común tanto como sea posible). Así que reevalúe la situación antes de cada cambio futuro.

Esto se parece a JSF. Cada renderizado = «…» esencialmente significa que tiene un if en su código, lo que causa una complejidad adicional.

«He hecho lo mismo porque» es la misma página, solo que con algunas diferencias aquí y allí «y en pocas palabras, no funciona a largo plazo porque no es» t la misma página y necesitará hacer trucos cada vez más elaborados para que funcione correctamente, lo que hará que sea innecesariamente difícil de mantener.

Si usa JSF con facelets en lugar de JSP (que debería, si pudiera), entonces puede crear fragmentos XML correspondientes a un bloque de la página, que luego puede incluir donde sea necesario. Esto le comprará modularidad y aún le permitirá reutilizar el contenido en todas las páginas.

Escuche a su compañero de trabajo. Tiene razón.

Comentarios

• por favor vea mi edición
• @ 0101, sospechaba exactamente esto. No ‘ no lo hagas, es el camino a la locura, muy probablemente para ti, un y ciertamente para futuros mantenedores.
• El verdadero problema es que mi camino es el mejor. si hiciera 3 páginas, alguien podría cambiar solo una de las páginas y no pensar en las otras. Me gustaría mi versión como futuro mantenedor.
• Creo que mi código está haciendo que el futuro mantenedor piense en otros casos. Si fuera un programador nuevo del proyecto y en el depurador descubriese que necesita cambiar el código en baseFormBasic.xhtml, ¿lo cambiaría también en baseFormAdv y baseFormSpec?
• @ 0101, ¿por qué preguntar qué es lo mejor? si solo desea que se confirme su opinión preconcebida?

¿Existe la posibilidad de generar la página usando código? En este caso, ¿qué tal algo como:

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

Y en el código de representación de la página

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

O en estilo OOP:

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

Comentarios

• no, no hay cambios . Sería crucificado si lo hiciera. además crea exactamente el mismo problema. if == renderizado.
• No es el problema exacto ya que extrae la lógica de la página. Haciendo solo una tarea, en lugar de dos.
• tal vez, pero siento que es lo mismo. mi razón es que mostrar campos es solo una cosa que es diferente, también hay diferentes ubicaciones y, a veces, etiquetas. además es la programación web, así que no puedo ‘ hacerlo así.

La esencia de esta pregunta parece ser: cuando tiene tres páginas web muy similares con algunas diferencias menores, ¿es mejor duplicar esas tres páginas y modificar cada una según sea necesario, o construir en una sola página la lógica para representar dinámicamente la página de acuerdo con qué «modo «se está viendo.

Para que conste, soy un tipo JSF y me gusta, y hago uso de la representación condicional.

Si opta por tener tres páginas, existe el riesgo de que, a medida que se produzcan cambios, el responsable del mantenimiento no lo aplique correctamente a las tres páginas.

Si opta por utilizar la representación condicional, resuelve ese problema, pero ha trasladado cierta lógica empresarial a su página, lo que podría necesitar un poco de reflexión.

Yo personalmente no tendría ningún problema con el uso de la representación condicional, pero realmente me gustaría ver la lógica del modo movida a un bean de respaldo, por ejemplo: en lugar de:

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

Me gusta:

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

Donde el bean maneja el lógica y devuelve verdadero o falso para controlar la representación del elemento.

La razón es que el modo que se está visualizando puede necesitar controlar más que solo esta página, puede necesitar persistir incluso más allá de la sesión única del usuario, o puede que necesite cambiar los modos completamente hacia abajo la carretera.

O bien, puede aceptar que cualquiera de los enfoques tiene posibles inconvenientes, y todos los inconvenientes parecen estar relacionados con aliviar los dolores en el futuro, y acepta preocuparse aún más cuando se produzca una de esas cosas «en el futuro» surgen y luego toman mejores decisiones ahora que se sabe más sobre cómo podrían cambiar los requisitos.