Independente do sistema de controle de versão de código que seu Projeto utiliza (GIT, SVN, etc.), saber redigir logs para cada revisão submetida ao repositório vai afetar muito a qualidade do resultado final de builds.
Aqui vamos ver os motivos disso e como podemos mudar nossa visão de algo tão negligenciado no ambiente de desenvolvimento e, ao meu ver, de vital importância.
Logs
Vivemos em uma era de metadados. Então, vamos pensar que as mensagens que deixamos armazenadas nos commits dos nossos códigos para o servidor são logs que devem manter um padrão para nos servirem de consulta a qualquer momento, inclusive em um futuro distante quando alguém necessitar entender uma parte do aplicativo para suporte ou correção.
Ou seja, mensagens em commits são feitas por humanos para serem lidas por humanos. Lembre-se disso sempre que estiver redigindo um log.
Evolução
De acordo com o conteúdo das mensagens podemos entender a evolução do Projeto e até mesmo os desvios na tomada de decisões que ele sofre.
Busca
Mensagens padronizadas facilitam a busca por termos relevantes à equipe de desenvolvimento e gestão do projeto. A relevância do que está sendo submetido no repositório a cada revisão deve estar transcrita dentro do commit.
Padrão
Mesmo trabalhando em equipes heterogêneas, distribuídas de forma abrangente na questão geográfica e, algumas vezes com integrantes que falam línguas diferentes, deve-se estabelecer logo no início do projeto um padrão para a escrita de mensagens nos commits.
Uma sugestão é o método MARC, (M)odificado, (A)dicionado, (R)emovido ou (C)orrigido. Cada mensagem ou frase, obrigatoriamente deve se iniciar com um desses quatro termos. Isso dá um norte para o desenvolvedor seguir na descrição da tarefa realizada naquele commit. Exemplos:
- “Modificado método de validação de dados no formulário de edição de Clientes”.
- “Adicionado recurso para emissão da ficha cadastral de Fornecedores.”
- “Removida rotina de exclusão de Logs.”
- “Corrigido erro no processo de cálculo do frete para outro país.”
Isso também reduz o trabalho de cada revisão à uma tarefa específica. Misturar soluções dentro de um mesmo commit é sabido ser uma prática nefasta no meio de programação e deve ser evitada a todo custo.
Conflitos
O trabalho de resolução de conflitos surgiu de forma natural após a difusão desse método de trabalho distribuído. Existem cargos e funções específicas de revisão de código cuja função é exata e exclusivamente essa. Facilitar o trabalho desses profissionais também é contribuir para uma evolução rápida e precisa do Projeto.
Maus Exemplos
- “Ticket #4594 finalizado” – ok, mas cole uma frase relevante desse Ticket no log da próxima vez, combinado?
- “Modificada linha com erro na emissão de notas fiscais” – é muito fácil descobrir qual arquivo e linha foram modificadas com apenas um único comando. isso é totalmente desnecessário mencionar em um log. foque no assunto, ex: “Corrigida rotina de cálculo do ICMS na homologação de NF-e para região Norte”
- “Problema resolvido” – Sério?!?
Por fim, evite textos longos nos logs e faça uso do WIP ou TEA (Work in Porgress/Trabalho em Andamento) quando precisar submeter algo para dar continuidade em outra estação de trabalho ou compartilhar essa parte do trabalho com algum colega.
Happy coding!
