design - significado - ¿Es factible el desarrollo de software no programático?
implementing domain driven design español (16)
Actualmente me enfrento a un problema de diseño muy inusual, y espero que un desarrollador más inteligente que yo pueda ofrecer alguna idea.
Fondo
Sin ser demasiado específico, una organización sin fines de lucro me ha contratado para ayudar con el redesarrollo de su software heredado, pero muy valioso (en términos de valor social). El equipo de desarrollo no se parece a ninguno de los que he encontrado en mi época como desarrollador de software, y está compuesto por un pequeño número de desarrolladores y un grupo más grande de expertos de dominio que no son de programación. Lo que hace que el arreglo sea inusual es que los expertos de dominio (llamémosles creadores de contenido), utilicen herramientas personalizadas, algunas de las cuales se basan en un motor de sistema experto en prólogos, para desarrollar componentes / formularios de software basados en la web.
El problema
El sistema utiliza un modelo de devolución de datos muy incómodo para realizar operaciones lógicas del lado del servidor y devolver nuevas formas / resultados. Es lento y propenso al fracaso. Cosas simples, como crear formularios html utilizando las herramientas existentes, es mucho más arduo de lo que debería ser. A medida que crece la demanda de una experiencia más interactiva y de mayor rendimiento, los desarrolladores de software encuentran cada vez más que tienen que eludir el sistema experto / herramientas visuales utilizadas por los creadores de contenido y escribir nuevos componentes a mano en javascript. Los creadores de contenido sienten cada vez más que sus manos están atadas, ya que ahora no pueden contribuir con nuevos componentes.
Enfoque de diseño: tradicional / típico
He estado abogando por el abandono total del modelo anterior y la adopción de un proceso típico de desarrollo de software. Como se mencionó anteriormente, el proyecto ha evolucionado naturalmente hacia esto ya que las herramientas de desarrollo no programáticas se han vuelto incapaces de satisfacer las necesidades del negocio.
Sin embargo, los creadores de contenido tienen una contribución muy valiosa que hacer, y me gustaría que se centren en especificar formalmente el comportamiento esperado del software con herramientas como Cucumber, en lugar de involucrarse en la implementación.
Enfoque de diseño: no programático
Mi compañero de trabajo, a quien respeto mucho y sospecho que tiene mucho más conocimiento que yo, siente que el proceso existente está bien y que solo necesitamos construir mejores herramientas. Sin embargo, no puedo evitar sentir que hay algo fundamentalmente defectuoso con este enfoque. Todavía tengo que encontrar una instancia, histórica o contemporánea, en la que este modelo de desarrollo de software haya tenido éxito. COBOL fue desarrollado con la filosofía de permitir a los expertos en negocios / dominio escribir aplicaciones sin la necesidad de un programador, y en mi opinión todo lo que hizo fue crear un nuevo tipo de programador: el programador COBOL. Si fuera posible desarrollar sistemas efectivos que permitan a los no programadores crear aplicaciones no triviales, seguramente la demanda de programadores sería mucho menor. Los únicos marcos de los que tengo conocimiento que se ajustan a este modelo son los Smart Forms de SAP y Dynamix AX de Microsoft, ambos sistemas ERP muy específicos de cada dominio.
DSL, lenguajes de prueba
Algo de compromiso entre los dos conceptos sería implementar algún tipo de DSL como lenguaje de plantillas. Sin embargo, ni siquiera estoy seguro de que esto sea exitoso, ya que todos los creadores de contenido, con una excepción, son completamente no técnicos.
También consideré crear un IDE personalizado basado en Visual Studio o Net Beans con herramientas de estilo gráfico / de caja de herramientas.
¿Pensamientos?
¿El desarrollo no programático es una misión tonta? ¿Esto siempre dará como resultado algo insatisfactorio, que requiera el desarrollo práctico de un programador?
Muchas gracias si se han tomado el tiempo de leer esto, y ciertamente agradecería cualquier comentario.
... Cosas simples, como crear formularios html utilizando las herramientas existentes es mucho más arduo de lo que debería ser ...
Más arduo para quién? ¿Estás tomando un modelo de desarrollo que funciona (sin importar lo mal) para los creadores de contenido que no son de programación, y porque algo es arduo para alguien a quien propones reemplazarlo con un modelo donde los creadores de contenido se quedan totalmente aislados? Me parece una locura
Si los creadores de contenido pueden aprender herramientas personalizadas basadas en un motor de reglas de Prolog, entonces han demostrado que pueden aprender suficiente formalismo para contribuir al proyecto. Si cree que se deben cambiar otros aspectos del desarrollo, solo veo dos opciones honorables:
Implemente el formalismo existente ("herramientas personalizadas") utilizando la nueva tecnología que cree que mejorará las cosas de otras maneras. Los creadores de contenido contribuyen exactamente como lo hacen ahora.
Diseñe e implemente un lenguaje específico de dominio que maneje el desajuste de impedancia entre lo que sus creadores de contenido saben y lo que pueden hacer, y la forma en que usted y otros desarrolladores creen que el trabajo debe realizarse.
Su escenario es un caso clásico en el que un lenguaje específico de dominio es apropiado. Pero el diseño del lenguaje no es fácil, especialmente cuando se combina con preguntas serias de usabilidad. Si tiene suerte, podrá contratar a alguien para que lo ayude, ya que es experto tanto en el diseño del lenguaje como en la facilidad de uso. Pero si no tiene fines de lucro, probablemente no tenga el presupuesto. En este caso, una posibilidad es buscar ayuda de otra organización sin fines de lucro, una universidad cercana, si tiene una.
Actualmente estoy luchando con un problema similar al tratar de permitir que los proveedores de atención médica escriban reglas para los flujos de trabajo, lo cual no es fácil porque no son programadores. No eres programador porque fuiste a la escuela de programación, eres un programador porque piensas como un programador. Afortunadamente, la mayoría de los hospitales tienen algún anestesiólogo o ingeniero biomédico que piensa como un programador y puede lograr programar. La clave es darles a los programadores que no son programadores-que-piensan-como-un lenguaje que puedan aprender y dominar.
En mi caso, quiero que los médicos puedan formular reglas simples, tales como: "Si la temperatura de un paciente es demasiado baja, envíele un mensaje de texto a su médico". Por supuesto, es más complicado que eso porque la definición de "demasiado bajo" depende de la edad del paciente, un paciente puede tener muchos médicos, y así sucesivamente, pero un médico inteligente podrá descifrar esas reglas. El verdadero problema es que el sensor de temperatura a menudo caerá del paciente y leerá la temperatura ambiente, lo que significa que la regla es inútil a menos que pueda averiguar cómo determinar que el termómetro realmente está leyendo la temperatura del paciente.
El gran problema que tengo es que, aunque es relativamente fácil crear una DSL para que los médicos puedan expresar IF [temperature] [less-than] [lookup-table [age]] THEN [send-text-message] , es mucho más difícil para crear uno que pueda expresar todas las heurísticas diferentes que pueda necesitar probar antes de llegar al modo correcto para asegurarse de que la lectura sea válida.
En su caso, es posible que desee considerar cómo VB se hizo popular: tiene una herramienta de dibujo de formularios que cualquiera puede usar fácilmente para dibujar formularios y establecer propiedades en los elementos del formulario. Como no todo se puede especificar mediante propiedades de formulario y enlace de datos, hay un modo de código subyacente que le permite hacer una lógica compleja. Pero para hacer que la herramienta sea accesible para los programadores principiantes, el lenguaje es BÁSICO, por lo que los usuarios no tienen que aprender sobre punteros, asignación de memoria o estructuras de datos.
Si bien es probable que no desee dar a sus usuarios VB, podría considerar un enfoque híbrido. Tendría un "lenguaje" (podría ser gráfico, como el diseñador de formularios de VB o Labview) donde los usuarios inexpertos pueden hacer las cosas simples fácilmente, y otro idioma para permitir que los usuarios expertos hagan las cosas complicadas.
Creo que el desarrollo de los no desarrolladores está condenado al fracaso. Ya es bastante difícil cuando los desarrolladores lo prueban. ¿Cuál es la tasa de fallas? 50% o más?
Mi consejo sería comprar el producto comercial más cercano que pueda encontrar o contratar a alguien para que lo ayude a desarrollar una solución personalizada teniendo en cuenta las características de mantenimiento que no son desarrolladores.
Ser desarrollador significa tener en cuenta un millón de detalles a la vez y preocuparse por detalles como el control de versiones, la implementación, las pruebas, etc. La mayoría de las personas a las que no les importan esas cosas rápidamente se cansan de la complejidad.
Por supuesto, involucrar a los expertos del dominio. Pero no los ensille con desarrollo y mantenimiento también.
Podría poner a su organización en riesgo con una solución mal hecha. Si es importante, hazlo bien.
El desarrollo de software no programático es factible, siempre que sea realista acerca de lo que los no desarrolladores pueden lograr de manera razonable, se trata de un compromiso entre la capacidad y la facilidad de uso.
La clave es desglosar los requisitos de manera limpia en cosas que los expertos de dominio deben poder hacer, y dedicar tiempo a implementar esas características de una manera infalible: el error clásico es intentar que el sistema haga demasiado.
Por ejemplo, supongamos que desea que los expertos en el dominio puedan crear un formulario con una entrada de texto enmascarada:
- La mayoría de los desarrolladores verán ese requisito y crearán un control sofisticado que aceptará algún tipo de expresión regular y permitirá al experto en el dominio hacer cualquier cosa .
Esta es la forma clásica de desarrollador de ver las cosas, sin embargo, es probable que el experto de su dominio no comprenda las expresiones regulares y el desarrollador haya olvidado el requisito del experto de dominio para poder crear este formulario.
- Una mejor solución podría haber sido crear un control que pueda confgurarse para enmascarar las direcciones de correo electrónico o los números de teléfono.
Sí, este control es mucho menos capaz que el primer control, y sí, los expertos del dominio deben pedir a los desarrolladores que lo extiendan cuando quieran poder enmascarar los números de registro del automóvil, sin embargo, los expertos del dominio pueden usarlo.
En general, sin embargo, 2 pensamientos:
No puedes reducir la vida a los algoritmos. Todo lo que sabemos (filosóficamente, científicamente) y la experiencia lo demuestran. (Lo siento, Dr. Minsky).
Dicho esto, una herramienta específica de dominio que permite a los no programadores expresar un lenguaje finito es definitivamente factible ya que varias personas han dado ejemplos. Otro ejemplo de este tipo de sistema es Mathematica y, especialmente, Simulink, que se utilizan con gran éxito en una amplia gama de aplicaciones. Sin embargo, el fracaso de Expert Systems, Fuzzy logic y Japan''s Fifth Generation, proyecto de computadora de los años 80 para despegar, demuestra la dificultad de hacer esto.
Este es un tema bastante filosófico y difícil de responder para cada caso, pero en general ...
¿El desarrollo no programático es una misión tonta?
Fuera de un alcance muy estrecho, sí. Los principales proveedores de software han invertido miles de millones a lo largo de los años en la creación de varios paquetes para intentar que los usuarios no técnicos creen y definan flujos de trabajo y procesos con un éxito limitado. Su mejor opción es aprovechar lo que se ha hecho en ese espacio en lugar de tratar de reinventarlo.
Editar : Sharepoint, InfoPath, algunas cosas de SAP son los ejemplos de los que estoy hablando. Como dije antes, "un alcance muy estrecho". Es posible permitir que los no programadores creen flujos de trabajo, formas complejas, algunos procesos de dominio, pero eso es todo. Cualquier cosa más general es simplemente tratar de convertir a los no programadores en programadores dándoles herramientas muy crudas.
Estoy de acuerdo con usted: las personas no técnicas no podrán programar nada que no sea trivial .
Algunos productos intentan crear lo que es básicamente un lenguaje de programación realmente simple. El problema es que la programación es tanto una aptitud como una habilidad. Se necesita un cierto tipo de mentalidad para pensar en el tipo de lógica utilizada por las computadoras, que simplemente no puede ser abstraída por ningún lenguaje de programación (al menos no sin hacer suposiciones que no puede hacer con seguridad).
Lo he visto en acción con empresarios que intentan crear flujos de trabajo en MS Dynamics CRM. A pesar de que el producto estaba claramente destinado a permitirles hacerlo sin un programador, simplemente no pudieron encontrar la manera de hacer funcionar un bucle o una condición if-else, sin importar cuán "amigable" fuera la UI. Miré con asombro mientras luchaban con algo que parecía completamente obvio para mí. Después de un día completo (!) De esto, lograron producir un par de flujos de trabajo muy básicos que funcionaron en algunos casos, pero no manejaron casos extremos como valores perdidos o datos no válidos. Básicamente fue una completa pérdida de tiempo.
De acuerdo, Dynamics CRM no es exactamente el epítome de la facilidad de uso, pero vi lo suficiente como para convencerme de que esto es, de hecho, un mandado tonto.
Ahora, si sus usuarios no son programadores, pero aún son personas técnicas , podrían aprender programación, pero esa es otra historia: realmente se han convertido en "nuevos programadores" y no en "no programadores".
Las compañías de juegos de computadora operan así todo el tiempo, hasta donde puedo decir: unos pocos programadores y muchos creadores de contenido que también necesitan poder controlar la lógica (como los diseñadores de niveles).
También es probablemente una disciplina saludable poder separar tu código de los datos y las reglas que lo impulsan si puedes.
Estoy, por lo tanto, con su colega, pero, por supuesto, ¡los detalles no pueden hacer que esta solución general sea apropiada!
No creo que ninguna solución extensa no programadora vaya a funcionar. La programación es más que lenguaje, es saber cómo hacer las cosas razonablemente. Algo diseñado para ser no amigable con los programadores casi seguro que contiene todas las trampas que un programador sabe evitar incluso si está expresado en inglés o en una GUI.
Creo que lo que se necesita en un caso como este es hacer que los creadores de contenido se preocupen por crear contenido y un programador real lo traduzca en un código informático razonable.
He trabajado con dos sistemas ERP diseñados para no programadores y en ambos casos puedes hacer con ellos casi todos los errores del libro.
Parece que el problema es de naturaleza organizacional y no puede resolverse solo por medios técnicos.
La raíz es que los creadores de contenido son completamente no técnicos, pero tienen que realizar tareas inherentemente técnicas de diseño de formularios y redacción de reglas de Prolog. Varios diseñadores y DSL pueden aliviar sus problemas, pero nunca los resuelven.
O bien reorganice el sistema y los procesos para que los portadores de conocimiento ingresen el conocimiento, nada más; o capacitar a creadores de contenido para realizar el desarrollo necesario con las herramientas existentes o pueden ser DSL.
El desarrollo no programático puede salvarse de los quehaceres de bajo nivel, pero esforzarse por configurar el sistema una vez y permitir que los usuarios lo expandan indefinidamente y sin restricciones es sin duda una tontería.
Piense en hojas de cálculo.
Las hojas de cálculo son un sistema simple que permite a los usuarios no técnicos hacer uso de las capacidades de cálculo de una computadora. Al hacerlo, han abierto computadoras para resolver una gran cantidad de tareas que normalmente requerirían un software personalizado desarrollado para resolverlas. Entonces, sí, el desarrollo de software no programático es posible.
Por otro lado, mira las hojas de cálculo. A pesar de sus habilidades de cálculo, realmente no querrás que un programador tenga que desarrollar software con ellos. Al final, muchas de las técnicas que hacen que los lenguajes de programación sean mejores para los programadores los empeoran para la población en general. La capacidad de definir una función, por ejemplo, hace que la vida de un programador sea mucho más fácil, pero creo que podría confundir a la mayoría de los demás.
Además, pasar un cierto punto de complejidad tratando de usar una hoja de cálculo sería un verdadero dolor. La hoja de cálculo funciona bien dentro del dominio para el que fue diseñada. Una vez que te alejas demasiado de eso, simplemente no es viable. Y nuevamente, son las mismas herramientas que usan los programadores para lidiar con la complejidad lo que evitará que un sistema sea ampliamente utilizable y suficientemente poderoso.
Creo que para cualquier área problemática dada, podría desarrollar un sistema que permita a los expertos especificar una solución. En primer lugar, será mucho más difícil desarrollar ese sistema para resolver el problema. Sin embargo, si repetidamente tiene problemas similares para los cuales los expertos pueden desarrollar soluciones, entonces podría valer la pena.
Que problema tan interesante
En última instancia, tendría que estar de acuerdo contigo y no estar de acuerdo con tu colega.
La filosofía y el enfoque del Desarrollo / Diseño Dirigido por Dominio existe exactamente para sus propósitos, en el sentido de que le da la máxima importancia al conocimiento específico de los expertos en el dominio con experiencia, y en la comunicación de ese conocimiento a los desarrolladores de software con talento.
Mira, en tu problema, hay dos cosas distintas. El dominio y el software. El dominio debe ser entendido y especificado antes que nada sin el desarrollo de software en mente.
Y luego la transformación al software ocurre entre la comunicación entre expertos de dominio y programadores.
Creo que tratar de construir herramientas de "programación" para expertos de dominio es una pérdida de tiempo.
En Domain Driven Development, los expertos de tu dominio seguirán siendo importantes y obtendrás un mejor software.
En el enfoque de su colega, está tratando de reemplazar a los programadores con una herramienta ... tal vez en el futuro, como comenzar el futuro, eso sea posible, pero hoy no lo creo.
Te aconsejo que leas este artículo antes de intentar eliminar todo el sistema. Lo veo de esta manera. ¿Qué cambió para impulsar la reurbanización? Los expertos de su dominio no han olvidado cómo usar el sistema original, por lo que ya tiene algunos "programadores COBOL" competentes para su dominio. Según su descripción, parece que han cambiado los requisitos de rendimiento y, posiblemente, una mayor necesidad de formularios web.
Por lo tanto, la solución deseada no es cambiar las responsabilidades de los expertos de dominio, sino aumentar el rendimiento y facilitar la creación de formularios web. Usted tiene la ventaja de una base de código existente que muestra exactamente lo que los expertos de su dominio son capaces de hacer. Sería una verdadera lástima no usarlo.
Me doy cuenta de que Prolog no es exactamente el lenguaje más popular, pero hay implementaciones más rápidas y lentas. Algunas implementaciones están diseñadas principalmente para la interactividad del programador y se interpretan dinámicamente. Algunas implementaciones crean código nativo compilado optimizado. También existen complejas técnicas de programación lógica, como la memorización, que pueden usarse para mejorar el rendimiento, pero probablemente ya nadie las aprenda en la escuela. Un flujo en el que los creadores de contenido se centran en la creación de contenido nuevo y los desarrolladores se centran en la optimización podría ser muy viable. Además, Prolog es ideal para la capa de modelo, pero no tanto para la capa de visualización. Mover más de su capa de vista a una tecnología diferente realmente podría dar sus frutos.
Tu dices:
Algo de compromiso entre los dos conceptos sería implementar algún tipo de DSL como lenguaje de plantillas. Sin embargo, ni siquiera estoy seguro de que esto sea exitoso, ya que todos los creadores de contenido, con una excepción, son completamente no técnicos.
Honestamente, esto suena exactamente como el enfoque que usaría. Incluso los usuarios "no técnicos" pueden llegar a ser competentes (suficiente) en un DSL simple o lenguaje de plantillas para realizar un trabajo útil.
Por ejemplo, trabajo mucho con el software de modelado científico. Muchos modeladores, aunque se sienten mucho más a gusto con la ciencia que con cualquier otra forma de ingeniería, se han visto forzados a aprender uno o más lenguajes de programación para poder expresar sus ideas de una manera que puedan usar. Diablos, hasta donde yo sé, Fortran sigue siendo un curso requerido para obtener un título de Meteorología, ya que todos los principales modelos meteorológicos actualmente en uso están escritos en Fortran.
Como resultado, existe una cierta comunidad de "programación científica" que está mayormente llena de expertos en el dominio con relativamente poca capacitación formal en ingeniería de software, experiencia o incluso interés. Estas personas se sienten más a gusto con idiomas / plataformas como Matlab, R e incluso con Visual Basic (ya que pueden usarlo para aplicaciones de script como Excel y ESRI ArcMap). Recientemente, he visto a Python ganando terreno en este espacio también, principalmente porque creo que es relativamente fácil de aprender.
Supongo que mi punto es que veo fuertes paralelismos entre este campo y tu ejemplo. Si los expertos de su dominio son capaces de pensar rigurosamente sobre sus problemas (y este puede no ser el caso, pero su pregunta es lo suficientemente abierta como para serlo), entonces definitivamente son capaces de expresar sus ideas en un lenguaje específico de dominio apropiado. .
Comenzaré discutiendo con los creadores de contenido algunas ideas sobre cómo les gustaría expresar sus decisiones y elecciones. Supongo que les gustaría escribir "código" (incluso si no tiene que llamarlo código) para describir lo que quieren. Deles un "depurador" (una herramienta para explorar interactivamente las consecuencias de sus cambios de "código") y una buena aplicación de soporte "IDE", y creo que tendrán una solución muy viable.
Tuve esto como un comentario anterior, pero pensé que merecía más mérito.
Definitivamente hay una serie de herramientas exitosas "no programáticas", de mano puedo pensar en Labview , VPL y en gráficos (edite: acabo de notar que este enlace tiene más que sombreadores) sombreadores que prevalecen en Aplicaciones 3D
Una vez dicho esto, no conozco ninguno que sea adecuado para el desarrollo basado en web (que parece ser su caso).
Digo mucho que la inversión en el desarrollo de tales herramientas valdría la pena (a menos que tal vez podría pasar a venderlo como un producto también).
Labview es un entorno de programación no programático muy exitoso.