Padronizao de Metodologias de Desenvolvimento de Software na Diviso de Ensino do CPD da UFRGS

Thiago Stein Motta Centro de Processamento de Dados Universidade Federal do Rio Grande do Sul
thiago@cpd.ufrgs.br Resumo: Esse artigo trata sobre o processo de padronizao da forma de desenvolvimento do grupo de programao PHP da Diviso de Ensino do CPD da UFRGS. Discorre sobre um breve histrico das tentativas de seguir nessa direo e conta como, finalmente, um padro foi definido e aceito por todos do grupo. 1. Introduo Em geral, pessoas possuem algumas diferenas entre si; elas pensam e se portam de formas diferentes. Esse panorama no poderia ser diferente em se tratando, tambm, de tcnicas de programao. Seja por ter aprendido de um jeito, ter lido recomendaes em algum repositrio ou simplesmente por ter determinada preferncia, um indivduo escolhe uma forma especfica de programar, e ela, de modo geral, no compartilhada por todos os demais com os quais esse convive. Isso acontece, especialmente, em ambientes cuja rotatividade de programadores grande, como acontece na maioria das empresas e Universidades que se utilizam de bolsistas. Entretanto, justamente por existir essa alternncia frequente no grupo de desenvolvimento, no interessante para o rgo empregador que a programao seja feita de uma forma despadronizada, pois, sendo assim, h uma dificuldade muito maior para um desenvolvedor seguir programando em um cdigo j iniciado por outro. Mesmo que boas prticas de programao como documentao de mdulos e cdigo estruturado sejam seguidas por todos, muito mais simples para um desenvolvedor dar manuteno a um cdigo que seguiu os mesmos padres que ele prprio segue. Da mesma forma, desenvolvedores iniciantes tm mais facilidade de aprender a forma de programar do rgo se apenas um padro seguido. Sabendo disso, o grupo do Departamento de Sistemas de Informao (DSI) do CPD da UFRGS se preocupa, h pelo menos cinco anos, com esse assunto e tem tentado estabelecer padres e boas prticas de desenvolvimento dentro do setor. Contudo, aps diversas tentativas fracassadas, somente agora um padro foi institudo dentro da Diviso de Ensino do DSI. 2. Tentativas Anteriores Conforme foi frisado, h cinco anos j havia a vontade de se buscar uma forma comum de desenvolver os sistemas da UFRGS. Como muito frequente que um sistema precisa de manuteno seja corretiva ou expansiva era desejo comum que os cdigos fossem produzidos de forma a poderem ser facilmente entendidos e modificados por qualquer desenvolvedor. Entretanto, a realidade estava muito longe disso at pouco tempo atrs. Ncleos de programadores desenvolviam padres prprios e as diferenas de programao iam desde a forma como eram realizadas (estrutural ou orientada a objetos), passando pela nomeao de variveis e at mesmo na quantidade de tabulaes e espaos que possua cada indentao de bloco, bem como na IDE utilizada. Diversas reunies foram marcadas, envolvendo as trs Divises de desenvolvimento do DSI: a de Ensino, a de Pesquisa e a de Extenso. Foram incontveis horas de apresentaes de frameworks, Design Patterns, padres de design grfico e bibliotecas para reuso de cdigo, seguidas de outras tantas horas de discusso acerca dos contedos apresentados. Naturalmente, sempre surgia uma ideia nova que parecia promissora e muitos ficavam pensando que o problema estava, enfim, solucionado. No entanto, os percalos encontrados na hora de implantao das teorias, e a resistncia de alguns, sempre se opunham chegada da soluo definitiva. No final, mesmo que as ideias fossem postas em prtica por uma semana ou duas, logo surgiam manutenes urgentes a serem realizadas e, no fim, tudo voltava a ser como anteriormente. Algumas metodologias foram adotadas, como o uso de tcnicas de MVC e formas indicadas de documentaes, mas um padro de desenvolvimento ainda precisaria ser estabelecido. 3. Rumo Padronizao Com a diminuio da rotatividade de desenvolvedores, devido entrada de programadores concursados e com o aumento do tempo mdio que os bolsistas permaneciam junto ao CPD, o nmero de

formas de desenvolvimento foi diminuindo e, com a adoo quase que total, dentro da Diviso de Ensino, da metodologia MVC, em conjunto com a criao da Equipe de Design do CPD, as interfaces vinham ficando cada vez mais semelhantes, e fez com que os antigos desejos de padronizao de programao fossem deixados um pouco de lado. Porm, ao final de uma reunio com propsitos bem diferentes, o assunto da padronizao da forma de desenvolvimento foi introduzido e a ideia foi prontamente aceita por todos. Decidiu-se, entretanto, que ao menos em princpio o padro seria estabelecido somente dentro da Diviso, para que, dessa forma, houvesse uma maior chance de que um consenso fosse alcanado. Foi marcado um encontro numa data em que todos desenvolvedores tinham disponibilidade, e o primeiro passo dado foi conhecer a forma com que cada ncleo de desenvolvimento da sala vinha programando. Para isso, um roteiro foi criado e cada ncleo apresentou aos demais as prticas que adotava. No roteiro constavam as metodologias utilizadas, a maneira de nomeao de variveis, a forma de escrever as consultas SQL, a subdiviso de pastas por projeto etc. Nessa primeira etapa no foi discutido nenhuma padronizao, muito embora j tenham sido feitos comentrios sobre uma abordagem especfica ou outra. Era necessrio, primeiramente, que todos conhecessem a forma de todos outros trabalharem e, mesmo que apenas para essa apresentao, a reunio foi longa. Aps as apresentaes, os dados coletados foram tabulados e analisaram-se as semelhanas e diferenas na forma de cada um programar. Muitas eram as semelhanas entre determinados ncleos, mas havia tambm algumas diferenas significativas. Marcou-se um novo encontro para dali a uma semana e, durante este perodo, uma forma padronizada foi definida a partir dos dados obtidos, de forma a agregar as melhores prticas e ideias de programao e, tambm, de maneira que no fosse feita uma mudana significativa na forma de cada um trabalhar. Em geral, constatou-se que todos programavam de forma parecida, tentando empregar conceitos de MVC, Orientao a Objetos e Design Patterns; s foi necessrio definir melhor de que forma essas tcnicas deveriam ser empregadas. No segundo encontro, o candidato a padro foi apresentado e, sobre ele, todos foram convidados a opinar. Questes bsicas como nomes de arquivos, pastas e variveis foram simples de serem regrados, pois no significavam uma grande mudana para ningum. Contudo, outros critrios foram mais problemticos e renderam bastante discusso, como a forma de se utilizar MVC (e sua respectiva estrutura de diretrios) e a maneira de se escrever consultas SQL. Ao final do encontro, boa parte da metodologia j havia sido definida e um terceiro encontro foi marcado para que fossem concludas as definies iniciadas. J a partir desse dia, alguns desenvolvedores comearam a utilizar as prticas definidas, alterando os cdigos em que estavam trabalhando e at mesmo alguns sistemas j construdos. Era o indcio de que o sucesso da padronizao viria em breve. Na terceira reunio, todos j haviam pensado bastante sobre o assunto e j estavam prontos para chegar a uma concluso. Aps a retomada do que j havia sido visto, os assuntos restantes foram tratados e, muito rapidamente, estabeleceram-se os padres que faltavam. Ao final do encontro tudo estava definido e apenas na questo do MVC tiveram de ser adotadas duas formas de programar, porm semelhantes: uma utilizando Orientao a Objetos exclusivamente e outra com algumas parte de cdigo estruturado. 4. Concluses e Trabalhos Futuros Com uma metodologia padro a ser seguida ser muito mais simples a definio de um Guia do Desenvolvedor a ser criado em breve. A partir desse guia, que conter a metodologia padro definida e exemplos de como utiliz-la, ser muito mais simples instruir um programador novato no setor, mesmo que ele tenha o mnimo de experincia. Alm disso, j est marcada uma nova reunio para que alguns desenvolvedores apresentem as tcnicas que eles utilizam em determinadas ocasies e que foram definidas como padro, como nas invocaes Ajax. Dessa forma, com trabalho em conjunto, ser facilitada a migrao das formas de programar. Com base no sucesso dessa experincia, pensa-se em apresentar, mais tarde, a metodologia escolhida para os demais setores. De qualquer forma, mesmo que o padro seja seguido somente na Diviso de Ensino, seu estabelecimento j pode ser considerado uma grande conquista, que ir nortear os rumos da programao no CPD para um caminho de maior qualidade e eficcia na programao, onde o desenvolvimento colaborativo prtica to desejada nas mais diversas reas de conhecimento poder ser empregado com muito mais facilidade.