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].
É 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).
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).