BT

Código é responsabilidade e risco: quanto menos, melhor

por Vikas Hazrati , traduzido por Giovanni Abner em 30 Mai 2011 |

Na Lean Manufacturing (termo traduzido como "produção enxuta" ou "fabricação otimizada"), o significado de estoque é bem claro: é o material adicional, o material sendo usado no momento, ou o material que está pronto para ser usado na próxima parte do trabalho. A mentalidade Lean enfatiza a redução do estoque, porque sempre há custos associados à sua manutenção. No desenvolvimento de software, os requisitos são frequentemente tratados como estoque. Mas e o código?

Sobre isso, Michael Feathers diz:

Se você gasta muito tempo elaborando requisitos para funcionalidades que não vai implementar de imediato, seu processo não é simples o suficiente. Isso é verdade, mas a dura realidade é que temos algo muito mais tangível que podemos tratar como se fosse estoque: o nosso código.

Ainda segundo Feathers, na produção enxuta os produtos são feitos um a um. Pode-se ganhar eficiência simplificando a forma como as peças são manipuladas no processo. Mas quando se trata de software, as coisas são diferentes. Em software, há equipes trabalhando sempre na mesma peça, e esta praticamente só fica pronta quando começa a ser usada. Portanto, o código é um estoque vivo que nos acompanha e que precisa ser minimizado.

No desenvolvimento de software, estamos essencialmente trabalhando no mesmo carro ou produto, não raro durante anos. Estamos envolvidos na mesma base de código, no mesmo problema. Não podemos esperar que um modelo de produção baseado na independência das peças funcione adequadamente quando trabalhamos continuamente com uma coisa só (o código), que se desgasta com o tempo e precisa de atenção constante. Para mim, o código é estoque e tem um considerável custo de propriedade. É saudável pensar em formas de minimizá-lo.

De forma similar, Ori Pekelman sugere que código é mais uma responsabilidade ou um risco do que um ativo. As equipes, segundo ele, têm que escrever código para construir um produto e ganhar dinheiro. Mas depois deveriam encontrar maneiras de reduzir o código o máximo possível, para manter os custos baixos. Para Pekelman,

Quanto mais código se tem, mais custoso será adicionar coisas novas. E a má notícia é que tudo que se adicionar ao código existente aumentará o problema, tornando acréscimos posteriores ainda mais custosos. Mas a utilidade marginal negativa do código existente não é imutável: quanto melhor estruturado estiver, quanto mais testes unitários existirem, quanto mais forem usados bancos de dados sem esquema ou com esquemas flexíveis, menos custoso o novo código será.

No livro The Art of Readable Code ("A Arte do Código Legível", sem tradução em português) de Boswell e Foucher, os autores enfatizam a importância de se ter bases de código enxutas, indicando que a melhor forma de lidar com um sistema em produção é mantendo seu código o mais resumido e leve possível. Alguns dos caminhos sugeridos são:

  • Criar o máximo possível de utilitários de uso geral;
  • Remover código ou funcionalidades não utilizadas;
  • Modularizar projetos em subprojetos independentes;
  • Ter familiaridade com bibliotecas que podem ser usadas;
  • Ter sempre consciência do tamanho do código e mantê-lo leve e ágil.

Kevlin Henney destaca que há grande necessidade de excluir código e torná-lo o mais leve possível, em seu guia prático para escrever menos código.

Portanto, há fortes motivos para manter seu código leve e ágil, como Feathers resumiu:

Considero que o futuro pertence às organizações que aprendem a estrategicamente a apagar código. O custo de manutenção de estoques é maior do que se pensa e as empresas que percebem isso têm vantagens competitivas.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Menos Código by Fernando Ribeiro

Tem muito código para ser apagado, muita coisa para ser transferida para a camada inferior (framework, servidor de aplicações, sistema operacional, hardware), sempre vale procurar.

Por um código limpo by Paulo Rebelo

Atualmente, vale a máxima de que quanto menos código melhor, assim como quanto mais simples, limpo e refatorado melhor ainda.

Modularizar by Pernalonga SC

Modularizar projetos em subprojetos independentes. Nem sempre depende só de você isso.

Boas Práticas by Márcio Rosa

Gostei muita da idéia de apagar códigos, também não gosto nenhum pouco de dar manutenção em código poluido, sem identação e com gambiarras, a vontade é de fazer um refactor e deixa-lo mais simples e limpo mais nem sempre é viavel devido a forma que a empresa trabalha e fatores internos de força maior, uma frase que define bem isso é:
"Sempre foi assim", ou seja além da empresa perder dinheiro pois quanto mais "zuado" e "bizarro" o código, mais tempo o desenvolvedor vai demorar para implementar algo, criando o famoso elefante branco.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

4 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT