Padrões Desenvolvimento

1 - Tarefa de Bug

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.

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:

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:

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.

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:

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:

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:

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.

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: