Tengo la necesidad de explicar MVC a los no programadores. A saber, a los gerentes de otros departamentos, en el contexto del informe de progreso. Una de las cosas que hago es refactorizar nuestra base de código hacia la separación MVC.

¿Qué es la separación MVC que podrían pedir? ¿Por qué es necesario que puedan preguntar?

Después de leer una respuesta bastante técnica como esta: ¿Qué es realmente MVC? , No estoy completamente satisfecho, ya que hablaré con personas que no son programadores. Pueden asentir con la cabeza, pero probablemente no entenderán qué es y por qué es necesario.

En realidad, no entiendo completamente lo que MVC es aparte de "separación de preocupaciones, deberes, funciones, clases, bloques, tareas, cosas, para mejorar la flexibilidad de hacer cambios en el software". Separar la base de datos de la vista y la vista de la lógica empresarial utilizando técnicas como las herramientas y técnicas DI y OO es algo que considero una separación MVC.

Entonces, la próxima vez que explique MVC a un no programador con experiencia en ventas y contabilidad, por ejemplo, ¿qué le diría?

No explicas MVC.

Lo que debe hacer es explicar que se trata de una reestructuración de la base de código.

Una reestructuración que simplifica la base de código y, por lo tanto, permite a los desarrolladores realizar cambios más rápidos y mejores en los informes de errores y solicitudes de características, con menos errores.

No necesitan conocer los detalles técnicos, solo por qué se hizo, qué se logró al hacerlo y cómo se beneficia el negocio.

En otras palabras, háblales su idioma.

Si bien respaldo la esencia de la respuesta de Oded , que debe explicar los proyectos técnicos a los gerentes de negocios en "su idioma", tengo dudas acerca de "no necesitan saber detalles técnicos, solo por qué se hizo".

Si está en una reunión de revisión de proyectos o inversiones con los jefes de departamento, y declara "esto es lo que estamos haciendo", es posible que quieran preguntar "Umm ... ¿por qué? Eso parece una gran inversión de tiempo y energía". ¿Podría darnos un poco más de comprensión de lo que está haciendo y por qué? Esa parece una pregunta eminentemente razonable. No quieres quedar atrapado en una posición de "Bueno ... es complicado". o "No, realmente no puedo explicarlo". o "No se preocupen por eso". Cuanto más alto sea el personal para el que está haciendo la revisión del proyecto, menos probable es que dejen volar "son cosas que no puedo explicar bien". Mejor si puedes ir al menos un nivel más profundo para que otros se sientan cómodos que 1) sabes lo que eres '

Por lo tanto, tenga un boceto de MVC en el bolsillo de su cadera, listo para usar. Algo como:

"Es un poco técnico, pero ... MVC divide el código en Modelos (responsables de los datos centrales y la lógica empresarial), Vistas (que muestra los datos) y Controladores (que manejan las interacciones y actualizaciones del usuario). Es una arquitectura comprobada. -posiblemente el "patrón de diseño" más exitoso de la ingeniería de software. Sé que podría parecer "solo un poco de fontanería", pero para manejar todas las solicitudes que lleguen, necesitamos una base más sólida. Esto nos pondrá en el camino correcto para construir nuevos características y resolver errores más rápido ".

Incluso si no comprenden completamente el MVC al final, e incluso si tuviera que simplificar demasiado para hacerlo comprensible ("rompa algunos huevos para hacer una tortilla"), apuesto a que le resultará mucho más cómodo tenga una explicación lista que tener que decir "No puedo explicarlo" o "no está calificado para entenderlo" a los gerentes superiores.

para mejorar la flexibilidad de realizar cambios en el software

Los gerentes están interesados ​​en el resultado final. Cuanto menos técnicos sean, menos probable es que se preocupen por cómo llegar allí. MVC es muy común, popular y probado.

Cuando se realizan solicitudes de cambio en el futuro, puede informar a la administración que se pueden hacer más fácil y más rápido. A todos les gusta escuchar esto.

Es una estrategia común, por lo que contratar nuevos desarrolladores no debería presentar un problema. De hecho, puede atraer a mejores desarrolladores que sean fuertes defensores.

Todo esto será muy difícil si hay muchos problemas urgentes en este proyecto en particular. Es posible que no estén dispuestos a dar un paso atrás para que pueda dar dos pasos adelante. La solución puede ser esperar o implementar en piezas más pequeñas.

• Modelo - Cables / electricidad
• Ver - Luminaria
• Controlador - Interruptor de luz

Relativamente fácil cambiar componentes (luminaria, interruptor de luz / dimmer). Quizás no tanto el cableado, pero aún se puede hacer sin afectar a otros componentes. Todos deberían poder visualizar eso en su cabeza, incluso los tipos de marketing / ventas. (Separación clara, etc.)

Ahora dígale a su jefe / compañeros de trabajo que en nuestra aplicación / sistema el interruptor está incrustado dentro de la lámpara y la lámpara está envuelta en un cable de cobre. Ahora imagine intentar actualizar la lámpara, el interruptor o el cable. Muy costoso, el impacto en otros componentes es muy alto y quizás peligroso hacerlo sin romper otra cosa.

MVC está aplicando un patrón a la base de código que convierte el desorden desordenado (pero que funciona) en algo donde los cambios pueden ocurrir más rápido y más fácil con menos errores.

Una manera fácil de entender MVC: el modelo son los datos , la vista es la ventana en la pantalla y el controlador es el pegamento entre los dos .

La mejor rúbrica de la historia: "Necesitamos modelos SMART, controladores THIN y vistas DUMB"

Al igual que con otros patrones de diseño de software, MVC expresa el " núcleo de la solución " a un problema al tiempo que permite que se adapte a cada sistema. Se ve mejor como un concepto en lugar de una implementación específica. Hay muchas implementaciones del concepto.

Todas las variantes de MVC usan la misma división de componentes, pero generalmente difieren en cómo interactúan esos componentes.

Para aquellos de ustedes que no lo saben, MVC se describió originalmente en términos de un patrón de diseño para usar con Smalltalk por Trygve Reenskaug en 1979 . Su artículo fue publicado bajo el título "Programación de aplicaciones en Smalltalk-80: Cómo usar Model-View-Controller", y preparó el terreno para la mayoría de las futuras implementaciones de MVC.

Estoy a mitad de acuerdo con Oded: aprender a convencer a sus pares y gerentes no técnicos de que lo que está haciendo es importante y útil, sin explicar los detalles, es una habilidad necesaria que sería prudente desarrollar.

Sin embargo, creo que tener la capacidad de explicar conceptos complejos en términos simples realmente ayuda con eso: un problema que los gerentes no técnicos a menudo tienen es que, dado que tienen problemas para comprender exactamente qué es lo que están haciendo los técnicos, tienen una tendencia a desconfío de ellos. Es solo la naturaleza humana: es más fácil creer que algo que no entiendes es inútil o incorrecto que confiar en él. Por lo tanto, si puede hacer que los conceptos sean fáciles de entender a voluntad, puede usarlos siempre que lo necesite, y con el tiempo, sus gerentes no técnicos aprenderán que pueden entenderlos si lo desean: no está deteniendo uno. en ellos, solo les estás ahorrando los detalles para su propia cordura. Ellos confiarán más en ti.

Aparte de eso, respondamos la pregunta:

Me resulta útil utilizar analogías que entienden los empresarios. Para MVC, lo describo como un negocio.

• Los modelos son responsables de la lógica y los datos comerciales: son las cosas que definen lo que hace el programa y los detalles de cómo lo hace. Si el programa fuera un negocio, entonces los modelos serían almacenes, fábricas, trabajadores y equipo de capital. También serían los gerentes de nivel inferior que se asegurarán de que se sigan las reglas y se apliquen las políticas.
• Las vistas son la capa de presentación: muestran a los usuarios lo que está sucediendo en el sistema y proporcionan un medio para interactuar con el programa. Si nuestro programa fuera una empresa, las vistas serían como el piso de la sala de exposición, el puesto de ventas en la convención comercial o los representantes de ventas. Muestran opciones, proporcionan información y comentarios fáciles de usar, y llevan las solicitudes a la empresa.
• Los controladores son la capa de coordinación: se aseguran de que la información llegue de los modelos a las vistas y viceversa, y que todo funcione en conjunto para hacer su trabajo. Si el programa fuera una empresa, los controladores serían la gerencia de nivel medio y alto. No se involucran demasiado en los detalles, pero se aseguran de que las personas adecuadas tengan las herramientas adecuadas para hacer su trabajo, y aprueban o niegan decisiones de alto nivel. Proporcionan la dirección general para que las cosas puedan funcionar juntas.

El beneficio de explicarlo con esta analogía es que un buen gerente verá la sabiduría al separar las preocupaciones de esta manera, ¡y podría decidir que deberían ser más similares a un controlador y no involucrarse demasiado en los detalles en el futuro!

Con suerte, eso responderá al "qué", el "por qué" también es fácil con esta analogía:

Imagine una compañía ideal, donde cada departamento es responsable de un conjunto de tareas, y sabe que siempre tendrá los recursos que necesita sin tener que preocuparse por lo que otros están haciendo. Un representante de ventas encuentra un cliente, obtiene su pedido, lo devuelve a la gerencia que lo aprueba y luego va al almacén / producción / ingeniería para su cumplimiento. La retroalimentación es directa: nadie más debe involucrarse a menos que haya un problema. Es un buen diseño de MVC: cada parte tiene un trabajo y no tiene que preocuparse por otras partes. De esa manera, es fácil cambiar si es necesario. En un diseño que no es MVC, las responsabilidades no están claras. El representante de ventas puede intentar modificar el producto cuando el cliente solicita algo diferente. O podrían dar precios diferentes dependiendo de cómo se sintieron ese día. El CEO podría estar en el piso de la fábrica jugando con la línea de producción, cuando debería estar preocupado por cómo establecer una cadena de suministro más confiable. Los trabajadores del almacén podrían estar en el piso de ventas hablando con los clientes cuando deberían cumplir con los pedidos que ya se tomaron.

En otras palabras, un buen diseño de MVC permite que cada parte se centre en una cosa, para que pueda hacerlo bien, al igual que una empresa bien organizada.

** Descargo de responsabilidad: si su empresa está mal organizada, podrían ofenderse por esto. En ese caso, necesitará otra analogía. Es posible que también necesite un trabajo diferente.

Los beneficios de MVC están principalmente en la separación de preocupaciones:

Permite a las personas concentrarse en lo que mejor hacen.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Reduce los costos porque los sistemas entrelazados requieren que el personal sea experto en todas estas áreas, o es más probable que tenga problemas cuando un cambio en un área afecta a las demás.

Proporcione ejemplos reales de arquitecturas MVC: teléfonos celulares, teléfonos de escritorio, Skype, etc. Cambiar la vista (tipo de teclado, altavoces, micrófonos) no afecta el modelo (la señal de audio), el controlador es el circuito en El teléfono que traduce las ondas sonoras en señales de audio.

Les diría que MVC separa mis preocupaciones.

Mi primera preocupación es la lógica del código: lo que hago detrás de escena para que el sitio web realice las acciones que desean.

Mi segunda preocupación es la lógica de negocios: lo que ellos (el usuario) quieren que haga la aplicación.

Mi tercera preocupación es cómo se ve el sitio: la página que visitan para hacer lo que quieren.

(No les diría esta próxima parte) Entonces, en orden, mis explicaciones fueron para el Modelo, el Controlador y la Vista.

Explicar las ventajas.

Explicaría MVC en términos de beneficios comerciales. Sus gerentes podrán entender esto y se unirán si las ventajas son convincentes.

MVC le permite dividir su aplicación en unidades sensibles, cada una de las cuales existe independientemente de las demás. Obtiene código limpio, mantenible, comprobable y potencialmente reutilización de código entre sistemas.

El modelo

Cada modelo encapsula un solo tipo de información comercial, por ejemplo, un registro de cliente o un producto, junto con toda la lógica comercial relacionada.

Separar esto le permite probar fácilmente la lógica de su negocio aisladamente de otras partes de su aplicación.

También puede extender fácilmente la aplicación agregando modelos adicionales, es muy modular y limpia.

Cada modelo en teoría puede existir independientemente de los demás. Puede considerar aplicar esto mediante el uso de objetos de servicio para manejar las relaciones entre modelos. Puede intercambiar modelos sin afectar el resto del sistema.

La vista

Separar su vista le permite actualizar fácilmente su front-end sin romper el back-end subyacente.

Puede dar su código de front-end a otro desarrollador sin necesariamente darles acceso a todo el sistema.

También es libre de crear front-end alternativos que funcionen con el sistema existente. Puede mostrar sus datos como una aplicación móvil, o una API, o un PDF, o una hoja de cálculo de Excel. Puede hacer esto sin hackear el resto del sistema. Es menos probable que rompa cosas accidentalmente. Puede crear fácilmente puntos de integración para que los sistemas existentes se conecten.

El controlador

El controlador conecta los modelos a la vista. Mantiene todo separado. Puede cablear en una vista diferente muy fácilmente. Si cambia el código de su modelo, la vista ni siquiera necesita saberlo.

Otras ventajas

Es un patrón común. Otros desarrolladores podrán entender su código y trabajar en él. Si regresa a su código años después, es probable que pueda entenderlo y hacer cambios. Es menos probable que su código se convierta en otro dolor de cabeza heredado para un futuro desarrollador.

Debido a que todo tiene un lugar, es mucho más fácil producir código limpio. El riesgo de espaguetización se reduce drásticamente (aunque no se elimina). Su código se vuelve mantenible.

Como todo es modular, puede probar partes de este de forma aislada. Su código es comprobable y es menos probable que albergue errores o agujeros de seguridad. Las actualizaciones futuras serán mucho más fáciles, ya que podrá probar fácilmente todo el sistema.