Mais sobre as "Regras de Ouro"

Após a divulgação do artigo "As 'Regras de Ouro' do desenvolvimento de software", me pediram para falar mais sobre cada uma, dando exemplos quando possível. Vou tentar atender ao pedido neste artigo.

Não se repita.

Esta regra não se refere apenas a não dizer a mesma coisa duas vezes. Esta regra não se refere apenas a não dizer a mesma coisa duas vezes. Ela está voltada para coisas mais profundas como não armazenar a mesma informação em mais de um lugar.

Por exemplo, imagine que você tem um conjunto de arquivos que deve ser instalado pelo instalador do seu software e, consequentemente, removido na desinstalação. Seria uma quebra desta regra se você fizesse algo do tipo:

:install
  copy a b c d e f <destDir>
:uninstall
  remove a b c d e f from <destDir>

Notaram a repetição de "a b c d e f"? Neste caso para evitar a repetição, a resposta seria usar uma variável. Em outros casos, pode ser mais complicado e exigir até mesmo um gerador de código automático.

Outro caso comum de repetição acontece quando um programador (normalmente novo na equipe, mas às vezes também um antigo e com preguiça de procurar o que já existe no código) inadvertidamente cria uma função para fazer a mesma coisa que uma que já existe e que ele não conhecia.

Outro exemplo, mais sutil:

Comentários descrevendo o que uma parte de código faz. O código em si deveria ser claro o suficiente para explicar o que ele faz (leitores entenderem), além de fazer o que deve (computadores entenderem). Os comentários devem ser usados apenas para informar sobre decisões e aspectos de mais alto nível relacionados ao código. Como está muito bem dito por Andrew Hunt e David Thomas em The Pragmatic Programmer: "bad code requires lots of comments".

Outro exemplo:

Duplicação entre a especificação e o código. Ok, esta é difícil de eliminar, mas num mundo ideal seria legal ter a informação só na especificação e o código sair sozinho. Uma das ideias com UML é poder especificar usando-a e gerar código automaticamente. Bom, a gente sabe o final da história e não preciso falar a respeito. :-)

Não separe o que deve estar junto.

"O que Deus uniu, o programador não separe."

Exemplos:

Documentação de projeto (especificações, etc) devem estar guardadas junto com o código (também devido à regra de manter as coisas perto de onde são usadas - a propósito, todos sabem que as especificações devem ser usadas durante a codificação?).

cpp e h de um mesmo módulo devem estar no mesmo diretório.

Instalador de produto e código do produto devem estar na mesma árvore.

Código do módulo e unit test do módulo devem estar juntos. Aliás, eu particularmente prefiro que o código de unit test esteja dentro do mesmo arquivo que o código de produção do módulo; assim, se diminui o trabalho para criar casos de teste novos ao criar funcionalidades novas e se evita o "esquecimento" de atualizar os testes. Unit test junto do código de produção também facilita a depuração quando aparece um bug, pois facilmente se coloca o módulo suspeito em teste (lembem-se de "O procedimento de correção de bug")

Não junte o que deve estar separado ou coisas que não estão relacionadas.

"O que o programador junta, nem o diabo separa."

Exemplo clássico: O programador precisa fazer uma função que retorna nome e sobrenome, então ele concatena os dois dados numa string e retorna a string, na ilusão de que, se alguém precisar do nome e sobrenome separados (ou em um formato de concatenação diferente...), é só "parsear a string". Não caia nesta ilusão; o correto é retornar os dados separadamente, porque isto é uma interface mais genérica. Ou, o que ainda é melhor no caso de linguagem orientada a objetos: Não ter uma função que retorna o nome e o sobrenome e sim métodos que processam o nome e sobrenome internamente e resolvem todo o problema dentro da classe (exemplo: um serializador para stream).

Guarde as coisas perto de onde elas são usadas.

Aqui a questão é guardar as coisas fisicamente próximas de onde elas são usadas.

Por exemplo, eu tive um cliente que seguidamente me contactava perguntando a data em que alguma versão do software tinha sido liberada e o que tinha sido incluído naquela versão. Para dar uma resposta rápida e exata, eu precisava ter estas informações à mão perto de minha estação de trabalho. Solução: Imprimir um resumo de cada release contendo data, novidades e versão liberada e deixar estas folhas presas na parede na frente da minha mesa - guardadas onde elas seriam usadas.

Outros exemplos:

Se há uma instrução de como desligar o ar condicionado, imprima-a e coloque-a perto do aparelho ao invés de deixá-la na rede da empresa. O mesmo vale para instruções de como fechar porta, fazer café, normas de codificação, etc..

Se há um esqueleto padrão de arquivo fonte, ponha-o bem pertinho de onde os arquivos fonte vão ficar. Junto com os fontes, no sistema de versionamento, num diretório chamado skels, por exemplo.

Guarde todo o material necessário para o seu projeto de software no mesmo sistema de versionamento e faça com que seja fácil (com um comando) baixar tudo quando necessário.

Teste tudo que você faz. 
Teste cedo, teste frequentemente. Se tem 3 linhas, já devia ter sido testado. Se tem um if, já devia ter passado por 2 testes.

O que você testa, funciona de primeira; o que você não testa, dá pau. Precisa dizer mais?

Sistemas de Qualidade de Software

Muito se fala em sistemas de Qualidade de Software (em geral, o pessoal gosta de maiúsculas no nome). Um sistema muito discutido e aplicado no Brasil tem sido o CMM. Infelizmente, poucas vezes se retorna às origens deste sistema para ver de onde surgiu e que problema ele visava resolver. Também poucas vezes se fala a respeito do sucesso ou fracasso deste sistema no mundo de desenvolvimento de SW. Vamos dar uma olhada rápida (e com uma dose de parcialidade) nisto.

O CMM começou com o Departamento de Defesa Americano, como uma ferramenta para avaliação da maturidade de seus fornecedores, em meio a uma crise no gerenciamento e na qualidade do que era recebido. Notem que ele foi concebido como uma ferramenta de avaliação (por conseguinte, externa, para ser usada pelo contratante) e não como uma ferramenta de trabalho das empresas contratadas (que produzem o software). Muito tempo se passou desde então. Hoje em dia, não sei se o DOD ainda usa CMM. Mas sei que muita gente propõe que o usemos como metodologia para produzir software melhor. Pode ser que se consiga, mas até hoje, ainda não presenciei casos de sucesso real. E tenho minhas dúvidas se um modelo originalmente concebido como ferramenta de avaliação realmente é suficiente ou adequado para promover melhorias na qualidade.

Sobre sucessos e fracassos, sempre ouço que a indústria indiana de software tem um grande número de empresas com certificações CMM altas e que isto comprova a importância do CMM. Pode ser. Minha experiência com tais empresas é muito limitada: Resume-se ao fato de que ouvi muitos clientes americanos reclamarem da baixa qualidade do software de companhias indianas, tanto em relação à qualidade intrínseca (correção, desempenho, etc) quanto a prazos. Claro que não devemos generalizar, mas é o que ouvi. A outra experiência que tive foi de uma empresa em que trabalhei e que não tem (ou ao menos não tinha na época) CMM e foi contratada para desenvolver um software que estava há 2 anos nas mãos de uma indiana certificada CMM. Tal software, mesmo após estes 2 anos de trabalho, ainda não era minimamente funcional e apresentava um número elevado de bugs registrados. A decisão tomada logo que minha companhia entrou em cena foi abandonar totalmente a base de código herdada e recomeçar o projeto do zero. Aceitamos o desafio e o projeto foi concluído em aproximadamente 6 meses, com índices de bug baixíssimos (zero críticos, zero graves, três cosméticos) e com funcionalidades mais avançadas que as do projeto original.

E aí me perguntam se eu gosto de Qualidade de Software. Bom, eu prefiro software de qualidade...

LGM