onvenções/acordos da equipe de desenvolvimento de software são importantes e bem-vindas na construção de software. A principal vantagem destes acordos é o entendimento sobre como o software é organizado e sustentado ao longo do tempo por aquele grupo de pessoas. Aqui coloco propositalmente “grupo de pessoas” e não “empresa” para que se entenda que somente o “grupo de pessoas” pode chegar a um consenso sobre estes acordos. Diretivas da empresa podem ser importantes e devem ser seguidas, porém o time de desenvolvimento deve fazer a tradução destas diretivas com instruções práticas de como isto é aplicado no contexto do time de desenvolvimento de software. Na minha experiência, já vi pontos de vista assim como “Meu time usa SOLID”. Apontar um conjunto de livros não implica que realmente todos da equipe estão usando o conteúdo de um certo livro.
Independente qual abordagem de engenharia de software a equipe está usando, o código fonte será modificado e interpretado por pessoas o tempo todo. O nível mais baixo de abstração em um projeto de software é o código fonte e, este código, deve ser cuidado e preservado utilizando melhores práticas, convenções e acordos.
Este artigo apresenta tanto o ponto de vista acadêmico como profissional utilizando referências de trabalhos de pesquisa e sugestões de experiências profissionais. As informações aqui publicadas são de interesse para desenvolvedores, arquitetos de software e gerentes de desenvolvimento de software.
Minha sugestão é que Tech Leads/Gerentes utilizem reuniões rápidas para discutir os temas a seguir. Dependendo da maturidade do time mais de uma discussão será necessária. Brown-bag sessions são bem legais para colocar o time para discutir estes temas e um almoço de graça sempre ajuda :)
Nos seguintes tópicos serão apresentados elementos relacionados com os acordos sobre códigos fonte.
- Padrões de Código
- Precisão na Nomenclatura
- Remover Código Morto
- Definir Profundidade dos Testes
Padrões de Código
Uma das formas mais conhecidas de acordos são os padrões de código ou do inglês code standards. Os padrões de código têm como objetivo criar um conjunto de sugestões, regras e acordos para que o time de desenvolvimento seja homogêneo na construção do código fonte. Independente da linguagem estes acordos descrevem, por exemplo, como nomear os arquivos, nomear variáveis e formatar o código.
Existem diversos modelos [4][5][6] para code standards disponíveis na internet. O ideal é que a equipe leia várias opiniões e compile um documento customizado para as necessidades da equipe. Tech lead/Arquitetos devem ser os responsáveis pela criação e manutenção deste documento, assim como da apresentação regular quando novas pessoas entram na equipe. Idealmente faça um workshop e defina junto com a equipe quais padrões serão utilizados e onde serão publicados.
Precisão na Nomenclatura
Quando utilizamos nomes significativos para variáveis, nomes de arquivos, nomes de classes e pacotes criamos ligações mentais entre os componentes do software e do sistema tornando o entendimento melhor. Nomes são substantivos para identificar coisas, estas coisas podem ser objetos, processos, ou estados em um software. Quando se cria um software estes nomes devem ser claros e significativos para quem o interpreta depois. A equipe de desenvolvimento deve acordar um conjunto de regras para nomear os componentes, classes, variáveis, arquivos de um programa.
Vou comentar um exemplo inusitado da missão Apollo 8 da década de 50. O que você pensa quando se depara com um programa chamada “P01”? Você pensaria o “primeiro programa” a ser executado? humm…. “Primeiro programa” pode significar o programa de inicialização? Faz sentido… certo? Sim! Portando vou executa-lo antes dos demais! :) Certo? hehehe! Certo! Foi o que aconteceu! O astronauta Jim Lovell selecionou P01 e executou em pleno espaço e apagou todo os dados de navegação da Apollo! [7]
Este exemplo da Apollo mostra como um nome de programa pode causar um problema e tanto. O software P01 foi desenhado para limpar os dados em ambiente de desenvolvimento e não deveria ser executado em pleno voo. Estava no Manual! :) Entretanto o usuário (um militar inteligente e treinado) fez algo que o desenvolvedor documentou para não fazer. O problema é que Jim foi induzido pelo programador ao erro.
Como consertar esse tipo de coisa? Que tal CLR ou DNT como nomes para o programa? Não chamaria mais a atenção que P01? Imagino que sim! Uma possível conversão para isso é utilizar nomes mais claros e objetivos! E não esconder ideias e lógicas especificas atrás de variáveis como “list”, “l”, “hash”, “stmt”, “i”, “result”…
Concluímos que linguagens modernas (Java, Go, …) não precisam de mnemônicos e que suportam nomes longos e significativos. Um acordo para o seu time seria utilizar nomes mais precisos e explícitos como listaOrdenadaClientes ou programaApagaDadosNavegacao 😊
Remover Código Antigo ou Código Comentado
Quando um desenvolvedor altera um código para correção ou inclusão de uma nova funcionalidade ou até um refactoring / re-engineering é comum aparecer trechos de códigos antigos que não estão sendo executados ou até estão comentados. “Remove Dead Code” [9] é um dos padrões de refactoring. Caso seu time utilize processo de refactoring você deve ter testes unitários automatizados para verificar seu código depois da remoção. Um comentário rápido, a Refatoração como processo é outro tópico interessante para um acordo, o que acha?
A razão para existência de códigos antigos não utilizados é a natureza dos requisitos de software que sempre mudam, exigindo assim, a melhoria contínua do software. Uma outra razão é a construção de códigos de “teste” e debug dentro do código principal.
É obrigação de cada desenvolvedor fazer a limpeza do código fonte removendo códigos que não estão sendo executados ou estão comentados. Qualquer linha de código incrementa o tempo de análise do desenvolvedor e pode gerar uma interpretação errada do estado atual do código.
Remover código antigo? Isto mesmo? Sim! Isto mesmo! :) Parece ser um pouco radical apagar um código feito por um desenvolvedor no passado. Entretanto, a quantidade de código gerada em um projeto pode influenciar na sua complexidade. Então, é dever do desenvolvedor criar uma solução com o mínimo de informação possível.
Nos anos 80 acreditava-se que códigos não utilizados (ou comentados) eram ativos e que não deveriam ser apagados [2]. Porém, como comentado anteriormente, a quantidade de informação influencia na qualidade da solução e isto foi proposto por Suh (1990) [3].
Deixe os acordos vivos, visíveis e disponíveis
É importante visitar os acordos de construção de software uma vez ao ano ou quando a equipe sofre uma mudança significativa, como inclusão de novas pessoas no time de desenvolvimento. A rotação entre as pessoas que apresentam os acordos é importante; assim, o responsável pode melhorar a apresentação e até acordos.
Sugiro a publicação dos acordos em uma página wiki interna (Atlasian Confluence ) . Desta forma, todos podem visualizar e sugerir mudanças no longo prazo. Dependendo da sua empresa ou equipe é necessário um documento formal. Para isto, o Confluence tem plugins para exportar em “.PDF” ou “.DOC”. Caso não tenha esta ferramenta o Word é excelente :).
A utilização de acordos é vital para times de desenvolvimento de software e fazem as pessoas crescerem em conhecimento sobre a linguagem de programação utilizada e cenários comuns do dia-a-dia do desenvolvedor de software. O resultado esperado com a utilização dos acordos é o aumento da familiarização com o código fonte e a redução na melhoria e correção de problemas (bugs).
Profundidade de Testes Unitários
A definição do que é uma unidade de teste é importante para o time seguir testes unitários de código. Parece algo trivial e sem valor, entretanto cada equipe deve ter uma discussão sobre este tópico e esclarecer o que uma UNIDADE significa e sanar qualquer dúvida que se tenha. O teste unitário é a assinatura do Extreme Programming (XP) e fundamento para o Desenvolvimento-Guiados-por-Testes (TDD).
Recomendo que a equipe toda leia a explicação do Martin Fowler sobre Unit Test [8] e em seguida um brown-bag session para acordar com a definição.
11 maio 2020, expandindo o escopo para Acordos de Equipes de Desenvolvimento de Software, incluindo tópico sobre profundidade de testes.
19 outubro 2015, Texto inicial.
Me diga o que achou pelo twitter @RafaelGorski. Caso tenha algum template para compartilhar, terei o prazer de publica-lo.
Referências:
[2] Belady, Laszlo A. “Special Feature Evolved Software for the 80’s.” Computer12.2 (1979): 79-82.
[3] Suh, Nam P. The principles of design. Vol. 990. New York: Oxford University Press, 1990.
[4] DOOM 3 code style convension from ID Software.
[5] Oracle Java Code Convension.
[6] Java programming Style Guide, Central Washington University\
[7] Digital Apollo
[8] Unit test, https://martinfowler.com/bliki/UnitTest.html
[9] Remove Dead Code https://www.refactoring.com/catalog/removeDeadCode.html