Cómo vender arquitectura DRY [duplicado]

La razón principal contra dos aplicaciones es que es muy probable que tenga que implementar los derechos de usuario de todos modos . ¿Es de suponer que no va a permitir que un asesor ingrese notas sobre los estudiantes que no aconseja, o que borre información importante sin privilegios de administrador de usuario, o que edite información sobre otros asesores? Una vez que tenga este mecanismo en su lugar, extenderlo a los estudiantes debería ser sencillo.

NB: Si sus superiores imaginan que los asesores académicos están de alguna manera por encima de los simples mortales en cuanto a no usar los privilegios, tienen una llamada de atención.

  

Otros en el equipo piensan que deberían ser dos completamente separados   aplicaciones debido a la complejidad de modificar las vistas basadas en   El nivel de autorización del usuario.

¿De verdad? ¿No se dan cuenta de que tienen que crear estas vistas de todos modos si hicieron 2 aplicaciones separadas? ¡Qué difícil es poner ambas vistas en la misma aplicación y decidir cuál mostrar en función de una bandera!

Ahora, hay que admitir que no implementa DRY por completo, pero es un muy buen comienzo: puedes reutilizar todo el código de back-end. Aquí es donde se realizará la mayor parte del trabajo y, por lo tanto, aquí es donde irá la mayor parte de su esfuerzo. La interfaz de usuario es casi una ocurrencia tardía en comparación.

Esto debería ayudarle a superar el problema de las "2 aplicaciones", y una vez que comiencen a crear la misma vista dos veces en el mismo proyecto, creo que comenzarán a considerar la duplicación y comenzarán a pensar en las partes que pueden se combinan en una sola vista ... y luego puedes decir "te lo dije" con convicción y suficiencia :-)

Por cierto, las mejores aplicaciones están escribiendo de una manera desacoplada como esta, el back-end proporciona una API que el cliente consume. Esto debería resolver el problema de la "complejidad de las llamadas", ya que diseñará el back-end para proporcionar los datos y la lógica necesarios (con suerte) antes de comenzar a codificar. Imagine que está utilizando datos proporcionados por un servicio de terceros en Internet: no puede decirles qué datos proporcionar, sino que llama a sus API y usa lo que le dan.

Claramente, las soluciones para 2 aplicaciones pueden carecer de experiencia. Solo imagina 'añadiendo este campo más' hecho dos veces.

La mayoría de los marcos MVC le permiten crear rutas separadas para usuarios separados (piense en example.com/admin, example.com/student, example.com/professor).

Esto, por supuesto, crea vistas por separado, pero (¡importante!) puedes extraer partes comunes (RoR las llama parciales, CakePHP las llama elementos). Este es un enfoque bien establecido

(no desea terminar con if en sus vistas para determinar si debe mostrar esta parte o no).

Recuerde que esto aumentará la complejidad, pero no tanto. En perspectiva hay años de gestión de esta aplicación. Usted pagará más al mantener dos versiones de casi las mismas aplicaciones.

// Edit: También verifique la respuesta de julia-hayward: enlace Este es un punto excelente: lo votaría, pero no tengo suficientes puntos para hacerlo.

El problema real en este caso es la capacidad de mantenimiento a largo plazo de dos bases de código separadas frente a una base de código única. Convencer a las personas que no entienden el problema requiere persuasión. ¿Tiene tu escuela un departamento de informática? ¿Qué tal una escuela de negocios o departamento de administración? El apoyo interno de un instructor sería bueno.

En resumen, el problema es este: escribe dos aplicaciones, terminas con dos bases de código, lo que significa potencialmente el doble de esfuerzo para mantener mientras estas aplicaciones estén en uso. Compartir módulos entre las bases de códigos puede mejorar este problema en cierta medida, pero si va tan lejos con la redefinición de su aplicación existente, simplemente modifíquela / rediseñe en una sola aplicación.

Los gerentes rechazarán lo que considerarán un esfuerzo adicional sin ganancia funcional, y debe convencerlos de que la recompensa se realizará a largo plazo. También le corresponde al equipo técnico hacer un buen trabajo en la aplicación para validar el argumento que está formulando, por lo que si decide buscar la solución que desea, asegúrese de que el equipo pueda respaldarla.

El argumento podría tener mérito de que será complicado cambiar la aplicación existente para acomodar diferentes conjuntos de permisos, pero la complejidad que se está discutiendo es un problema que debería haberse solucionado antes de que se construyera la primera aplicación. Si se conocía de antemano el requisito de proporcionar la funcionalidad a los estudiantes, era un error no diseñar para ello. No permita que un error pasado evite que el equipo tome la decisión correcta para la siguiente etapa del proyecto.

Creo que tengo otra versión.

• La aplicación de la facultad y el personal está funcionando y está en uso.
• Cambiarlo para crear una aplicación de estudiante tiene un gran riesgo.
• Espero que haya pocas pruebas automatizadas del sistema para la aplicación de la facultad y el personal.
• Es probable que se ejecuten en servidores diferentes, de modo que la aplicación para estudiantes no ralentice la aplicación del personal.
• Pueden tener diferentes ciclos de lanzamiento y prueba.
• Tarde o temprano, el diseño y la interfaz de usuario deberán ser diferentes entre las dos aplicaciones.

Es posible compartir código entre aplicaciones sin tener que ponerlo todo en una aplicación.

(Algunos sistemas de control de versiones permiten que cada aplicación tenga diferentes versiones del código compartido, mientras que te permite permanecer sano).

Sin embargo, comenzaría poniendo el código compartido en una biblioteca común y creando subclases para cada aplicación según sea necesario. Se utilizará un sistema de inyección de dependencias, por lo que una aplicación puede controlar la navegación entre vistas con la necesidad de tener todas las vistas informadas sobre ambas aplicaciones.

  

armar una nueva aplicación MVC

     

Algunos de los problemas que veo al hacer que esto sea un evento separado   Las aplicaciones son:

MANY of the views would actually be the same data being displayed.   

Un argumento en favo (u) r de una sola aplicación.

  

Tanto el código HTML como el modelo deberían copiarse entre los   Soluciones - por no mencionar las pruebas unitarias. No quiero mantener   El mismo código en ambos lugares que eventualmente se convertirá en muy   Difícil de mantener.   ¿No será el código del modelo idéntico, qué dos vistas y uno o dos controladores?

The skins for both sites are the same - any changes would have to be done in both places. 

CSS? O, podría usar AngularJs con plantillas para sus vistas.

The authentication and authorization parts are exactly the same for both applications.  

     

Estamos autentificando contra AD y tenemos un   base de datos de autorización común.

Por supuesto, si ese código ofrece una API limpia, entonces puede usarse si tienes una aplicación o dos.

Personalmente, me gusta AngulrJs para esto, ya que le permite mostrar / ocultar partes de una página web de forma sencilla en un solo dato en el alcance de $ del controlador.

<div ng-hide="isStudent" class="ng-hide">
   staff specific HTML goes here ...
</div>

y, en el controlador, simplemente establece $scope.isStudent según corresponda.

Por lo tanto, mi voto es para una sola aplicación y AngularJs

Al hablar con su equipo, debe ser explícito al decir que se trata de una compensación entre el tiempo inicial de comercialización de una primera versión del sitio del estudiante y el costo total de propiedad durante la vida útil del sistema.

He visto un sistema real que evolucionó a lo largo de una década a partir de PHP, donde los clientes tienen un micro sitio de extranet donde pueden cargar / descargar datos / informes a un sistema backend. Comenzaron sin control de código fuente y, literalmente, la carpeta copió el último micro-sitio personalizado para iniciar el próximo micro-sitio del cliente y realizó mejoras solo al último sitio en el que estaban trabajando.

Una década más tarde, tenían cientos de micro sitios semi-a medida en diferentes versiones de su código. Cabe destacar que el sistema fue (y sigue siendo) exitoso. Esto se debe a que cada micrositio era "lo suficientemente bueno" para que el cliente hiciera la entrada de datos que se mantuvo estable durante años. El hecho de que cada micro-sitio tuvo cambios por cliente se convirtió incluso en un punto de venta como "compromiso personalizado con el cliente".

El punto clave fue que nunca tuvieron que regresar y volver a probar los micro sitios antiguos cuando cambiaron cualquier cosa en la que se estaba trabajando para el último cliente nuevo. El hecho de que pudieran brindar una experiencia inconsistente a todos los clientes significaba que no tenían que mantener ningún código común (solo una lógica común de importación / exportación de datos a los sistemas backend que finalmente lograron generalizar como un código backend altamente configurable con un plano). interfaz de archivo).

Doy este ejemplo porque siempre hay una excepción que demuestra la regla general; la mayoría de los sitios realmente debe brindar una experiencia consistente, "lo más reciente y lo mejor" a todos los usuarios y no sería racional ni aceptable trabajar de la manera que acabamos de describir.

Con su aplicación, si tiene mucha lógica codificada en la página, sin el motor adecuado, sin la capa empresarial separada y las capas de acceso a datos, y sin modelo de datos / modelo de datos aislados, sin pruebas de unidad de back-end automatizadas y sin automatización prueba de front-end, entonces sí, sus colegas tienen razón, que al dejar lo que se hace solo y comenzar con una copia, que puede evolucionar rápidamente, hablando en su mayoría con las mismas tablas de bases de datos, sin volver a reparar y probar el sitio existente, obtendría un primer prototipo operativo en funcionamiento mucho más rápido que "hacerlo correctamente".

Sin embargo, después de un rápido éxito, su empleador querrá aprovechar su nueva aplicación para implementar nuevas características y capacidades que mejoren el compromiso entre el personal y los estudiantes. Esperarán que sea "una cosa" y que sea consistente y no parezca que "dos cosas" trabajen duro para mantenerse sincronizados.

Lo que necesita elaborar es cuál es la ganancia potencial a largo plazo cuando "lo hace correctamente"; qué nuevas características comunes son el futuro del sitio que justifican un modelo de datos compartido, una lógica de negocios común compartida, plantillas por tipo de usuario / vistas condicionales del usuario sobre el modelo / lógica. Si existen tales requisitos futuros (que seguramente deben), entonces quedará claro que actualizar a un framework / motor de seguridad / almacenamiento (cms) estándar, con un motor de plantillas condicional estándar para representar las vistas, diseñar / mejorar una información compartida. El modelo, el diseño de una lógica de negocios común para todos los usuarios, obtendría la experiencia completa del estado final sin el doble de código y seguramente el doble de esfuerzo y errores.

Le recomendaría que haya organizado una revisión de los posibles requisitos futuros y le sugiero que realice un trabajo de prueba de concepto (unas pocas semanas) para encontrar el mejor enfoque para preparar mejor el sistema para cumplir con esos requisitos futuros, mientras Al desarrollar la siguiente fase del proyecto (es decir, actualizar las funcionalidades de marcos / migraciones a un CMS de código abierto, puede escribir módulos personalizados para crear todas las funcionalidades a medida aprovechando la madurez de su infraestructura y el modelo de usuario). Sospecho que en este momento la gente se centrará en "la próxima fecha límite para que el sitio del estudiante esté en vivo" y pensará en "no hacer mucho trabajo o tener que aprender algo nuevo". Por lo tanto, debe entusiasmar al cliente / jefe acerca de la funcionalidad / estado final del futuro objetivo y entusiasmar a sus compañeros de "hacerlo correctamente" con nuevas y emocionantes herramientas y técnicas. Entonces, hacer lo correcto se convertirá en la idea de todos. Buena suerte.