

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Práticas recomendadas
<a name="best-practices"></a>

**Promova a propriedade.** Cada membro da equipe do projeto deve ter o poder de criar e possuir um ADR. Essa prática distribui o trabalho de pesquisa arquitetônico entre os membros da equipe e transfere esse trabalho do arquiteto de soluções ou do líder da equipe. Também promove um senso de propriedade no processo de tomada de decisão. Isso ajuda a equipe a adotar essas decisões mais rapidamente, em vez de tratá-las como decisões impostas por níveis mais altos da organização. 

**Preserve o histórico de ADR.** ADRs deve ter um histórico de alterações e cada alteração deve ter um proprietário. Quando o proprietário do ADR atualiza o ADR, ele deve alterar o status do ADR antigo para **Substituído**, anotar suas alterações no histórico de alterações do novo ADR e manter o ADR antigo no log de decisões. 

**Agende reuniões regulares de revisão.** Se você estiver em um novo projeto (greenfield), o processo de ADR poderá ser bastante intenso no início. Recomendamos que você estabeleça um ritmo regular de discussões e reuniões de revisão do ADR antes ou depois da reunião diária. Com essa abordagem, o definido se ADRs estabilizará em dois ou três sprints e você poderá construir uma base sólida com menos reuniões. 

**Armazene ADRs em um local central.** Cada membro do projeto deve ter acesso à coleção de ADRs. Recomendamos que você os armazene ADRs em um local central e faça referência a eles na página principal da documentação do seu projeto. Existem duas opções populares para armazenar ADRs:
+ Um repositório Git, que facilita a criação de versões ADRs 
+ Uma página wiki, que a torna ADRs acessível a todos os membros da equipe

**Código de endereço não compatível.** O processo de ADR não resolve o problema do código herdado não compatível. Se você tiver um código legado que não suporta o estabelecido ADRs, você pode atualizar gradualmente a base de código ou os artefatos desatualizados, ao mesmo tempo em que introduz novas alterações, ou sua equipe pode decidir refatorar o código explicitamente criando tarefas de débito técnico.