Canônico

Aqui pensando em gramática e jeito de escrever o que fazemos em software.

Em desenvolvimento de software escrever com padrão sempre foi algo importante e diria que quase obrigatório para uma equipe com pensamento de longo prazo.

Em diferentes aspectos, não só na formatação do código fonte, mas também como nomear variáveis e diferentes estruturas nomeadas em um código, como testes automatizados e também de modelo de dados.

Em desenvolvimento de software nos dias atuais, pensar em como fazemos descoberta de um determinado problema e como fazemos construção. No caso de descoberta o que existe de entrada? Documentações, reuniões com clientes (transcrições e desenhos), algum tipo de manual de apoio, relatórios e outras regras de negócio que podem ser usadas como base. E no caso de entrega, todos os padrões que podemos estabelecer para fazer um código fácil de ler, testável e fácil de dar manutenção.

O canônico neste contexto falo sobre construção que acontece conforme normas mais habituais de uma gramática. Tipo existe um jeito fácil de operar e ser. Existem convenções onde tudo flui. Podemos fazer diferente, mas vai gerar mais trabalho.

Manutenção, testabilidade e documentação se tornam informações importantes para atuar com agentes de inteligência artificial. A forma de construção de software vai ser executada conforme padrões já definidos e testados anteriormente.

Estamos em um momento que posso remover o código criado e recriar a partir de uma especificação, sabendo que padrões e que ferramentas serão empregadas para resolver o problema. Se der errado, melhoro a especificação de agentes ou de padrões a serem usados, e construímos novamente.

O jogo mudou. E existe um jeito fluído de fazer acontecer. Ainda existem muitas opções e formas de criar esta padronização. E isso vai depender de equipe, estrutura de trabalho e padrões que desejamos ter.

-- Daniel Wildt