Os sete passos para o desenvolvimento de firmware de qualidade

No excelente livro de Jack Ganssle, The Art of Designing Embedded System Design, são apresentadas ao leitor boas práticas para o processo de desenvolvimento de sistemas embarcados.

 

Estas práticas foram observadas com base em pesquisa em empresas de sistemas embarcados, olhando o que funciona e o que não funciona. E também, é claro, com a experiência adquirida pelo Jack em sua longa carreira na área.

 

Um dos dados mais interessantes, ao meu ver, é que, segundo Jack, na maioria das empresas de sistemas embarcados a experiência não faz a menor diferença na produtividade. Muitos começam a escrever código assim que se formam e nunca estudam para evoluir, fazem a mesma coisa durante toda a carreira, então, segundo pesquisa, não há diferença na produtividade entre pessoas com 6 meses, 1 ano ou 15 anos de experiência. Apenas repetimos a mesma experiência durante toda a nossa carreira.

 

Segundo Jack, qualquer idiota pode escrever código. Profissionais acham jeitos de criar software de alta qualidade dentro do prazo e do orçamento. O plano de sete passos:

 

 

1. Use um sistema de controle de versão

 

Até mesmo uma empresa de uma pessoa necessita de um controle de versão, rastreabilidade de mudanças é fundamental, saber exatamente quando e o que ocasionou um bug, reconstruir o sistema em uma data específica, backup do código fonte e de arquivos importantes e etc. são as principais vantagens de se utilizar controle de versão.

 

 

2. Utilize um padrão de codificação para desenvolvimento de firmware

 

Você não consegue escrever um software bom sem um guia de boas práticas, ainda assim a maioria das empresas não utiliza um guia escrito de regras para codificação. Os padrões de codificação garantem que todo software desenvolvido pela sua empresa tenha um nível mínimo de manutenção e legibilidade. Também previne discussões tolas como identação, todos devem seguir o padrão da empresa e pronto.

 

 

3. Comece um programa de inspeção de código

 

A idéia é ter uma reunião semanal de no máximo duas horas com papeis bem definidos (leitor, moderador, autor e gravador). O código, antes de ser testado, deve passar pela reunião de inspeção de código e só então testado. Alguns dados do livro: A HP encontrou que 80% dos erros pegos na inspeção de código não seriam pego nos testes; segundo a IBM 82% dos erros são pegos antes do teste começar. Segundo Jack, não há melhor jeito de pegar bugs do que a inspeção de código. Outro dado interessante é que o custo por linha de código de firmware varia entre 20 e 50 dólares, o custo para fazer esta revisão de 2h/semanais é de 1.54 dólares por linha. Os benefícios superam e muito o custo de corrigir estes bugs mais tarde.

 

 

4. Crie um ambiente silencioso, que instigue o pensamento

 

Segundo estudo apresentado no livro, um lugar de trabalho quieto chega a multiplicar a produtividade por 260%! Após uma interrupção por ligação ou pedido de ajuda, o desenvolvedor demora em média 15 minutos para voltar à concentração e, segundo Jack, um ambiente onde o desenvolvedor também dá suporte simplesmente não é viável/produtivo.

 

 É necessário seguir estes quatro passos (só 1, 2 ou 3 não bastam) para, daí então, ir para os próximos três:

  

 

5. Meça a taxa de bugs por linha de código de um projeto

 

O passo 3 é muito importante mas mesmo assim os bugs estarão lá, eles sempre estão. Bugs são uma parte natural do processo de desenvolvimento de software, mas temos que estar preparados para pegar e corrigir estes erros.

 

 

6. Meça a taxa de produção de código

 

Os prazos falham por muitas razões, e a principal desculpa encontrada é que sem uma clara especificação do projeto, qualquer estimativa de prazo é inútil. Mesmo assim muitos projetos começam todos os dias com a seguinte especificação: “Faça um produto que é parecido com aquele, com uma ou duas coisas a mais, mais barato e menor”. Qualquer estimativa em cima desta especificação não tem valor.

 

Você deve medir quão rápido você escreve código para embarcados e monitorar esta medida para toda a sua carreira. Assim facilita inclusive a estimativa de prazos, Linhas de código estimada * Tempo por linha.

 

 

7. Estude constantemente engenharia de software

 

Aprenda novas tecnologias, faça experimentos com elas, aprenda novas e melhores maneiras de escrever código. Repita isso durante toda a sua carreira.

 

No livro há exemplos de modelos para alguns tópicos, além de explicações mais detalhadas.