Quem eu sou
Os exemplos deste site dizem mais do que uma lista de qualidades. Aqui estão alguns padrões de como abordo o trabalho.
↳ geralmente começa por quem controla os dadosNa Dynamox, trabalho em ferramentas para inspeção industrial. Uma mudança pode passar pela tela usada por quem faz a inspeção, pela API por trás dela e por cópias dos mesmos dados em outros serviços. Tento entender esse caminho inteiro antes de decidir onde corrigir o problema.
Às vezes, o trabalho começa com uma decisão de arquitetura; em outras, com um relato de que um número parece errado. Nos dois casos, testo minha explicação contra o comportamento do sistema e deixo os trade-offs claros para que outras pessoas possam questioná-los.
Quando vários serviços guardam versões do mesmo dado, a pergunta difícil é qual deles pode alterá-lo e como os outros recebem a mudança. Uma regra clara nesse limite evita muitos casos especiais depois.
Registro as alternativas e os motivos da decisão. Assim, o time pode revisar o raciocínio, voltar a ele mais tarde ou usá-lo quando surgir um problema parecido.
- —Acompanhar uma mudança de dados por interfaces, APIs, consumers e tabelas
- —Encontrar onde uma regra compartilhada deve ficar entre serviços
- —Construir fluxos de frontend junto das APIs e dos modelos de dados por trás deles
- —Escrever decisões para que o time possa revisar o raciocínio, não só a conclusão
- —Levar uma funcionalidade da definição do problema até a implantação
- —Um valor que muda dependendo do serviço ou da tela em que é consultado
- —Uma funcionalidade útil que fica lenta por causa de dados espalhados em uma hierarquia grande
- —Uma divergência em produção cuja primeira explicação não bate com as evidências
- —Um fluxo que precisa continuar funcionando quando uma requisição ou mensagem falha no meio do caminho