bank kata kotlin
1.0.0
He practicado el banco Kata de Sandro Mancuso
Mis objetivos donde practicar una mezcla de la mezcla de TDD de TDD (una idea de Manuel Rivero)
Haciendo un seguimiento del tiempo usando Git Commits.
He implementado la función de transferencias seguras: la cuenta se puede configurar para solicitar un código (p. Ej.
He investigado formas de conservar las propiedades ácidas, en lugar de elegir un sistema eventualmente consistente.
Como parámetros de la clase de cuenta: código
Este es el enfoque más simple: depende del tipo de parámetro para decidir el comportamiento de la clase.
Como una máquina de estado: código
Configure los estados y las transiciones como una parte interna/externa de la clase de transferencia, lo que lo hace más genérico y a prueba de futuro (¿YAGNI?)
Esto se puede representar utilizando la herencia de una clase común (en este caso, transferencia) o utilizando un envoltorio (estado <>) para significar el estado actual. Para el primero, está el código de producción. Para este último, una étuda lateral que implementa una biblioteca de máquinas de estado (usando un automóvil + su fábrica como dominio)
En la implementación, es menos seguro de tipo, menos cómodo trabajar con esta implementación, ya que las firmas de método son bastante ambiguas: cualquier estado es representable bajo el objeto de transferencia.
Como o (es decir, cálculo fallido): código
O le permite representar dos resultados de cálculo explícitos. La izquierda se ha utilizado para significar la transferencia bloqueada/segura y la derecha para significar la transferencia desbloqueada.
Esto solo permite representar dos valores, de manera implícita: el consenso del equipo indica izquierda y derecha para estos significados.
Además, es estacionario ver un Either<T,T> donde ambas T son iguales. Es posible que esto sea causado por tener la máquina de estado implícitamente (heredar de una clase común) + la.
Como thunks (es decir, cálculos retrasados): código
Se ha pasado un Thunk como parámetro y ejecutado cuando es necesario. Este sistema no permite una fácil persistencia/almacenamiento, ya que las funciones no se pueden serializar/deserializar.
Como flujo de trabajo (es decir, un conjunto de pasos predefinidos): [código] [https://github.com/alvarogarcia7/bank-kata-kotlin/tree/variant/control-safe-transfers-as-workflow]
Este flujo de trabajo tiene un conjunto de pasos (que pueden validarse o no), y al final hay un conjunto de acciones.
Según la forma en que se ha implementado (solo se pasan los datos, pero no el comportamiento), esto podría ser serializado / expuesto sobre reposo.
f log --format="%s;%ct"|grep CLOCK|cut -d";" -f1 da los mensajes f log --format="%s;%ct"|grep CLOCK|cut -d";" -f2 da los tiempos en milis
Luego copie a una hoja de cálculo y calcule la diferencia cuando se detenga
