Em 1998, a Pirelli, empresa italiana que fabrica de pneus a cabos de aço e de fibras óticas a robôs, lançou um slogan: Potência não é nada sem controle. No campo automobilístico, podemos resumir qual o significado dessa frase ao pensarmos nas cenas de filme de carros em alta velocidade chegando próximos à ribanceiras e se salvando de quedas mortais por poucos centímetros.
Um carro é um produto de engenharia. Há um processo bem definido e controlado para construí-lo. É possível estimar com grande segurança o tempo e o custo necessários para fabricá-lo.
O software nasceu pelas mãos de matemáticos, físicos e engenheiros. A computação já existia antes de existirem os computadores como nós conhecemos hoje, que na verdade constituem apenas um tipo de computador específico: o computador eletrônico. Cada um desses grupos contribuiu na criação de software com aquilo que conhecia. Os engenheiros tentaram aplicar ao software o mesmo processo utilizado na construção de produtos tangíveis: aí nasceu a Engenharia de Software.
Mas o software é muito diferente de um produto ordinário de engenharia. Philippe Kruchten [1] afirma que o software apresenta quatro características diferenciais:
- Ausência de uma teoria fundamental
- Facilidade de mudança
- Evolução rápida de tecnologias
- Baixo custo de manufatura
A facilidade de mudança e o baixo custo de manufatura podem dar a impressão de que o software é muito fácil de construir do que qualquer produto de engenharia, então os processos de engenharia aplicados ao software darão muito mais resultado do que os aplicados a produtos tangíveis. Ledo engano.
Enquanto não padece dos males dos produtos tangíveis, o software apresenta muito mais complexidade do que eles. É incrível ver hoje como o software era desprezado pelas grandes empresas no final da década de 70. O desprezo pela importância do software tornou possível a ascensão meteórica da Apple e da Microsoft, que começaram seus negócios sem sequer ter o que vender.
Em artigo apresentado em 1972, ao receber o Turing Award, o pioneiro da programação de computadores Edsger Djikstra [2] já apontava para a complexidade do trabalho do programador:
“Mas eu chamei a essa uma causa menor; a causa maior é… que as máquinas se tornaram várias ordens de magnitude mais poderosas! Colocando de uma forma brusca: enquanto não haviam as máquinas a programação não era problema; quando passamos a ter poucos e pequenos computadores a programação tornou-se um problema moderado, e agora que temos computadores gigantescos a programação passou a ser um problema igualmente gigantesco. Nesse sentido a indústria eletrônica não resolveu um único problema; ela criou problemas – ela criou o problema de como usar seus produtos. Em outras palavras: tão logo a potência das máquinas disponíveis cresceu por um fator maior que mil, a ambição da sociedade em aplicar essas máquinas cresceu em proporção, e o pobre programador acabou se situando nesse campo explosivo de tensão entre fins e meios.”
Veja, ele diz que a programação se tornou um problema gigantesco. Só que nesse trecho do artigo ele estava se referindo aos anos 50 do século XX!
Em outro trecho, Djikstra fala sobre a importância da legibilidade de programas. Esse foi o tema do meu trabalho de graduação, inclusive. No livro Refatoração : Aperfeiçoando o Projeto de Código Existente, de Martin Fowler e Kent Beck, há uma frase que adoro: “Qualquer tolo pode escrever um código que um computador entenda. Bons programadores escrevem código que humanos podem entender”. Logo abaixo você vê que Djikstra concorda totalmente com isso:
“O programador competente é plenamente consciente do tamanho estritamente limitado de sua própria cabeça; portanto ele aborda a tarefa programação com muita humildade e dentre outras coisas ele evita como a praga os truques astutos. No caso de uma conhecida linguagem conversacional, eu tenho dito que tão logo a comunidade é equipada com o terminal, um fenômeno específico ocorre, cujo nome é bem estabelecido; é chamado “uma linha”. Tal fenômeno assume duas formas: um programador coloca um programa de uma linha na mesa de outro e diz orgulhosamente o que o programa faz acrescentando ‘você consegue codificá-lo com menos símbolos?’ ─ como se isso fosse de alguma relevância conceitual ─ ou diz apenas: ‘adivinhe o que ele faz!’. Dessa observação temos de concluir que essa linguagem, como ferramenta, é um convite aberto aos truques astutos; embora seja precisamente isso que explicaria seu atrativo, isto é, para aqueles que gostam de mostrar quão inteligentes são, considero uma das coisas mais condenáveis que podem ser ditas a respeito de uma linguagem de programação.”
É muito legal perceber que você consegue fazer com 1 linha de código o equivalente a 5 ou 10 linhas. Também é legal saber que você pode otimizar a execução de determinado trecho de código em 0,1s. Mas os respectivos problemas são: de nada adianta ter uma só linha de código que ninguém entende; não adianta fazer algo pontual mais rápido se o custo disso não afetar o conjunto da aplicação.
Compreender o software é muito importante para controlá-lo. O controle está ligado a manutenção do software, que é uma atividade que custa muito mais caro do que o seu desenvolvimento. Por isso que o desenvolvimento em um bom projeto e uma boa arquitetura implicam na redução de custo de manutenção. Quanto mais flexível e legível for o o seu software, mais fácil será acrescentar e alterar funcionalidades nele.
Potência não é nada sem controle. Se faltar alguma imagem à sua mente, assista ao desenho Carros da Pixar quando Doc Hudson desafia o Relâmpago McQueen para uma corrida onde tem uma curva na estrada.
[1] http://www.ibm.com/developerworks/rational/library/4700.html
[2] https://sites.google.com/a/integra.ufjf.br/professor-joao-carlos/t10.doc?attredirects=0









