Tornar a vida do usuário mais simples: Nossa meta

Lembre-se sempre de que programas de computador existem para facilitar a execução de um trabalho. Ou seja, para tornar a vida do usuário mais simples.

O que isto significa do ponto de vista de um programador? Significa que, ao tomar decisões de projeto, você deve pautá-las considerando o que vai tornar mais simples a vida do usuário, mesmo que isto implique em tornar a sua vida mais complicada. Resumindo: sempre optar pelo que dá menos trabalho para o usuário, mesmo que isto implique em mais trabalho para o programador.

Command Line Interfaces

Taí um artigo que eu gostaria de ter escrito. Mas já o fizeram muito bem em http://www.antoarts.com/designing-command-line-interfaces/. Recomendo que leiam.

Alguns excertos:

• "Ease of automation: Most command-line interfaces can easily be automated using scripts."
• "Fast startup times: Most command-line interfaces beat their graphical counterparts several times at startup time"
• "Easier to use remotely: Maybe it’s just me, but I prefer to remotely control computers via SSH over VNC"
• "Higher efficiency: Being able to do a lot by just typing some characters instead of searching in menus increases the efficiency which you are able to do work at"
• Try to avoid interactivity 
• Name the program correctly
• Follow the CLI conventions on arguments
• "Provide --version and --help"
• "If a program has nothing of importance to say, then be quiet"
• "Every program should do one, and only one thing, and do it well"

Metodologia XGH

XP é coisa do passado. A onda é usar XGH: http://www.judsonmaria.net/index.php/geral/extreme-go-horse-programming.

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

O conjunto básico

E que tal se a gente conversasse hoje sobre o que são as coisas fundamentais num projeto de software?

Todo projeto de software deve conter os itens listados abaixo. Quanto mais cedo eles forem criados, melhor. Recomendo até que eles sejam criados / adicionados na ordem em que os listo.

• Sistema de bug tracking. Exemplos: Bugzilla, Mantis, etc.
  Por que deve ser o primeiro item? Porque bugs ocorrem desde o primeiro dia de trabalho no projeto. Pode ser um erro em algum diagrama, algum problema que um programador encontra no código de outro como resultado de uma revisão, etc. Se ganha muito se isto for registrado de modo centralizado e CONCISO.
  Deve ser um sistema orientado para desenvolvedores, de modo a ajudar não só no controle, mas no processo de correção, ou seja:
• Deve ter, no mínimo, os estados New (não corrigido ainda), Fixed (bug corrigido, correção comitada no source control) e Verified (um release-build que contém a correção foi criado, testado para o bug e não se viu o dito cujo ocorrer novamente). Outros estados, embora não sejam fundamentais, ajudam muito. Exemplos: Assigned (tem alguém corrigindo o bug - isto evita que, em grupos grandes, dois desenvolvedores trabalhem na mesma coisa sem saber), Closed (confirmado pelo usuário que reportou o bug que ele não acontece mais).
•  Os desenvolvedores precisam poder criar entradas neste sistema. Parece mentira, mas tem muita equipe que acha que desenvolvedor não acha bug... Surpresa: Eles acham MUITOS. E normalmente os acham MUITO ANTES que o software entre em uma fase de testes.
• Deve permitir que os desenvolvedores coloquem anotações acerca da investigação das causas do bug no próprio bug report. (As seguintes Regras de Ouro se aplicam: "Não separe o que deve estar junto.", "Guarde as coisas perto de onde elas são usadas."
• Sistema de versionamento de fontes. Exemplos: subversion, git, cvs.
  Deve ser colocado no ar bem cedo, pois devemos ter o histórico desde o início. Muita gente mostra resistência em colocar material no sistema de versionamento antes de ter "algo que funcione". Não é uma boa idéia. Vença a resistência e comece a versionar no primeiro dia.
  Detalhes importantes: 
• Não existe um sistema de versionamento que seja absoluto. Cada método de trabalho casa melhor com um sistema diferente. Não se renda a modismos na hora de escolher. Escolha com a cabeça.
• Um bom versionamento implica em ter tudo no mesmo sistema e na mesma árvore de diretórios. Um comando de checkout único deve baixar todo o material necessário para trabalhar no projeto.
• Build automatizado e integração contínua. Mesmo antes de ter um software funcional (antes de começar a programar), ponha no ar um sistema de integração contínua e automatize o processo de build. O que se quer é que se produza os deliverables do software com apenas um comando e, ao se commitar algo no sistema de versionamento, o sistema de integração contínua faça o build e testes sozinho. Importante: Considero parte dos deliverables a geração de tags no sistema de versionamento, de modo a permitir a recuperação dos fontes usados em cada build.
  Na fase inicial do projeto, ainda não temos código, mas já devemos fazer um sistema automático que gere o pacote de instaladores, documentos (manual do usuário, etc), mesmo que gere um instalador com um executável tipo "return 0", que não faz nada.
• Unit tests. Automatizados, de preferência com possibilidade de rodá-los automaticamente durante o processo de build. Os unit tests devem ser aprimorados ao longo do projeto, por exemplo, quando se encontra um bug (ver O procedimento de correção de bug). Importante: Unit test é feito e rodado pelos desenvolvedores. Pode (e deve, sempre que possível) ser rodado automaticamente no build também; mas o fundamental é que os desenvolvedores possam rodar cada unit test de modo simples e na sua cópia de trabalho dos fontes.
• Número de versão no software. Sem números de versão não tem como ter rastreabilidade do software. Não tem como saber o que foi testado; não tem como saber quando bugs foram corrigidos. Mais detalhes no artigo Identificadores de Versão.
• Testes funcionais. Deve-se ter uma rotina de testes funcionais bem definida e executá-los seguidamente ao longo do projeto. Detalhes importantes: 
• O ambiente de teste (máquinas, dispositivos, etc) deve ser diferente do usado no desenvolvimento. Testes na máquina do desenvolvedor sempre funcionam (a não ser que seja um desenvolvedor muito relapso)...
• Usar sempre o material gerado nos builds automatizados para os testes. Nunca rode testes funcionais oficiais usando material gerado nas máquinas de desenvolvedores.
  

Assinaturas padrão dos operadores de stream

Sempre esqueço da assinatura padrão dos operadores de inserção e remoção do C++. Então resolvi anotar aqui:

std::ostream& operator<<(std::ostream& s, const MyData& data);

std::istream& operator>>(std::istream& s, MyData& data);

Um exemplo de implementação do >>:


istream& operator>>(istream& s, MyDataEnum& data)
{
    int v;
    s >> v;
    
    if (s) //Conversion OK.
        data = MyDataEnum(v);

    return s;
}