Tagged: desenvolvimento de software

Código Fonte: Os acordos

Cconvenções sobre códigos fonte são importantes e bem-vindas quando existem mais de uma pessoa construindo software. As vantagens são várias, mas a principal é a possibilidade de um desenvolvedor poder analisar o código de outro o mais rápido possível.

Independente qual abordagem de engenharia de software o time está usando, o código fonte será modificado e interpretado por pessoas o tempo todo. O nível mais físico (ou 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.

Nos seguintes tópicos serão apresentados elementos relacionados com os acordos sobre códigos fonte.

Utilizar Code Standards

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 tem 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 o time leia várias opniões e compile um documento customizado para as necessidades do time composto. A formula é sempre diferente para cada grupo de trabalho. Então idealmente faça um workshop e defina junto com o time quais padrões serão utilizados e onde serão publicados.

Utilize Nomes Significativos

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 cria-se 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 depara-se 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 idéias e lógicas especificas atrás de variáveis como “list”, “l”, “hash”, “stmt”, “i”, “result”…

Concluimos que linguagens modernas(Java, Go, …) não precisam de mnemonicos 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 é comum aparecer trechos de códigos antigos que não estão sendo executados ou até estão comentados. 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. Geralmente utilizo um brown-bag session que é uma reunião rápida (max 20 min) para apresentar este tipo de assunto.  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 como Confluence (da Atlasian). 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).

Ultima alteração: 19 Outubro 2015.

Me diga o que achou pelo twitter @RafaelGorski. Caso tenha algum template para compartilhar, terei o prazer de publica-lo.

Referências:

[1] Schneidewind, Norman F. “The state of software maintenance.” Software Engineering, IEEE Transactions on 3 (1987): 303-310.

[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