└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Code Review Checklist 
 2 | 
 3 | ## Geral
 4 | 
 5 | - O código funciona? Ele desempenha o papel esperado, a lógica está correta, etc?
 6 | - O código é facilmente entendido?
 7 | - O código respeita as convenções de codificação [definidas para o projeto](https://github.com/Coderockr/Standards)?
 8 | - Existe algum código redundante ou duplicado?
 9 | - O código é o mais modular possível?
10 | - Algum código de log ou debug pode ser removido?
11 | - Se a tarefa exigir a inclusão de uma nova biblioteca/componente no composer.json ou no bower.json toda a equipe deve ser informada para evitar problemas de compatibilidade. O mesmo caso seja necessária uma atualização de versão de uma biblioteca/componente já existente
12 | - Código comentado foi removido?
13 | 
14 | ## Segurança
15 | 
16 | - Todos os inputs foram validados (tipo correto, tamanho, formato, valores válidos)?
17 | - Os parâmetros inválidos foram tratados?
18 | 
19 | ## Documentação
20 | 
21 | - É necessário executar o algum comando extra (composer, grunt,bower, etc) para que o código funcione
22 | ? Deve ser avisado na descrição do PR se for o caso. 
23 | - O código possui documentação? Nos principais métodos e lógicas complexas?
24 | - Todas as variáveis foram definidas com nomes significativos, consistentes e claros?
25 | 
26 | ## Performance
27 | 
28 | - As consultas do Doctrine (ou do banco de dados, ou Zend\Sql, etc) foram otimizadas pensando-se em melhoria de performance?
29 | - Informações que podem ser armazenadas em cache estão sendo cacheadas?
30 | - Processamentos redundantes ou lentos foram otimizados?
31 | - Foi evitado o uso de construções IF-ELSE para diminuir a complexidade da execução?
32 | 
33 | ## Testes
34 | 
35 | - Se a tarefa envolver apenas um módulo, executar os testes daquele módulo. Se envolver mais de um, rodar todos os testes do sistema. 
36 | - Os testes unitários devem ser rodados com todos os erros do PHP habilitados de modo à garantir que nenhum notice,warning,deprecated entre na base.
37 | - Se for uma tarefa que crie ou altere uma API devem ser criados/alterados os testes de Api referentes a tarefa (caso o projeto possua este tipo de teste)
38 | - Os testes unitários devem cobrir tanto dos casos de sucesso quanto dos casos de erro
39 | - Testar a interface seguindo os requisitos mínimos de navegadores:
40 | 
41 | 	- Microsoft Internet Explorer 8.0
42 | 	- Chrome 35.0
43 | 	- Safari 8
44 | 	- Firefox version 35
45 | 
46 | - Caso não consiga testar em todos os navegadores deve descrever na descrição do PR em quais navegadores realizou os testes
47 | 
48 | 
49 | 
50 | 
51 | ## Referências
52 | 
53 | [http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/](http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/)
54 | 
55 | [https://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist.pdf](https://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist.pdf)
56 | 


--------------------------------------------------------------------------------