quarta-feira, junho 14, 2006

[Leonardo Garcia] Software livre e processos de qualidade de software

Por Leonardo Garcia

A idéia deste post surgiu das duas reclamações que o Miguel já fez neste blog a respeito da falta de documentação em projetos de Software Livre (uma destas reclamações está aqui) e de algumas conversas que tive com ele sobre este assunto baseadas na recente experiência que estou tendo no meu trabalho.

Bom, antes de mais nada, concordo com o Miguel de que falta documentação na maior parte dos projetos de software livre que eu já vi. Quer dizer, depende do que nós estamos acostumados a chamar de documentação. O meu referencial de documentação de um projeto vem dos conhecimentos de Engenharia de Software que eu tenho e da vivência com outras Engenharias. Deste ponto de vista, na minha opinião, documentação é tudo aquilo que te ajuda, de alguma forma, a explicar um sistema, como ele funciona, quais são suas funcionalidades e, talvez o mais importante, como usá-lo de uma maneira correta e eficiente, ou seja, para que o sistema serve.

Acho que a grande falha neste sentido para muitos projetos de software livre está no fato de que muitas pessoas da comunidade acreditam que a documentação é o código-fonte, afinal, que melhor maneira haveria para obter informações a respeito de um sistema do que simplesmente poder ver como o sistema funciona nos mínimos detalhes? A falha neste pensamento, comparado ao que eu disse no parágrafo anterior, está na palavra "ajuda". A documentação deveria ajudar a entender o sistema e olhar o código fonte nem sempre ajuda muito no início. Em sistemas grandes como o Eclipse, pode-se demorar uma semana ou mais para se pegar o "jeito" e conseguir, a partir de então, obter informações relevantes do sistema a partir do código-fonte. Em projetos grandes, uma semana pode não ser muito tempo, mas isto inibe, por exemplo, que uma pessoa que nunca tenha feito um plugin para Eclipse se aventure a fazer um plugin que lhe pareça útil... simplesmente porque o tempo que ela vai gastar para entender a arquitetura do sistema lhe dá apenas duas opções: ou ela vai utilizar uma parte do seu tempo livre para entender o funcionamento do sistema ou vai se virar sem a funcionalidade que ela queria implementar e, provavelmente, distribuir gratuitamente para uso-fruto do resto da comunidade.

Outra questão importante é: se há documentação, muitas vezes ela não é de fácil acesso. É muito comum os sites que hospedam projetos de software livres terem estruturas complicadas, pouco amigáveis. Apesar de eu achar este um detalhe menor, é importante citá-lo também, pois isso leva com que pessoas que trabalham com software livre se comportem de uma maneira diferente de pessoas que, por exemplo, trabalham com software proprietário.

Quando eu programava em tecnologias proprietárias, minha maior fonte de referência não era o Google. Era muito mais fácil achar referências e soluções para meus problemas na própria documentação gerada pela empresa desenvolvedora do sistema. Tive esta experiência, por exemplo, com Visual Basic 6. Não quero aqui discutir as virtudes ou não desta linguagem e muito menos as virtudes ou não da Microsoft (isto dariam vários outros posts e este já vai ficar grande o suficiente). No entanto, a Microsoft fornece uma documentação muito completa, rica em exemplos e de fácil navegação e busca. Simplesmente isto fazia com que eu dificilmente recorresse a sites específicos a respeito de VB6, ou a fóruns ou ao próprio Oráculo, digo, Google. Isto também faz com que VB6 seja, ainda hoje, uma das linguagens mais conhecidas e mais utilizadas no desenvolvimento de sistemas, mesmo com todas as suas limitações e com o fim de suporte oficial da Microsoft à linguagem.

Em compensação, todas as vezes que eu trabalho com software livre, "Google is my friend!". Gosto das listas de discussão também, mas acho que elas são mais complicadas de serem utilizadas, pois existe toda uma etiqueta para participação de listas, o que inclui a leitura dos FAQs e perguntas antigas das listas, o que geralmente eu não tenho muita paciência para fazer. De qualquer forma, poderíamos dizer que neste caso a documentação não está escrita formalmente. Se ela existe, é difusa e esta mal catalogada (por melhor que o Google seja, ele não pode ser utilizado como catálogo de nada, até porque o objetivo dele não é este, por enquanto). Isto, na minha opinião, acaba inibindo alguns novos desenvolvedores a experimentarem o software livre. A filosofia de que a documentação é o código-fonte, para estas pessoas, não funciona.

Os mais puristas em relação ao modelo de desenvolvimento do software livre poderão pensar que eu estou exagerando, e talvez esteja mesmo. Mas eu queria chamar atenção para o fato de que talvez um processo mais elaborado de geração de documentação poderia fazer com que projetos de software livre fossem mais bem vistos por desenvolvedores de uma forma geral e pelas corporações também (afinal, hoje grandes empresas também têm papel decisivo no desenvolvimento de projetos de software livre).

Não estou dizendo também que se deva adotar um processo formal de qualidade de software no desenvolvimento de software livre. Este esquema, na minha opinião, não funciona com o modelo de desenvolvimento criado pelas comunidades de software livre. Um processo exagerado de documentação certamente desmotivaria os colaboradores dos projetos livres, mas alguns controles, como os criados, por exemplo, pelo Gforge, poderiam ser interessantes. Isto sem levar em conta alguns argumentos interessantes da comunidade de software livre para a ausência total de documentação nos projetos de software livre. Algumas que eu acho interessante e faço questão de comentar:

- Software de qualidade não necessariamente é feito com processos de qualidade e nem todo software feito com processo de qualidade tem qualidade. Isto é uma verdade indiscutível.

- Processos de qualidade de software como o CMMI focam boa parte do trabalho na definição dos processos pois se a empresa ou o grupo de desenvolvimento tiverem os processos bem definidos, isto significa que, teoricamente, a saída de uma pessoa do grupo e a sua substituição por outra pessoa não deveria interferir na qualidade do software produzido. Isto faz com que as pessoas sejam transformadas em meros recursos, o que, definitivamente, não é a idéia das comunidades de desenvolvedores de software livre, onde os desenvolvedores são os principais atores.

- Espera-se que a comunidade de software livre tenha colaboradores bons. E uma pessoa que não seja boa o suficiente para ler um código-fonte e entendê-lo não agregará nenhum valor ao movimento. Isto, na minha opinião, é uma verdade pela metade. Uma das grandes batalhas de um dos principais representantes do mundo de software livre, o Linux, é que ele seja um sistema operacional mais aceito e utilizado mundialmente. E, para que isto aconteça, é necessário, antes de mais nada, que o sistema seja fácil de usar e seja entendido por pessoas que não fazem nem idéia do que seja um código-fonte. Qual é a melhor maneira de se fazer entender neste caso? Eu acho que uma boa documentação poderia ajudar bastante nesta hora.

- Na comunidade de software livre, boa parte dos problemas que seriam resolvidos com processos de qualidade de software são resolvidos pelo mantenedor do projeto. Sem dúvida nenhuma, o mantenedor é uma figura crucial em projetos de software livre e ele é o responsável, como o próprio nome diz, pelo bom andamento do projeto. Dizer que o processo de desenvolvimento de software livre não possui nenhum processo formal de qualidade pode até ser verdade, mas isso não significa que o mantenedor e seus colaboradores não tenham que definir funcionalidades, recursos, estimar tempo de desenvolvimento e definir milestones e releases do produto. Tudo isto também acontece com software livre.

Em suma, acho que o que talvez falte para o software livre seja pegar algumas poucas idéias dos processos complexos de qualidade de software e tentar aplicar estas idéias de uma forma apropriada à sua realidade. Sei que cada projeto é um caso diferente e que as regras não seriam universais, mas alguns conceitos poderiam ser usados para tentar ajudar a vida não só dos desenvolvedores, mas também dos usuários comuns que queiram propagar a filosofia de ser livre.

[NDA: Leonardo Garcia é Engenheiro de Computação, e foi meu colega de graduação na UNICAMP. Já trabalhou em diversos projetos relacionados a software livre (inclusive já tendo construído sua própria mini distro de linux :-) ) e em diversas empresas e atualmente está no Linux Technology Center da IBM ]

2 Comments:

Blogger Marcos Dumay de Medeiros said...

Ao que me parece, para a maioria dos desenvolvedores de software livre, documentação é algo chato de se fazer.

Isso quer dizer que quem não está fazendo isso a trabalho não documenta ou documenta somente o essencial. O resultado é que, sim, a documentação que vem junto com o software é pouca.
Já os projetos em que as pessoas ganham para trabalhar neles, costumam ter uma documentação grande e bastante completa.

Agora, a idéia do software livre é que qualquer pessoa pode colaborar. Isso vale também para a documentação, existem, por exemplo, vários livros (de graça e pagos) sobre os principais programas livres usados por aí, e muitos destes livros são excelentes. A falta de documentação que vocês estão sentindo provavelmente se deve à falta de experiência em procurar uma fonte. O começo é mesmo dificil, é uma mentalidade comletamente diferente. Por exemplo, a documentação do software proprietário também é faltosa em diversas formas, e vocês nem percebem mais isso porque se acostumaram.

O que estes livros não costumam cobrir, porém, é como modificar o código dos programas. Mas nesse quesito, não dá para comparar com o software proprietário, que simplesmente não deixa você mexer no código... Vale lembrar que a organização de um projeto livre é completamente diferente da de um proprietário, a começar pelos requisitos, que não vêm de uma análise, mas de diversas listas diferentes e muitas vezes conflitantes. Nenhum método clássico de engenharia de software é capaz de lidar com isso, assim, o que acaba aparecendo é uma organização política, e não técnica. Sem requisitos formalizaveis, o software não pode passar pela etapa de projeto (release early) e tem que iterar diversas vezes pela prototipação (release often) até amadurecer (ele não fica "pronto", mas "maduro"). Nessas iterações, a todo o tempo o (que seria) projeto do software muda. Documentar algo assim é um dificílimo, o que acaba levando as pessoas a usar somente documentação automática (doxygen) e , no máximo, introduções bastante pequenas apresentando o código.

6/14/2006 07:54:00 PM  
Blogger Miguel Galves said...

Marcos, eu realmente não acho que o problema seja de falta de experiência em procurar informações. Acredite, eu sei procurar documentação e informações importantes, e em geral encontro o que preciso..e acho que isso vale pra você tambem e pro Leonardo. O grande problema nao é encontrar, e sim o tempo que se leva pra isso. Essa questão fica mais importante quando se leva em conta que o software livre está no centro de discussões importantes, e cada dia aumenta sua participaçãoo dentro de empresas, governos e outros. Passar dias atras de uma informação simples, por mais que se saiba procurar, não é muito produtivo

Estamos todos de acordo, documentar é chato. Mas é necessário. Grandes projetos devem se organizar pra isso, encontrando as ferramentas que mais se adequem ao grupo. Recentemente, um colega meu chamado Alexandre Barbosa postou no seu blog um artigo sobre o esquema de documentação que ele implantou na empresa dele baseado em Wiki. A coisa deu tão certo que até gente fora da área de computação da empresa se aventurou a documentar processos internos.

6/15/2006 11:11:00 AM  

Postar um comentário

Links to this post:

Criar um link

<< Home