bank kata kotlin

Banco Kata

Eu pratiquei o banco kata por Sandro Mancuso

Meus objetivos onde praticar uma mistura de mix de TDD externo-in + Classicist (uma ideia de Manuel Rivero)

Mantendo o controle do tempo usando o GIT Comets.

Opinião

• A capacidade de refatorar sem quebrar os testes é muito boa, satisfatória mesmo
• Testes nos quase-limites não cobre todos os casos, mas é um passo na boa direção

Notas de desenvolvimento

Variantes para transferências seguras (ácido)

Eu implementei o recurso de transferências seguras: a conta pode ser configurada para solicitar um código (por exemplo, OTP) para verificar a transferência de fio, ambos de saída (por exemplo, a maioria dos bancos tem isso) como recebendo.

Investigei maneiras de economizar as propriedades do ácido, em vez de escolher um sistema eventualmente consistente.

Parâmetros

Como parâmetros da classe de conta: código

Essa é a abordagem mais simples: depende do tipo de parâmetro para decidir o comportamento da classe.

Máquina de Estado

Como uma máquina de estado: código

Configure os estados e as transições como uma parte interna/externa da classe de transferência, tornando-a mais genérica e à prova de futuro (Yagni?)

Isso pode ser representado usando a herança de uma classe comum (neste caso, transferência) ou usando um wrapper (estado <>) para significar o estado atual. Para o primeiro, há o código de produção. Para o último, um lado é que implementa uma biblioteca de máquinas estaduais (usando um carro + sua fábrica como domínio)

Na implementação, é menos seguro, menos confortável trabalhar com essa implementação, pois as assinaturas de método são bastante ambíguas: qualquer estado é representável sob o objeto de transferência.

Qualquer

Como (ou seja, falha na computação): código

Ou permite que você represente dois resultados explícitos de computação. A esquerda foi usada para significar transferência bloqueada/segura e a direita para significar transferência desbloqueada.

Isso permite apenas representar dois valores, de maneira implícita: o consenso da equipe indica a esquerda e a direita para esses significados.

Além disso, é estrondo ver um Either<T,T> onde os T são os mesmos. É possível que isso seja causado por ter a máquina de estado implicitamente (herdando de uma classe comum) + a.

Thunks

Como Thunks (ou seja, cálculos atrasados): código

Um Thunk foi passado como um parâmetro e executado quando necessário. Este sistema não permite uma persistência/armazenamento fácil, pois as funções não podem ser serializadas/desserializadas.

Fluxo de trabalho

Como um fluxo de trabalho (ou seja, um conjunto de etapas predefinidas): [Code] [https://github.com/alvararcarcia7/bank-kata-kotlin/tree/variant/control-safe-transfers-sworkflow]

Este fluxo de trabalho tem um conjunto de etapas (que podem ser validadas ou não) e, no final, há um conjunto de ações.

Com base na maneira como foi implementada (apenas os dados são transmitidos, mas não no comportamento), isso pode ser serializado / exposto ao descanso.

Relógio

f log --format="%s;%ct"|grep CLOCK|cut -d";" -f1 fornece as mensagens f log --format="%s;%ct"|grep CLOCK|cut -d";" -f2 dá os tempos em milis

Em seguida, copie para uma planilha e calcule a diferença quando é parada