ping web

Retrospectiva 2009 do i-Educar

Posted in desenvolvimento, i-Educar, software livre by Eriksen Costa on janeiro 15, 2010

Não perdendo o bonde do tempo, ao som de Bittersweet Symphony (The Verve), vejo que 2009 foi muito bom para o i-Educar.

Para quem não conhece, o i-Educar é um sistema de gestão escolar livre. Foi desenvolvido pelo Centro Tecnológico de Informação e Modernização Administrativa (CTIMA) da Prefeitura Municipal de Itajaí/SC. Tornou-se software livre no final de 2008, quando foi disponibilizado no Portal do Software Público Brasileiro (SPB).

Até março do ano passado eu desconhecia o i-Educar assim como o SPB. Foi então que surgiu um convite para trabalhar na Cobra Tecnologia com o objetivo de dar suporte aos clientes e de ajudar no desenvolvimento do projeto. E o melhor de tudo: com liberdade para publicar as melhorias realizadas na aplicação.

A situação do projeto não era das mais favoráveis. Com a visibilidade do anúncio, houve uma grande procura no Portal que rapidamente se transformava em frustração devido as dificuldades do processo de instalação e da falta de suporte e de documentação. A falta de padrões no projeto era de enlouquecer: muita gente (a maioria, com boas intenções) corrigiam os problemas do software e publicavam em diretórios públicos sem versionamento! Isso deu no nascimento a diversos forks dentro da própria comunidade, todos eles sem histórico algum das correções.

Foi então com a ajuda do Pedro Simões (analista, Ministério do Planejamento) e do pessoal da Cobra (PajéLunix e da Miris) que consegui entender a situação do projeto. Então, comecei a aplicar algumas ideias simples, copiadas ou inspiradas em outros projetos de software livre. O ano foi bastante ocupado mas teve saldo bastante positivo.

Das diversas tarefas executadas no ano, a fundamental foi ter estabelecido o versionamento do i-Educar e de usar efetivamente o versionamento de código. Usamos atualmente um esquema com três números X.Y.Z onde X é a versão maior, Y é uma release com mudanças arquiteturais ou novas funcionalidades e Z é a release menor, podendo conter correções de bugs a erros de digitação.

A release tornou-se um processo automatizado. Para a primeira versão (a 1.0.0), apenas compactei o diretório com os arquivos-fonte da aplicação em zip e gzip para distribuição. Desde então, cada release nova foi gerada automaticamente usando o Phing. Até os banais arquivos CHANGELOG.txtREADME.txtLICENSE.txt não existiam e foram incluídos, informando as atualizações da release (com os devidos créditos), os procedimentos de instalação e a licença do software (GPLv2), respectivamente.

O banco de dados ganhou uma lipo. Ao instalar o i-Educar, o usuário ganhava (não que isso o fizesse feliz) uma aplicação com dezenas de cadastros: alunos, professores, quadros de horários além dos dados em logs no banco de dados, entre os quais alguns remanescentes da Secretaria de Educação de Itajaí. Como consequência, as pessoas reclamavam que tinham que apagar diversos dados no sistema antes de podê-lo colocar em produção.

Além da limpeza geral no banco, este foi devidamente versionado! Como o i-Educar não possui uma API interna de schema de banco de dados, um arquivo SQL plano é distribuído. Isso não só tornava a criação de uma nova release um pesadelo: como garantir que uma alteração no schema ou que um dado necessário para a inicialização da aplicação seria corretamente distribuído? Com o DbDeploy (uma task do Phing), criamos pequenos arquivos com as instruções SQL necessárias para modificar o banco de dados (chamados de delta files).

Apesar de já ter sido disponibilizado publicamente com vários bugs, conseguimos inserir testes de software automatizados no i-Educar. Integramos o framework PHPUnit, membro da família de frameworks xUnit, e temos uma minúscula parte do código coberta por teste (não chega a 1% no branch atual de desenvolvimento). A grande maioria dos testes são unitários mas alguns são funcionais, como os testes Selenium que executam no navegador.

Esse passo foi fundamental para diversos outros, como a consolidação dos padrões de codificação e a criação de novoscomponentes reusáveis (no contexto de desenvolvimento do i-Educar). O objetivo desses componentes é o de agilizar na padronização e na criação de módulos que estendam as capacidades do i-Educar, sem que seja necessário grandesrefactorings no core da aplicação. É assim que projetos como WordPressDrupalJoomla! além dos mais corporativos SugarCRMMagento possibilitam o desenvolvimento de novas funcionalidades. Este é um assunto em que gostaria de contar com a colaboração dos programadores-membros da comunidade. Vai ser uma tarefa bastante árdua especificar uma API para módulos! É inconcebível que um projeto de sofware livre seja pensado como um grande e abrangente monolíto de funcionalidades. Precisamos caminhar para a direção da extensibilidade e da interoperabilidade infinita. O i-Educar precisa se tornar mais simples de ser customizável e precisa também conversar com outros sistemas e com a web 2.0 (detesto hypes!).

O código continua sendo a coisa que mais me desagrada no i-Educar. Existe muita duplicação! Consigo perceber facilmente grandes trechos de código copy n’ paste. Isso provavelmente ocorre devido a problemas de educação dos desenvolvedores originais. Os sinais são claros: pouco conhecimento de orientação a objetos junto com a baixa barreira de entrada da programação PHP.

A ausência do uso das capacidades OO do PHP 5 (todo o código até então usava a OO do PHP 4) como classes abstratas, interfaces e de design patterns simples (como SingletonFactory, entre outros) demonstra alguma falta de intimidade com a linguagem. Some a isso grandes trechos de código comentados, erros de ortografia no código-fonte e identação usando <tab> e perceberá que não é nada trivial criar uma comunidade de desenvolvedores para um projeto com um legado (código fonte herdado de alguém) deste.

Estamos avançando aos poucos já que nem sempre é fácil introduzir testes em código legado (pelo simples motivo do código não ter sido escrito para ser testável). O trabalho é metódico: primeiro, coloca-se o arquivo nos padrões de codificação, faz o commit e só depois aplica-se o refactoring. É a única maneira de se ter um diff visualizável, como o da correção de um bug bobo que impedia o acesso a uma página, mesmo que o usuário tivesse permissão para tal, porque a metainformação da página usava o código de outra funcionalidade.

Além da lenta introdução de testes, refactorings maiores serão necessários, afim de reduzir a duplicação exagerada de código. É nessa duplicação que se encontram a maioria dos bugs do i-Educar. Sendo conservador, considero que cerca de 40% do código da aplicação seja duplicado. O phpcpd me informa cerca de 18% (o que já é bastante alto) mas este analisa apenas duplicações dentro de um mesmo arquivo.  Segundo os dados do phploc para a tag 1.1.0-beta2, temos 257.279 linhas de código-fonte (excluindo as linhas de comentários). 40% equivale a 102.911 e 18% a 46.310. É bastante código, o que significa mais tempo gasto com a manutenção do projeto! Mal comparando, o SugarCRM, por exemplo, é um sistema CRM completo com apenas 108 mil linhas (de acordo com as métricas da rede Ohloh).

A única área que avançou a passos mais curtos foi a documentação. No início houve um consenso em manter a documentação voltada aos usuários finais dentro do próprio SPB e a voltada aos desenvolvedores/administradores de sistemas no Trac. Mas manter a documentação, mesmo que tenha conteúdo e público-alvo distintos nos dois ambientes sempre me pareceu contra-produtivo. Eu disponibilizo toda a documentação no Trac, por dois motivos (a) o wiki do Trac é muito mais prático que o wiki do OpenACS, software que suporta o Portal e; (b) no Trac, a informação é indexável para os buscadores já que não exige login para acessar as páginas do wiki.

Outro motivo que me preocupa em seguir por esse caminho é o crescimento da própria documentação. O i-Educar possui diversos cadastros e vários comportamentos não documentados. Com o trabalho no refactoring do código e gradual substituição de funcionalidades core para módulos, manter a documentação sincronizada e versionada com a evolução da aplicação somente via wikis será tarefa ingrata. A primeira alternativa que vejo é a de criar a documentação usando Docbook XML, versionando-a normalmente no repositório e exportando-a para HTML e PDF, por exemplo.

No geral, o que foi feito em 2009 foi bastante animador, face aos problemas já apontados. Uma prova disso foi a grande procura nas atividades do i-Educar durante o I Encontro Nacional do Software Público, realizado em Brasília. Mais de 300 pessoas compareceram nas duas apresentações e nos dois mini-cursos durante o evento, o que demonstra que existe uma boa demanda por serviços com o i-Educar. A apresentação “O Estado do Projeto i-Educar” foi gravada e está disponível para download no Archive.org. Outra medida tem sido o crescimento aritmético constante de membros cadastrados na comunidade, mesmo com a entrada de outros projetos no SPB que também incluem funcionalidades de gestão escolar. Passamos de 2.200 membros para mais de 6 mil em 9 meses.

Existe muito trabalho a fazer. Além de todo o trabalho técnico descrito acima, precisamos trabalhar que os membros cadastrados na comunidade i-Educar se comportem como membros de um projeto de fato. Para isso não basta clamar por participação, é preciso criar as condições necessárias para que a comunidade floresça e tome para si o projeto. É para isso que investimos em melhoria de código e que estamos desenvolvendo novas APIs e componentes.

A inteção é criar um ecossistema que dê saúde ao projeto, que complete o ciclo de feedback, gerando novas funcionalidades (no caso dos módulos poderíamos chamar de pequenas revoluções), documentação, oportunidades de negócios e economia (para o país). A lógica é simples: com um software extensível e melhor documentação, um prestador de serviço ganha subsídios para capacitar-se e para oferecer serviços especializados no software. Os municípios se beneficiam pois o i-Educar elimina o custo da aquisição de licença (já ouvi falar em projetos com custos de até R$ 1 mi/ano, sendo que a licença correspondia entre 50% a 80% do total) e a sua plataforma não demanda aquisição de software proprietário. Ao customizar ou melhorar algum aspecto do software por conta da prestação de um serviço, o prestador retorna as melhorias ao projeto e instantaneamente todos os outros municípios passam a contar com a melhoria sem custos adicionais.

Demanda já temos, fato comprovado pelo crescimento constante dos membros cadastrados. Se evoluirmos o i-Educar, poderemos oferecê-lo a instituições particulares (desde escolas de nível básico a faculdades, universidades e centros de treinamento) e ONGs. O horizonte é amplo!

Criar condições favoráveis ao desenvolvimento do ecossistema também demanda bastante tempo para comunicação. Ainda pecamos na comunicação, um exemplo foi não ter publicado de forma adiantada as atividades da comunidade i-Educar no I Encontro Nacional do Software Público. Outro exemplo é a falta de notificação sobre o que está sendo desenvolvido e para quê, ao qual temos este ano para corrigir. Hoje, o caminho mais rápido para se manter informado é através do Twitter do projeto (@iEducar).

2009 teve um saldo positivo. Vamos continuar trabalhando para que todos se beneficiem. Bem vindo, 2010!

Tagged with:
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 180 outros seguidores