Padrões Desenvolvimento
1 - Tarefa de Bug
1.1 - Informações técnicas
1.1.1 - Painel Motivo da Inconsistência
Utilizar o painel do tipo “erro” para documentar o motivo da inconsistência
Nesse painel descrever o motivo da inconsistência, o porquê ela ocorre. Também adicionar os nomes das classes e métodos onde o erro acontece.
1.1.2 - Painel Sugestão da correção
Utilizar o painel do tipo “sucesso” para descrever a sugestão da correção.
Nesse painel descrever o que pode ser feito para corrigir a situação, pode-se adicionar trechos de código como exemplo de como ajustar o bug e também descrever as classes e métodos que precisam ser alterados.
Correto: |
1.2 - Descrição da implementação
Descrever o que foi alterado para resolver o problema.
Utilizar o formato:
Correção: Descrição do que foi alterado.
Motivo: A razão do ajuste que foi realizado.
Observação: esse tópico é utilizado para revisão de código e também para ter documentado o que foi feito para resolver o problema, caso em outro momento for necessário lembrar.
Correto: |
Caso a tarefa possuir reprovação, adicionar um painel do tipo erro com o seguinte formato:
Correto: |
1.3 - Plano de testes
1.3.1 - Checklist de desenvolvimento
Utilizar um painel do tipo sucesso para documentar o “checklist de desenvolvimento”.
Nesse painel, deve-se documentar, em forma de tópico, tudo o que foi ajustado na tarefa.
Ele deve ser feito pensando em quem testará a tarefa, ou seja, não é necessário colocar nome de métodos e classes, apenas documentar, de maneira objetiva e não técnica, todas as correções realizadas.
1.3.2 - Rotinas/Módulos
Utilizar um painel do tipo nota para documentar as “rotinas/módulos”.
Painel para listar todas as rotinas que a correção pode impactar.
1.3.3 - Plano de teste
Utilizar um painel do tipo info para o “plano de testes”.
Nesse painel, deve-se colocar um passo a passo do que fazer para realizar os testes, quanto mais detalhado melhor. Descrever as configurações a serem realizadas para o teste e o comportamento esperado em cada cenário.
Correto: |
2 - Tarefa de Melhoria
2.1 - Informações técnicas
Utilizar o status de análise técnica apenas para mapear os arquivos e métodos que será necessário mexer.
Na documentação, separar os tópicos por projeto, descrevendo os arquivos e métodos a serem criados ou alterados, também é interessante colocar arquivos já existentes para se utilizar como base, caso necessário.
Correto: |
2.2 - Descrição da implementação
Caso tenha sido seguido tudo o que foi documentado na análise técnica, pode-se adicionar o seguinte comentário:
Realizado as implementações descritas nas informações técnicas;
Dessa forma não é necessário repetir tudo o que já havia sido analisado nas informações técnicas.
Caso for implementado coisas além do que foi descrito nas informações técnicas, é interessante adicionar em forma de tópico. Assim como nos bugs, esse campo também é utilizado para revisão de código.
Comandos de banco
Sempre que houver comandos de banco na tarefa, adicionar um painel do tipo código com os comandos implementados.
Etapas Alteradas
Caso for mexida em alguma consulta das etapas da carga inicial do mobile, adicionar a consulta antiga e a consulta atual em painéis do tipo código. Essa documentação é necessária apenas quando houver alterações que podem impactar no tempo da carga, como inner joins ou subselect. Em casos onde apenas é adicionado colunas novas no select não é necessário.
Correto: |
Caso a tarefa possuir reprovação, adicionar um painel do tipo erro com o seguinte formato:
Correto: |
2.3 - Plano de testes
2.3.1 - Checklist de desenvolvimento
Utilizar um painel do tipo sucesso para documentar o “checklist de desenvolvimento”.
Nesse painel, deve-se documentar, em forma de tópico, tudo o que foi ajustado na tarefa.
Ele deve ser feito pensando em quem testará a tarefa, ou seja, não é necessário colocar nome de métodos e classes, apenas documentar, de maneira objetiva e não técnica, todas as correções realizadas.
2.3.2 - Rotinas/Módulos
Utilizar um painel do tipo nota para documentar as “rotinas/módulos”.
Painel para listar todas as rotinas que a correção pode impactar.
2.3.3 - Plano de teste
Utilizar um painel do tipo info para o “plano de testes”.
Nesse painel, deve-se colocar um passo a passo do que fazer para realizar os testes, quanto mais detalhado melhor. Descrever as configurações a serem realizadas para o teste e o comportamento esperado em cada cenário.
Correto: |