A importância do código-fonte

Talvez o nome deste post seja estranho, em um blog tão focado à programação. Porém, vale um pouco de história.

De duas semanas para cá, estou escrevendo um artigo para tentar apresentar no Workshop Brasileiro de Métodos Ágeis. Inclusive, eu recomendo a todos que trabalham a um certo tempo com uma linguagem, tecnologia, etc, que escrevam um artigo sobre o assunto, mesmo que não seja em formato científico, só para organizar as idéias. Ajuda bastante a focalizar seus próximos passos. Porém, esse não é o assunto. O assunto é bem simples, na verdade:

Design de Software.

Tentei traçar as origens da tal “metodologia em cascata”, e não consegui. O artigo mais antigo que eu cheguei foi de Winston Royce, em 1970 (sim, 1970 – é difícil de acreditar que a maioria das metodologias de desenvolvimento de software de hoje se baseiam numa idéia que surgiu a 40 anos atrás), e Royce sequer nomeia a metodologia. Na verdade, ele apresenta o desenho típico de uma metodologia em cascata e comenta: “a implementação acima é arriscada e convida à falhas”. Seria possível que, na informática, alguém em 1970 apresenta o modelo que mais tarde seria chamado de “cascata”, diz para as pessoas não usarem, e as pessoas começam a usá-lo? Bom, sendo informática, eu não duvido de nada (nem de doutores em engenharia de software citando que até uma metodologia em cascata é melhor do que as metodologias ágeis – sim, eu ouvi isso). Enfim…

Mas, voltando ao tópico – a metodologia que Royce propôe enfatiza a documentação. Mais tarde, essa documentação seria unificada pela UML, e uma série de estudiosos iriam “contribuir” para a tal UML, criando mais e mais diagramas… além daquelas coisas obsoletas, tipo fluxograma, “teste de mesa”, etc etc. Aqui, vale a pena citar Jack Reeves, que pergunta em seu artigo (de 1992): “O que é design de software?”. O artigo é extenso, mas transcrevo umas partes aqui:

O objetivo final de qualquer atividade de engenharia é algum tipo de documentação. Quando um trabalho de design foi completado, a documentação é entregue à manufatura. Eles são um grupo completamente diferente, com habilidades completamente diferentes do time do design. Se a documentação realmente representa um design completo, o time da manufatura pode proceder para construir o produto. De fato, eles podem proceder para construir uma grande parte do produto, sem qualquer intervenção dos designers. Depois de revisar o ciclo de desenvolvimento de software, da forma que eu entendo, eu concluo que a única documentação de um software que, na verdade, satisfaz o critério de uma documentação de design é o código-fonte.

Pode parecer absurdo (especialmente para quem não estuda metodologias ágeis), mas a linha de raciocínio do Reeves faz sentido. O que não faz sentido é pensar que a indústria, pelo menos os que não trabalham seriamente com metodologias ágeis (sim, existem pessoas que procuram na metodologia ágil uma série de processos que, magicamente, transformariam seu desenvolvimento em ágil), tiram completamente o foco do desenvolvimento do software da codificação. De fato, quando você vê a maioria das metodologias tradicionais de desenvolvimento, o processo de codificação é o mais isolado – como explicar, então, que seja o mais demorado? Como justificar que desenvolvedores precisem fazer horas e horas extra para terminar seus trabalhos, e as equipes de teste e levantamentos de requisitos não?

Para fazer um compacto, vamos imaginar uma situação hipotética: Imagine que, em seu trabalho, há um servidor que contém todos os códigos-fonte dos programas. Numa outra sala, há um armário com toda a documentação dos códigos-fonte. Agora, imagine duas situações: na primeira, a sala com a documentação pegou fogo, e todos os diagramas foram perdidos. Na segunda, o servidor explodiu, e todo o código-fonte foi perdido. Em qual das duas situações o prejuízo é maior?

É preciso, de uma vez por todas, devolver a ênfase do desenvolvimento do software aonde ela é de direito – o código-fonte. Se você jogar a UML num servidor, isso não vai virar um programa, não importa quantos mil diagramas você fizer. Vi, outro dia, um artigo que falava de UML executável, e o artigo dizia: “estamos próximos, em cinco anos veremos sistemas inteiros desenvolvidos só usando a UML”. Porém, o artigo era de 2003, e até hoje não temos sequer um protótipo dessa maravilha. Aliás, “maravilha” entre muitas aspas: será que escrever um sistema complexo apenas usando a UML é uma coisa boa? Ou será que uma linguagem de programação é, realmente, a ferramenta que deve ser usada no desenvolvimento de código? Vale lembrar que, usando Ruby por exemplo, criar um programa que faz engenharia reversa e extrai os métodos de uma classe (para transformar isso em UML) é mais fácil que fazer o contrário. Agora, já em linguagens mais estritas… isso é precisamente o que eu chamo de criar dificuldades para vender facilidades – ao invés de usar linguagens simples, reflexivas, elegantes, usa-se uma linguagem assumidamente difícil de se programar, para que se possa usar ferramentas CASE, diagramas complexos, uma ou outra parafernália de coisas tudo porque, no geral, eles são “mais simples” do que a linguagem complexa.

Outra coisa que tem me revoltado faz algum tempo já: o mercado, especialmente academicamente falando, só fala em Java. Outros, só falam em .NET. Uma pequena porcentagem trabalha com Python, Ruby, e outras linguagens. Afinal, qual o medo que todos têm? Basta um pouco de exercício de lógica para quebrar aquelas velhas histórias do tipo “ah, mas e se essa linguagem der problema mais na frente…”: Imagine que um projeto demorará dois anos, em uma linguagem X. Se a linguagem Y permitir que o tempo de desenvolvimento caia pela metade, você escreverá o sistema em um ano e SE o programa der problema, você terá mais um ano inteiro para resolvê-lo.

Me dá medo a área de informática, porque aparentemente qualquer pessoa pode falar o que quiser (como se alguém que nunca estudou medicina chegasse a um médico e lhe disesse como operar alguém). Além disso, no Brasil, a gente valoriza muito os títulos – pegue Kent Beck (criador do XP e organizador do Test-Driven Development), por exemplo: ele possui apenas mestrado. Ward Cunningham (Criador da primeira Wiki), idem. Já aqui, valorizamos tanto os títulos, os doutorados e pós-doutorados, e vemos doutores que sabem programar em três linguagens de programação – enquanto Fred George, que também possui mestrado no MIT (e nenhum doutorado), conta SESSENTA linguagens.

A propósito, estou estudando Haskell. Será minha vigésima-primeira linguagem. E, tou apanhando pacas, porque em Haskell, o que muda não é só a sintaxe, mas sim o paradigma inteiro. Fecho o artigo dizendo: “se você sabe Delphi, VisualBasic, VB.NET, Java, C#, você efetivamente só sabe UMA linguagem”. Mude paradigmas. Aprenda algo funcional, procure aprender Lisp, Haskell, Ruby, Prolog, Smalltalk. Tente programar em uma linguagem procedural, não orientada a objetos. Isso dá uma nova visão sobre programação e, especialmente, vai evitar que no futuro, você defenda com unhas e dentes apenas uma linguagem. Até porque, uma linguagem melhor que todas as outras não existe. Nem mais segura, ou mais rápida. Como um exemplo besta, hoje estava otimizando um código no meu trabalho, em Rails. Uma tela estava demorando 26 segundos para carregar. Depois da otimização, a tela passou a carregar em 750 milisegundos. Não foi necessária nenhuma biblioteca em C/C++, nem nenhum outro artifício – apenas, re-escrever código e seguir boas práticas. Porque, no fim das contas, o código é o que importa, não a linguagem, não o framework, não a UML ou os diagramas, ou ferramentas.