Extreme Programming (usualmente chamado de XP) é uma “nova” metodologia para o desenvolvimento de programas e que tem conquistado muitos adeptos recentemente.
Mas o que de fato há de novo nessa metodologia? O que podemos ganhar com ela? Como podemos aplicar seus preceitos fundamentais ao desenvolvimento de jogos? Quais as suas relações com o método de se desenvolver programas usados pela filosofia GNU, que também tem repercutido muito nesses últimos tempos?
É para tentar responder tais perguntas e, acima de tudo, desmitificar o XP que escrevemos esse pequeno texto. Para isso, vamos explicar inicialmente alguns dos conceitos que julgamos fundamentais no XP, mostrando aplicações e possíveis modificações a produção de jogos, que sabemos possui suas próprias particularidades.
A metodologia XP pode ser resumida como uma coletânea de boas práticas no desenvolvimento de programas, que normalmente todo desenvolvedor profissional já conhece, mas que raramente encontrávamos em prática sistematicamente.
É esse, provavelmente, o grande mérito dessa nova metodologia: ela sistematizou a aplicação de procedimentos reconhecidamente produtivos e chamou atenção para isso. Entre esses procedimentos estão todos os seus pilares teóricos: a coletânea de histórias dos usuários, a programação aos pares, os testes sistemáticos e o acesso total do código a todos os desenvolvedores.
COLETÂNEA DE HISTÓRIAS DOS USUÁRIOS
Todos sabemos que um bom programa deve satisfazer as necessidades do usuário. Entretanto, outras técnicas tradicionais como as de se criar inicialmente uma interface e design com a ajuda do usuário para então codificar-se as rotinas propriamente ditas têm como grande problema o fato de que inúmeras vezes o usuário acaba esquecendo alguns itens importantes e/ou incluindo alguns que ele julga serem necessários em um sistema, sem de fato estar pensando em sua utilização. Com isso, são gerados muitos ciclos de retrabalho, com elevados custos.
Com a metodologia XP, tenta-se manter essa idéia de voltar-se para as necessidades do usuário, mas de uma forma indireta, evitando assim muito do retrabalho. Para isso, são documentadas histórias dos usuários sobre como utilizam o sistema e/ou realizam suas tarefas, e estas são então usadas como guia para o trabalho em si.
Esse tipo de pensamento está também incluído, em geral, na filosofia de desenvolvimento GNU. Os programas assim desenvolvidos costumam justamente surgir da necessidade de alguém automatizar uma tarefa e/ou mudar a forma como ela é feita com base em alguns relatos. Ainda, a manutenção de tais programas costuma contar com a cooperação de diversos usuários que utilizam o programa e fazem assim a requisição de novas funcionalidades, em um ciclo parecido com o descrito, embora mais informal e certamente mais distribuído.
Esse é, também, o ponto mais complicado para uma aplicação imediata à programação de jogos. Enquanto continua válido para aspectos comuns do desenvolvimento de jogos, como as partes técnicas de entrada de dados, configuração dos jogos, etc.; esse ponto é muito dificilmente aplicável ao núcleo do jogo e sua história em si, pois um jogo assemelha-se nesse ponto mais a uma “obra de arte” do que a um software comum.
PROGRAMAÇÃO AOS PARES
É, talvez, o ponto em que realmente poderíamos dizer que a metodologia é nova. Encontrar programadores trabalhando realmente aos pares, codificando juntos uma mesma parte de um projeto é realmente raro. Certamente é mais raro ainda na filosofia GNU, pois nesta normalmente os grupos de desenvolvimento estão espalhados pelo mundo.
Programar com um parceiro pode parecer, inicialmente, um processo altamente ineficiente. Entretanto, como a nossa própria experiência mostra, mostra-se de fato uma saída eficiente e com muitas vantagens agregadas. Nesse contexto, o código costuma ser mais claro e eficiente, pois ele é melhor planejado e discutido e também evitam-se “acomodações” na implementação, pois seu parceiro está acompanhando. Consegue-se também evitar a criação de “ilhas de código”, onde apenas um programador tem conhecimento de como funciona determinada fatia do código.
Esses pontos são fundamentais no desenvolvimento de jogos também, onde a equipe de programadores é usualmente pequena, e assim a perda de qualquer membro pode ser altamente perigosa para o progresso do projeto.
É interessante notar que na filosofia GNU essa prática é muito rara, mas ainda assim, dada a grande exposição do código – que fica aberto ao mundo – e a um uso freqüente de fóruns/listas e a divisão do trabalho em grupos pequenos, conseguem-se efeitos similares em diversos projetos. Entretanto, os aspectos motivacionais da criação e desenvolvimento nesses dois contextos são muito distintos, e assim mereceriam maior atenção em uma análise mais profunda.
TESTES SISTEMÁTICOS
Fundamentais, e usualmente deixados como um “último passo”, os testes são uma ferramenta extremamente poderosa de se detectar falhas e também funcionalidades esquecidas mas extremamente importantes. Por isso, uma filosofia de testes periódicos e detalhados deve ser planejada. Além disso, não se deve quebrar o código, i.e., não se deve permitir alterações no código que o reprove nos testes até aquele ponto.
Essa prática pode ser implementada de diversas formas. No desenvolvimento de jogos implica, normalmente, em ter versões de desenvolvimento do seu jogo até determinado ponto e um grupo de voluntários para testá-lo e fornecer o feedback sobre todos os itens importantes, como a jogabilidade, aparência do jogo, desenvolvimento da história, estabilidade do programa, etc.
Em programas segundo a filosofia GNU, ela é posta em prática imediatamente: cada versão do programa está sempre disponível para testes e uso tão logo quanto criada, e há grupos de usuários que testam exaustivamente os programas. Além disso, muitas vezes são criados também scripts e testes padrão para o desenvolvimento de versões iniciais e/ou novas funcionalidades.
Uma rotina de testes bem definida possibilita, assim, um desenvolvimento estável e diminui sensivelmente o risco de ser preciso reprogramar grandes partes do projeto por ter se identificado perto do final algum grande problema ou funcionalidade vital que foi deixada para trás.
ACESSO TOTAL AO CÓDIGO DOS DESENVOLVEDORES
Este ponto é cada vez mais comum aos desenvolvedores com o fortalecimento da filosofia GNU no mundo, pois nela o código está totalmente acessível a qualquer pessoa interessada.
As vantagens são muito interessantes, mesmo quando o código é disponível somente à equipe do projeto. Possibilitando que o código seja totalmente acessível, aumenta-se a integração do código e da equipe, e diminui-se implementações duplicadas para funções comuns, por exemplo. Também torna mais uniforme a estrutura e apresentação do código, bem como evita que o trabalho de um grupo quebre o de outro.
Mas não é só para a leitura do código que usamos a palavra “acesso”. Qualquer programador pode atuar em qualquer parte do código, possibilitando assim que partes complicadas recebam maior atenção e que otimizações e novas idéias venham da equipe como um todo. Também torna ainda mais difícil a criação de “ilhas de código”, e de forma muito eficiente, ainda mais quando praticada em conjunto com a programação aos pares.
Todas essas vantagens são claras também no desenvolvimento de jogos.
OUTROS ASPECTOS IMPORTANTES E LIMITAÇÕES
Deve-se notar que utilizamos muitas vezes as palavras “desenvolvimento” e “programação” nesse texto sem uma distinção precisa. De fato, os pontos citados da metodologia XP visam principalmente a programação e não o desenvolvimento de um programa, com exceção da coletânea de histórias dos usuários.
Principalmente para o desenvolvimento de jogos, então, devemos notar que é uma distinção muito relevante, e que mostra muitas limitações da metodologia XP, principalmente quando notamos que a coletânea de histórias dos usuários é justamente o ponto menos relevante da metodologia no desenvolvimento de um jogo. Jogos requerem muitos outros trabalhos: roteiros, gráficos e efeitos especiais, sons, etc. Isso torna o desenvolvimento de jogos muito longe de simplesmente programação, ao contrário de um grande número de tipos de softwares por aí, e torna portanto a metodologia XP limitada a somente uma parte do ciclo de desenvolvimento.
Além disso, vemos que pode-se realmente pensar que há poucas novidades na metodologia XP, até se comparada à filosofia GNU de desenvolvimento, pois os principais preceitos da filosofia GNU já incluem a grande maioria dos pontos destacados pela metodologia XP. Entretanto, a metodologia XP consolida diversos aspectos importantes para a programação profissional e, principalmente fora do “mundo GNU”, chama a atenção para diversos pontos que são usualmente esquecidos.
Isso não significa que devamos ignorar essa metodologia e jogá-la em uma lata de lixo. Programar continua sendo uma das partes fundamentais do desenvolvimento de um jogo, e uma boa metodologia para a mesma possibilita inclusive uma maior integração com os demais itens do desenvolvimento, possibilitando resultados finais muito melhores. Este pensamento é particularmente verdade quando pensamos que muitos dos desenvolvedores de jogos nacionais são grupos onde os programadores não são “só″ programadores.