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?
Opa amigo, eu também tenho uma lista aqui, que apesar de não ser norma na empresa onde eu trabalho eu a torno parte do meu cotidiano.
Eu tenho essa lista colada aqui do lado do meu monitor:
Good Code:
Dont Repeat Yourself
Run All tests
One function should do one thing
Meaningful names
Small blocks are better
Keep a good error handling
Has a good comments
Dont Forget:
The single responsability principle and Demeters Law
Keep yourself simple and clean.
Coloquei a lista em inglês porquê lembro dos termos dessa forma.
Traduzido…
Bom código:
Não Se Repita
Executa todos os testes
Uma função deve fazer uma coisa
Nomes significativos
Pequenos blocos são melhores
Mantenha um bom tratamento de erros
Possui bons comentários
Não se esqueça:
O princípio da responsabilidade única e a Lei de Deméter
Mantenha-se simples e limpo.
Além dessa lista, aqui na empresa temos uma rotina que roda o PMD nos fontes no inicio e no final do dia e é uma diretiva corrigir qualquer warning no código.
Ola, gostei desses aqui, vou adicionar na minha lista.
Acho importante so fazer check in de codigo de qualidade, porque a experiencia que a gente tem aqui tem mostrado que leva muito mais tempo ficar mexendo no mesmo codigo 2, 3 ou mais vezes pra arrumar coisas do que demorar um pouquinho mais no comeco pensando num monte de detalhes e ter um codigo de qualidade.