Ola pessoal,
resolvi abrir esse topico apos uma discussao que eu tive com um colega de trabalho sobre quais os requisitos que devem ser satisfeitos num codigo para que ele seja aceitavel antes de um check in??
Aqui na empresa nos trabalhamos usando a metodologia Kanban e quando nos iniciamos o desenvolvimento de uma certa funcionalidade (story) nos temos uma definicao bem rigida pra aceitar que essa determinada funcionalidade esta completa.
Quando a gente quebra uma estoria em diversas tarefas menores, a pergunta eh qual a qualidade aceitavel do codigo antes do desenvolvedor fazer o check in?
Eu enumerei alguns:
-
A codigo funciona como esperado?
-
Foi desenvovida da melhor forma possivel, atendendo padroes da empresa, design patterns?
-
Nomes de metodos, funcoes, variaveis expressam corretamente o papel das mesmas e atendem aos padroes usados pela empresa?
-
Documentacao e comentarios estao presentes e dao uma boa descricao dos metodos, variaveis, funcoes?
-
Documentacao e comentarios, usam linguagem correta? Ingles precisa ser claro e correto.
-
Unit tests
-
Seguranca foi levada em consideracao?
-
Codigo foi verificado duas vezes pelo desenvolvedor e um vez por outro membro do time que seja familiar com a parte do sistema que a funcionalidade esta sendo implementada.
-
Em caso de desenvolvimento front-end, devem obedecer todos items anteriores.
-
Front-end, funcionalidade foi testada em diferente browsers
-
Front-end, a interface e design obedecem a acessibilidade e design especificados pelo time de design. UI foi revisitada e aprovada pelo time de design?
Tem varios padroes em como desenvolver unit tests tb mas ficaria um post muito longo.
E voces? O que voces pensam antes fazer o commit no seu codigo?
//Daniel
