SI. No solo sí, sino que debería serlo.
Mis ilustraciones serán simplistas y a los puristas no les gustaría. Pero lo que me preocupa?
Diseño y desarrollo impulsado por el comportamiento : en este momento, esta frase parece demasiado libre y liberalmente definida. Te diré lo que debería ser.
- ¿Qué tecnologías utiliza wayfair.com?
- ¿Qué distingue a los mejores arquitectos de software de los mediocres?
- ¿Qué temas en ciencias de la computación son más importantes para un aspirante a ingeniero de software?
- ¿Dónde puedo obtener software crackeado que sea seguro de usar o cómo puedo ejecutarlo de manera segura?
- ¿Crees que hay un código que nunca debería escribirse? Si es así, ¿cuál sería y por qué?
- Comienza por realizar un análisis situacional de cómo desea que se comporte su aplicación.
- Luego, realiza un análisis situacional de cómo deben comportarse otros recursos que interactúan con su aplicación.
- Y luego se compromete la forma en que los recursos existentes están obligados a comportarse, porque no debe perder el tiempo cambiando esos recursos.
- Luego realiza un análisis de todos los posibles comportamientos y comportamientos esperados sistémicos y humanos.
- Luego, especifica salvaguardas para erigir para excepcionalizar, mitigar o evitar el mal comportamiento de clientes o recursos. La evitación podría incluir la eliminación o el respeto de una función.
- Debe descubrir todas las conductas ridículas en las que los clientes interactuarán con su aplicación, ya que necesita idear una reacción aversiva, mitigante o prohibitiva a esas conductas ridículas de los clientes.
- En un entorno ágil, comienzas pequeño, manejable, desarrollable y codificable.
- Debido a que es un entorno ágil, se le permite tener objetivos en movimiento.
- Los objetivos móviles son buenos y virtuosos porque la economía mundial y, por lo tanto, las especificaciones y la base de usuarios y los recursos en sí mismos son objetivos móviles inestables.
- Creer que un diseño no debería ser un objetivo móvil es una ilusión.
- Especialmente cierto son los comportamientos desconocidos o inesperados de los recursos y usuarios. Esos son verdaderos objetivos móviles.
- Es bastante imposible comprender completamente las interacciones y el comportamiento de los usuarios y los recursos porque son objetivos inherentemente móviles.
Esto puede parecer que tiene muchos pasos, pero debido a que comenzó con pequeños pasos y los itera gradualmente para hacer crecer su aplicación gradualmente, podrá visualizar cómo funciona su aplicación.
Conozca a los actores y recursos.
Una vez que haya entendido los comportamientos e interacciones requeridos, esperados e inesperados entre los recursos con su aplicación, debe dibujar círculos que representen cada bloque de clientes, recursos o sistema existente. Esos son sus actores y recursos.
Y luego trazas líneas para cada una de las interacciones entre los actores / recursos. Ahora tiene una visualización completa y completa de los sistemas involucrados y de lo que interactúan. El siguiente es un esquema simplista de su aplicación.
Sepa cómo interactúan .
Después de saber lo que interactúan, debes saber cómo interactúan. Ahora transforma los círculos en palos verticales. El siguiente es el mismo shtick pero especificando la secuencia. La dirección del tiempo fluye hacia abajo.
A partir del diagrama de secuencia, tal vez se dé cuenta de que necesita un proceso intermedio para desacoplar el presentador del CRM, e inserte ese proceso en el diagrama del sistema anterior, así como en el diagrama de secuencia. Es compulsivamente un buen hábito no hacer que su proceso de presentación se moleste con cosas de back-end.
La API
Digamos que estás atrapado con el diseño original. Desde el diagrama de secuencia, ahora sabe que su CRM necesita estas dos funciones
- Bill getBill (suscriptor)
- Ack registrarse (pago)
Sabes que tu presentador necesita la API
- Inicio de factura (suscriptor)
- Ack post (pago)
Ahora puede comenzar a escribir código para la interfaz CRM, independientemente del suscriptor y el presentador. Del mismo modo, el presentador de facturación se puede escribir de forma independiente. Y luego puede escribir pruebas para probar cada una de ellas de forma independiente.
“Conducido por prueba”
Probar independientemente es algo que naturalmente desea hacer, para descubrir si las funciones responden según lo deseado. Las pruebas unitarias son tan simples como eso.
Ni siquiera debería llamarse Test-Driven Development (TDD). Debería llamarse Desarrollo Motivado por Pruebas (TMD) debido a su inclinación inherente a descubrir, pieza por pieza, qué es lo que están haciendo esos intrusos. Las personas contra TDD y las personas contra TDD están haciendo que parezca demasiado complicado.
Te entrevistan y te preguntan “¿Sabes cómo hacer TDD?”
Pregunta incorrecta contratar gerentes. No hay nada complicado en el desarrollo impulsado por pruebas / motivado. NO le desfavorezca a la ingeniería de software haciendo preguntas tan tontas y grandiosas.
La pregunta real es “¿Eres discapacitado sin TMD?”
La pregunta debería ser: “¿Sabe cómo diseñar y visualizar su aplicación en términos de secuencias de funciones y API de funciones?” Porque una vez que un programador hace eso, sería una inclinación natural para un programador caer en la tentación de la unidad. prueba cada función mientras las desarrollas. Tendrías que ponerles un arma en la cabeza para decirles que no escriban pruebas unitarias.
Si los programadores no realizan pruebas unitarias, es su culpa. Tú, la culpa del arquitecto. Debe ayudar a sus programadores a visualizar la API y el flujo del proceso, de modo que se vayan a dormir por la noche visualizando lo que hay detrás de esas API.
La máquina de estados
La máquina de estados es el concepto más esencial, poderoso y confiable en el diseño de una aplicación. La máquina de estado permite que su aplicación funcione en modo de complementos. La tabla de máquinas estatales es como la tabla de tarifas de peaje Turnpike del estado de Nueva Jersey. Cada punto de entrada en la tabla es un estado .
- Tiene un punto de entrada y desea llegar a otro punto de entrada en su aplicación. ¿Cuál es la tarifa que debe pagar? ¿Cuál es el evento que debe suceder?
- ¿Cuál es la secuencia de eventos que deben ocurrir si no hay rutas directas de un punto de entrada al punto de entrada deseado?
State Turnpike es el mecanismo que demuele todas las excusas para tener una programación else-if , eliminará la mayoría del código if-then-else .
La tabla State Turnpike enumerará exhaustivamente todos los posibles estados en los que podría estar su página.
El guión gráfico amarillo-pegajoso:
Transformado en State Turnpike:
Estado de origen> Evento> Estado de destino
- Ahora su equipo tiene una base para discutir sobre el comportamiento de la página.
- Ahora tiene controladores de eventos para cada evento.
- Ahora tiene un Mapa de controladores.
- Ahora puede tener Spring util para inyectar controladores en su Mapa.
- Ahora no tiene que luchar con if-then-else, porque cada vez que discute y cambia de opinión, simplemente actualiza su configuración de Spring para esa página. O inyectar nuevos controladores.
Así es: cambie las reglas de su negocio sin tener que lidiar con una sola línea de if-then-else .
@Recurso
Map eventStateHandlerMap;
/ ****************************
* ¡Mira mamá, no si-entonces-más!
**************************** /
UiPageState protegido invokeNextState (UiPageEvent uiPageEvent) {
return eventStateHandlerMap.get (uiPageEvent);
}
La jerarquía de máquinas de estado
Como puede ver, con la máquina de estado anterior documenté solo una página de IU de las muchas páginas de una aplicación. Sin embargo, en un nivel más alto del árbol de navegación, puede tener una máquina de estado de máquinas de estado, con un Mapa de navegadores de página para administrar la navegación de la página UI a la página UI.
Las máquinas de estado se pueden usar más allá de las páginas de la interfaz de usuario. Se deben aprovechar todas las posibilidades para transformar una aplicación en una máquina de estado.
Este es el patrón sin sentido y casi sin otro conocido como el Patrón de máquina de estado.
Patrón de Petri Net-ish
Una técnica de simplificación más compleja es utilizar el análisis de red de Petri para gestionar la concurrencia. ¿Complejo pero simplificador?
Complejo porque ahora tienes que entender los principios detrás de las redes de petri. Redes de petri. Las redes de Petri son la secuencia de disparo de eventos en un entorno de concurrencia altamente no determinista.
Simplificando porque ahora, puedes visualizar las condiciones de carrera y controlarlas.
Ha pasado algún tiempo desde que hice redes de petri, disculpas. Necesito revisarlo.
Patrón funcional
Para mantener su arquitectura altamente visualizable, modificable y mantenible, su API debe ser lo más funcional posible.
Permítanme fabricar mis propias opiniones sobre qué API funcional es. Es funcional cuando
- Se ajusta al principio del lugar correcto, el momento correcto y el herramental correcto.
- p.ej. una función de presentación de IU no realiza el acceso a la base de datos.
- por ejemplo, un controlador de impresora no realiza el acceso de telefonía.
- Una función debe tener una y solo una función. No desea agrupar muchas funciones en una sola función. Una forma de controlar eso es darse cuenta de que cada vez que su código tiene más de tres niveles de sangría, está en peligro.
- Tu función debe ser apátrida. Con los mismos argumentos ejecutados nuevamente, la respuesta no debería ser diferente cada vez. Deje que la máquina de estado (o redes de Petri) maneje las transiciones de estado.
De esta manera, tendría una idea clara y visual de lo que hace su API.
Normalización del modelo de datos
He visto que los servicios web y el esquema de objetos de transporte de datos están “diseñados” sin un plan en el que los modelos de datos se superpongan.
Uno no solo necesita normalizar la información del repositorio, sino también los DTO y DAO. Los modelos de datos normalizados le permiten desacoplar las funciones de los modelos de datos. Un modelo de datos debe tener una función y solo para esa función.
De tal manera, ahora tendría una imagen clara y visualizable para qué sirve un modelo de datos. Muchos procesos pueden usar un modelo de datos, pero debe definir cuál es la función de la información que transporta. No puede tener más de una función de transporte de información para un modelo de datos.
Ahora puede imaginar en su cabeza, mientras se duerme por la noche (o tal vez mientras programa en el trabajo) con los modelos de datos que fluyen por su mente mientras imagina el flujo de información de su arquitectura.