Pular para o conteúdo

Moldando o seu Framework

Você escolheu uma semente porque era a mais próxima. Em algum momento ela deixa de servir, e isso é esperado: um Framework (a estrutura) pode remodelar qualquer parte sem bifurcar o padrão.

Toda mudança é uma edição do .eidos/Framework.yaml e dos templates (modelos) ao lado dele. eidos configure:<noun> faz cada uma a partir do shell, mostrando o plano primeiro e reescrevendo todo Blueprint (plano) e link que a mudança alcança; o Framework Settings do navegador faz o mesmo como formulários. Comandos →

O que você muda O que você nunca toca
Uma coleção, pasta, grupo, variant (variante), propriedade, termo, documento ou papel A prosa de um Blueprint
O índice gerado
properties.core: do padrão, reescrito pelo migrate
A convenção de nomes, depois que existem arquivos
Janela do terminal
eidos configure:collection add decisions --description "Architecture decision records." --grouping Areas

Decida quatro coisas: o nome, uma descrição de uma linha, as variants (começa com uma) e se ela agrupa os seus Blueprints um nível abaixo.

Janela do terminal
eidos configure:variant add specs api --from micro

Normalmente a resposta certa quando os Blueprints de uma coleção variam. Uma família de templates por coleção: o que muda é quais seções aparecem, nunca a ordem ou os nomes. “Specs de integração têm cinco seções diferentes” não é uma variant; é uma coleção diferente, ou um sinal de que as seções deveriam ser opcionais em um só template.

Dois padrões que funcionam: leve → completo (micro cresce até full, mantendo intenção, critérios e non-goals) e uma alternativa deliberada de peso igual para um tipo diferente de unidade na mesma coleção.

Um grupo cujos Blueprints quase todos usam uma mesma variant pode dizer isso, e um Blueprint novo ali começa por ela antes da padrão da coleção:

Janela do terminal
eidos configure:group set specs ideas --default-variant micro
Janela do terminal
eidos configure:property add tier --type Text --applies-to specs --options Core,Extended --meaning "How central the unit is."

Decida tudo: nome, tipo, a que se aplica, obrigatória e significado, e opções onde o valor é um de um conjunto que você controla. Prefira opcional por padrão: uma propriedade obrigatória é preenchida em branco em todo Blueprint a que se aplica e relatada até ser preenchida.

Antes de adicionar uma, verifique três coisas:

  • Uma seção do corpo seria melhor? Se ela quer mais estrutura do que um dos seis tipos, sim. A lista de tipos é curta para forçar esta pergunta.
  • É um rótulo leve ou estrutural? Uma categoria que rege visões é um rótulo. Uma que muda quais seções um Blueprint tem é uma variant.
  • É acompanhamento de trabalho disfarçado? sprint, estimate, assignee e qualquer coisa que signifique “quão longe está”: progress, phase, target_date. Em vez disso, linke para o seu gerenciador de tarefas.
Janela do terminal
eidos configure:property remove depends_on

A metade negligenciada. Se uma propriedade ficou em branco nos últimos vinte Blueprints, ela não faz parte do seu contrato. O plano mostra cada valor que seria perdido antes de remover a entrada e as chaves; nada é descartado em silêncio.

Os arquivos de papel são commitados e ajustáveis pelo time: edite-os diretamente, ou adicione um novo com eidos configure:role add. Os elencos das sementes são ilustrações, não um conjunto fixo. Papéis →

Tudo na raiz é declarado. Uma pasta ou arquivo que o documento do Framework não lista é relatado pelo eidos check até que você o declare (configure:folder add, configure:doc add) ou o mova.

Agrupar mais fundo do que um nível não é permitido. Se você está buscando um terceiro nível, o que você quer é outra coleção.

Depois que o seu assentar, ele é forma sem conteúdo, que é exatamente o que você entrega a outro time. Se dois produtos na sua organização deveriam ser descritos do mesmo jeito, publique o Framework em vez de copiar uma raiz e apagar o conteúdo. Um Framework, qualquer número de raízes. O Registro →