UNIVERSIDADE FEDERAL DO RIO DE JANEIRO DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Comparativo entre as linguagens de programação Java e Ruby para projetos que utilizem Extreme Programming ALAN KLOH, RODOLFO CORDEIRO BURLA DE AGUIAR DCC-IM/UFRJ Bacharelado em Ciência da Computação Orientador: Vinícius Manhães Teles Rio de Janeiro 2007

2 Comparativo entre as linguagens de programação Java e Ruby para projetos que utilizem Extreme Programming Alan Kloh, Rodolfo Cordeiro Burla de Aguiar Projeto Final de Curso submetido ao Departamento de Ciência da Computação do Instituto de Matemática da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para obtenção do grau de Bacharel em Ciência da Computação. Apresentado por: Alan Kloh Rodolfo Cordeiro Burla de Aguiar Aprovado por: Vinícius Manhães Teles, M.Sc. (Presidente) Adriano Joaquim de Oliveira Cruz, Ph.D. Carlo Emmanoel Tolla de Oliveira, Ph.D.. Vanessa de Paula Braganholo, D.Sc RIO DE JANEIRO, RJ - BRASIL JUNHO DE 2007

3 AGRADECIMENTOS Rodolfo A Deus, por ter me dado a oportunidade de concluir mais essa etapa na minha vida. Aos meus pais, José Geraldo e Paula, que mesmo estando longe, me deram todo incentivo, auxilio e carinho que precisava para completar mais essa etapa. À minha irmã Rosane, que foi quem sempre esteve ao meu lado durante todos esses anos, me ajudando quando precisava, me incentivando quando era necessário e me divertindo nos momentos de descanso. À minha irmã, Cecília, e meu cunhado, Pascoal, pelo o apoio e carinho durante todos esses anos. À minha namorada Mayara, pela compreensão nos momentos de ausência, pelo carinho e amor nos momentos em que estávamos juntos, que tornaram a graduação muito mais agradável, e pelo grande incentivo em todos os momentos. Ao nosso orientador Vinícius Manhães Teles, por ter me apresentado a essa nova metodologia, pelo apoio e auxilio na escolha do tema, e sem o qual essa monografia não teria a mesma qualidade. Ao Alan, parceiro durante toda a graduação, inclusive nessa monografia, sempre tornando os momentos mais difíceis naqueles mais divertidos com seu bom humor e suas piadas. Aos amigos da graduação, Luciano, Rafael, Carlos Eduardo (Kadu), João Paulo (Pipa) e Wallace, pela ajuda nos momentos de dificuldade e pela amizade nos momentos de diversão. Aos professores do DCC/UFRJ os quais nos transmitiram valiosos conhecimentos ao longo da graduação. A todos que nos ajudaram de alguma forma, direta ou indiretamente, na elaboração desta monografia.

4

5 RESUMO KLOH, Alan; AGUIAR, Rodolfo Cordeiro Burla, Comparativo entre as linguagens de programação Java e Ruby para projetos que utilizem Extreme Programming. Orientador: Vinícius Manhães Teles. Rio de Janeiro: UFRJ/IM/DCC, Monografia ( Bacharelado em Ciência da Computação) Este trabalho apresenta um estudo comparativo entre as linguagens Java e Ruby, com o framework Rails, no que se refere à utilização da metodologia de desenvolvimento Extreme Programming. Esse comparativo foi criado através de uma pesquisa de tecnologias para as linguagens a fim de identificarmos as vantagens e desvantagens das mesmas. Para o estudo, também foram criados dois blogs para comparar a qualidade do produto final, o tempo de duração do processo de desenvolvimento e a facilidade de sua utlização.

6 ABSTRACT KLOH, Alan; AGUIAR, Rodolfo Cordeiro Burla, Comparativo entre as linguagens de programação Java e Ruby para projetos que utilizem Extreme Programming. Orientador: Vinícius Manhães Teles. Rio de Janeiro: UFRJ/IM/DCC, Monografia ( Bacharelado em Ciência da Computação) This work presents a comparative study between Java and Ruby languages, relating to the use of Extremme Programming methodology. This comparative was created through research on technologies to the languages and by the development of two blogs, each of them in one of the languages. To identify the advantages and disadvantages of each used language with a set of technologies previously chosen.

7 SUMÁRIO 1 Introdução Motivação Proposta Validação Extreme Programming Valores Práticas Blog em Java Introdução Padrão Model-View-Controller MVC Model Struts JUnit Estrutura do Blog Funcionamento do Blog Considerações Blog em Ruby Introdução Ruby on Rails Migration Estrutura do Blog Funcionamento do Blog Considerações Comparativo Introdução Linhas de Código Analisando as práticas Conclusão...74

8 7 1 Introdução 1.1 Motivação Ao longo de mais de três anos, entre estágio e trabalho, percebemos que apesar de trabalharmos em lugares distintos nos deparávamos com os mesmos problemas em nossos projetos. Eles constantemente sofriam alteração no cronograma, pois era verificado que este era irreal e não poderia ser cumprido. Com isso, projetos que deveriam durar um determinado número de meses duravam, na realidade, quase o dobro. Os projetos eram entregues mas, muitas das vezes não atendiam às necessidades dos usuários. Em alguns casos até, esta já havia deixado de existir, devido a alguma mudança no ambiente em que seria utilizada. Esses problemas não aconteciam somente na nossa equipe, mas sim em grande parte dos projetos que as empresas estavam envolvidas, o que nos mostrava que não era um problema gerencial ou técnico das equipes. Como ocorriam em empresas diferentes, verificamos que se tratava de um problema em algo que era de uso comum às duas empresas. Foi então que começamos a estudar Extreme Programming (XP) 1 na faculdade. Durante esse estudo, o professor apresentou diversos problemas que eram comuns em projetos de software em geral. E eram, exatamente, esses os que identificávamos nas respectivas empresas. Assim descobrimos que as metodologias utilizadas nas duas empresas eram muito parecidas e, portanto, tinham alguma influência nos constantes atrasos e falhas dos projetos de software. E essa é uma metodologia comum, não somente a essas duas empresas, mas à maioria das companhias de desenvolvimento de software. 1 Metodologia de desenvolvimento de softwares criada no final da década de 90. (TELES, 2004)

9 8 No estudo do XP vimos que ela apresenta diversas práticas que buscam corrigir os erros mais comuns no desenvolvimento de software. Essa metodologia nos foi apresentada utilizando-se o Java (SUN 2006f), por ser tratar de uma linguagem amplamente utilizada hoje em dia no mercado e por possuir artefatos que auxiliam na utilização dessa metodologia. Porém, a integração desses artefatos que auxiliam na utilização dessa metodologia nem sempre é fácil e rápido, assim como o desenvolvimento nessa linguagem em geral requer a codificação de muitas classes, interfaces e arquivos de configurações. Diante dessa característica da linguagem, optamos por buscar, uma outra, e foi então que conhecemos a linguagem Ruby(THOMAS; HANSSON 2005) e o framework Ruby on Rails (THOMAS; HANSSON 2005). Porém, não sabíamos como seria utilizar a metodologia XP com essa linguagem, quais práticas possuiriam ferramentas para auxílio e quais seriam as dificultadas. Decidimos comparar as duas linguagens para verificar qual delas se mostraria mais eficiente, utilizando-se as práticas de XP, levando-se em conta as características de cada linguagem e o seu suporte na utilização das práticas de XP. 1.2 Proposta Nesse trabalho iremos testar essas duas linguagens utilizando-se as técnicas de XP, com a finalidade de verificarmos qual seria mais recomendada para o desenvolvimento de aplicações Web. Iremos com isso gerar um estudo comparativo entre as duas linguagens, apresentando vantagens e desvantagens, para cada técnica utilizada em XP. Ao

10 9 final, apresentaremos aquela que considerarmos a mais adequada para o desenvolvimento de aplicações Web, se verificarmos a existência de uma. Nesse comparativo iremos utilizar a métrica de linhas de código, como uma das formas de comparação entre as duas, bem como uma análise subjetiva em relação a complexidade no desenvolvimento da aplicação. 1.3 Validação Para obtermos esse comparativo, iremos desenvolver uma mesma aplicação Web, utilizando-se as técnicas de XP, nas duas linguagens, anotando as características de cada uma em relação a cada técnica. Essa aplicação será um blog 2, por se tratar de uma aplicação bastante utilizada atualmente, simples de ser implementada, mas, ao mesmo tempo, suficiente para a elaboração desse estudo. 2 Página da web que possui textos, que em geral se referem a um mesmo assunto, ou pertencem a uma mesma pessoa, que são organizados cronologicamente, que normalmente podem ser comentadas.

11 10 2 Extreme Programming Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos, na década de 90, baseada em alguns valores e práticas que ajudam a tornar o desenvolvimento dos softwares mais ágil e produzir resultados com maior qualidade. Essa é uma das metodologias conhecidas como metodologias de desenvolvimento ágil. Essas metodologias seguem um conjunto de princípios criados por um grupo de profissionais veteranos que se reuniram numa estação de esqui, no EUA, para discutir formas de melhorar e agilizar o processo de desenvolvimento de software. Eles chegaram à conclusão de que todos os projetos em que estiveram envolvidos e que obtiveram sucesso, seguiam um mesmo conjunto de princípios. Com base nisso, eles criaram o Manifesto para o Desenvolvimento Ágil ( também conhecido como Manifesto Ágil. Esses princípios são: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano O manifesto ressalta que, mesmo que haja valor nos itens à direita, os itens à esquerda são considerados prioritários. No decorrer desse capítulo, iremos apresentar e explicar cada um dos valores e práticas utilizadas no desenvolvimento de software que seguem o XP. 2.1 Valores

12 11 Feedback Projetos de software são bastante suscetíveis à falha, pelo fato de que, em muitas vezes, os clientes não sabem exatamente o que desejam quando fazem uma solicitação de softwares Em geral, os clientes reconhecem os seus problemas e querem um sistema para resolvê-lo. No entanto, não sabem ao certo o que o software deve fazer para solucioná-lo. Devido a essa característica, geralmente, o entendimento do que o sistema deveria fazer não é o mesmo entre os desenvolvedores e os clientes, e por isso, constantemente, vemos softwares que não satisfazem às necessidades dos clientes (BROOKS, 1987). Para contornar essa característica do desenvolvimento de software, o XP utiliza um valor chamado feedback, que consiste em obter o feedback dos seus clientes o mais rápido possível. Esse processo busca diminuir, ao máximo, a defasagem de tempo entre o momento entre a execução da ação e a obtenção de seu resultado. Quanto mais cedo um mau entendimento de alguma funcionalidade for identificado, menor será o custo de seu reparo. Por isso, este valor é tão importante no XP, pois quanto maior o feedback dos clientes menor o risco de se produzir algo errado. Comunicação No desenvolvimento de software estão envolvidas pelo menos duas pessoas. O desenvolvedor e o cliente. Mas, em sua maioria, um maior número de pessoas estão envolvidas( mais clientes e desenvolvedores). No desenvolvimento de software, o cliente geralmente, precisa informar o que deseja ser produzido. E cabe ao desenvolvedor, informar quais as limitações técnicas envolvidas. No processo, os problemas na comunicação, frequentemente, causam uma compreensão equivocada do que está sendo solicitado.

13 12 Muitas vezes o meio de comunicação que está sendo utilizado faz toda a diferença na compreensão das pessoas que estão se comunicando, pois uma série de conhecimentos tácitos podem ser perdidos, dependendo do meio de comunicação empregado. Quando explicamos algo pessoalmente, por exemplo, percebemos através das expressões faciais, se estamos sendo compreendidos pela outra pessoa. Quando fazemos essa explicação por telefone, esse conhecimento tácito é perdido. Muitas vezes os clientes executam suas atividades de modo tácito, e por isso têm dificuldades de descrever suas atividades utilizando meio de comunicação pouco ricos como, telefone e por exemplo, mas em uma conversa presencial conseguem explicar facilmente essas tarefas. Por isso o XP valoriza meios de comunicação mais ricos, trazendo o cliente, ou ao menos um representante, para dentro da equipe de desenvolvimento. Isso significa trazer o cliente para o mesmo ambiente em que estão os desenvolvedores, para que a comunicação entre eles seja feita de forma presencial e o mais rápido possível. O XP também faz uso de radiadores de informação (COCKBURN, 2002) que, além de facilitar a comunicação, ajudam a colocar em prática um modelo de autodirecionamento do processo de desenvolvimento. Outra característica do XP, importante para que haja uma melhor comunicação entre os integrantes do processo de desenvolvimento, é a utilização de equipes pequenas, pois quanto menos pessoas envolvidas no processo de desenvolvimento, mais fácil saber o que cada uma está fazendo. Assim, evita-se que duas pessoas realizem tarefas que interfiram nas tarefas dos outros. Além disso, quanto menos pessoas envolvidas num processo de comunicação, mais fácil é a

14 13 compreensão do que uma pessoa está falando, por termos menos interferência e conversas paralelas, o que torna a comunicação mais rica. Simplicidade Um estudo do Standish Group (JOHNSON, 2002) mostrou que 45% das funcionalidades de um sistema típico jamais são utilizadas e que 19% das funcionalidades são usadas raramente. Esses números revelam um pouco da razão pela qual o desenvolvimento de software costuma ser mal sucedido. Quando falamos mal sucedido, nos referimos a projetos que, foram entregue fora do prazo, ou extrapolaram o custo, ou os dois, ou até que não terminaram. Esses 64% de funcionalidades desenvolvidas, sem necessidade, indicam um desperdício de tempo, dinheiro e pessoal responsável. Isto, em grande parte, pelo insucesso dos projetos de software. Essas funcionalidades surgem basicamente por três motivos: O escopo do sistema, geralmente, é fechado no inicio do desenvolvimento e alterações no mesmo são evitadas; Desenvolvedores criam soluções genéricas para facilitar possíveis alterações no escopo; Desenvolvedores têm a tendência de criar funcionalidades que eles imaginam que serão solicitadas pelos clientes. Para combater esses problemas, o XP utiliza um escopo negociável (POPPENDIECK & POPPENDIECK, 2003) e utiliza iterações curtas onde são projetados, programados, testados, integrados e entregues incrementos de softwares úteis (POPPENDIECK & POPPENDIECK, 2003).

15 14 Como essas iterações são curtas, o feedback do usuário é obtido em um espaço curto de tempo e, assim, o desenvolvimento de funcionalidades desnecessárias é evitada, já que as funcionalidades de uma iteração são definidas pelo usuário que estabelece a prioridade de cada funcionalidade que ele imagina ser necessária ao sistema. Os desenvolvedores selecionam as mais prioritárias dentro do limite de tempo para realização daquela iteração, deixando as outras para a iteração seguinte. E, assim, aquelas funcionalidades que o usuário imaginava necessária no inicio do desenvolvimento, mas que não eram prioritárias, mostram o seu caráter desnecessário com o passar das iterações e não são desenvolvidas. O valor da simplicidade implica em fazer somente o que é necessário agora, sem tentar adivinhar o que será necessário no futuro, fazendo da maneira mais simples possível. Porque mantendo o seu sistema o mais simples possível, fica mais fácil adicionar novas funcionalidades no futuro, nas iterações seguintes. Coragem Existem diversos temores no processo de desenvolvimento de software. Esses temores podem interferir no desenvolvimento, já que atingem tanto os clientes como os desenvolvedores, e as tarefas executadas passam a ser baseadas nesses temores.. Em projetos XP, estes temores também estão presentes. Porém, o XP utiliza um conjunto de práticas que tendem a diminuir a conseqüência desses temores e, com isso, torna a equipe mais confiante de que seu trabalho não será afetado por esses temores. Por exemplo: Os clientes possuem medo de que não seja produzido o que eles querem, ou que estejam pagando muito por pouco. Para isso o XP usa a prática de iterações curtas que mostram o resultado rapidamente ao cliente, que assim pode

16 15 avaliar se está sendo bem interpretado e ainda avaliar se a equipe com a qual está trabalhando está produzindo o suficiente que justifique o investimento. Essas e outras práticas dão suporte para que as equipes XP se sintam encorajadas a desenvolver seus trabalhos. 2.2 Práticas Cliente Presente Esta prática consiste em levar o cliente para perto da equipe de desenvolvimento ou levar a equipe para perto do cliente. Quando falamos perto, queremos dizer, colocar os dois, fisicamente, no mesmo local. Esta prática é importantíssima para dois dos valores em que o XP se baseia: feedback e comunicação. O feedback é aprimorado na medida em que o desenvolvedor, estando próximo ao cliente, pode tirar dúvidas, na hora que sentir necessidade. Por sua vez, o cliente pode ir testando o sistema, à medida que este vai ficando pronto e com isso ir fornecendo feedback a respeito do que foi produzido. E, assim, o desenvolvedor assimila mais rapidamente as necessidades do cliente, fazendo com o desenvolvimento fique mais rápido ao longo do tempo. A comunicação melhora, pois conforme falamos anteriormente, o XP valoriza os meios de comunicação mais ricos e, nada é mais rico do que uma conversa presencial. Estando o cliente no mesmo espaço físico do desenvolvedor, a comunicação entre eles tenderá ser sempre presencial, o que é importantíssimo para uma maior compreensão do que está sendo conversado. A presença do cliente no mesmo espaço do desenvolvedor cria uma outra relação benéfica, que é a

17 16 relação de confiança, onde o cliente toma conhecimento dos esforços das equipes de desenvolvimento. Apesar da presença dos clientes trazer essas vantagens, nem sempre é fácil envolvê-los nos projetos. Boehm e Turner (2003) e Teles (2004) apresentam situações nas quais pode ser difícil, ou inviável, a utilização desta prática. Como por exemplo, quando o cliente está situado em outra cidade, estado ou país diferente de onde se encontra a equipe de desenvolvimento. Jogo de Planejamento O planejamento em XP é feito de forma contínua ao longo do desenvolvimento do software, onde o cliente e os desenvolvedores estão presentes. Os clientes escrevem pequenas funcionalidades em cartões, chamadas de histórias. Essas histórias devem ser simples e escritas de forma que cliente e desenvolvedores sejam capazes de entendê-las. Uma vez com as histórias definidas, os desenvolvedores estimam quanto tempo irão levar para desenvolver cada uma. Com as estimativas definidas, o cliente define o valor de negócio de cada uma e então determina as prioridades e, baseado no orçamento dos desenvolvedores, define quais as histórias deverão ser entregues no próximo release.(beck & FOWLER, 2001). Os releases são intervalos de tempos, que geralmente duram alguns meses, onde um pequeno conjunto de funcionalidades, devidamente testado e integrado, é entregue aos usuários para serem utilizados. Esses releases são divididos em intervalos menores chamados de iterações. As iterações são intervalos de tempos que, geralmente, duram algumas semanas, e onde os desenvolvedores entregam algumas funcionalidades, também devidamente testadas. Uma coisa que vale ressaltar é que a duração de cada

18 17 iteração é constante ao longo do de todo o projeto. Essas iterações servem para se obter uma melhor estimativa do andamento do projeto e, com isso, estimar melhor o tempo de desenvolvimento da equipe, chamada de velocidade, ao longo do desenvolvimento. Essa velocidade tende a se estabilizar. As iterações também são extremamente importantes para obtenção de feedback de que o que está sendo desenvolvido é realmente o que foi pedido pelos clientes. Assim podemos identificar, mais rapidamente, possíveis erros cometidos e corrigí-los. A cada início de iteração é definido quais funcionalidades serão implementadas, baseado na velocidade das iterações passadas e após redefinição das prioridades das histórias. Por se tratar de um processo continuo de planejamento, revisão de prioridades e entrega de produtos, as funcionalidades desnecessárias tendem a não serem desenvolvidas, uma vez que o cliente vai tendo acesso ao sistema e verifica que essas funcionalidades não se fazem mais necessárias. Com isso, o desperdício de recursos é minimizado e aumenta a chance do projeto ser bem sucedido. Stand up meeting O Stand up meeting, como o próprio nome em inglês diz, é uma reunião em que seus participantes ficam em pé. Essa característica e extremamente importante para demonstrar que esta reunião deve ser rápida. Ela ocorre, diariamente, para que todos tomem ciência do que aconteceu no dia anterior. Todos contam o que fizeram um dia antes para que toda a equipe tenha conhecimento do andamento do projeto. Essa reunião também é importante para a obtenção do feedback dos outros integrantes da equipe. Neste momento, cada um fica sabendo de sua atividade diária, que é definida por toda a equipe. Ao tomar conhecimento de todas as atividades dos membros, dos problemas enfrentados e das soluções encontradas, o conhecimento adquirido por uma pessoa

19 18 é disseminado para toda a equipe. Porém, esta reunião só é possível se todos os membros da equipe trabalharem no mesmo lugar. Programação em Par A programação em par consiste em duas pessoas programando juntas em um mesmo computador. À primeira vista, essa prática pode ser vista como uma perda de recursos. Porém, como iremos ver, essa prática traz uma série de vantagens. A inspeção de código realizada intensamente é a primeira das vantagens que podem ser citadas. Ter alguém, ao lado, desenvolvendo com você, faz com que esta pessoa funcione como um revisor do código capaz de verificar erros simples, que podem passar despercebidos pelos programadores. Tais erros poder consumir dias para serem corrigidos. Assim, detectá-los cedo diminui o esforço da correção. Discussões ao longo do desenvolvimento fazem com que os programadores explorem um número maior de cenários, fazendo com que estes cheguem a uma forma mais simples de resolver o problema. Isto é uma grande vantagem quando tiver que ser dada alguma manutenção no código. Além disso, implantar a solução mais simples, em geral, consome menos tempo. Outro aspecto importantíssimo na programação, em par, é a disseminação do conhecimento. Como os programadores trocam de par constantemente, a troca de conhecimento enquanto trabalham juntos é acontece naturalmente. Ao se depararem com problemas, os programadores mais experientes passam seus conhecimentos para os mais jovens. Além disso, quando as pessoas obtêm informações sobre questões que estão enfrentando no dia-a-dia, a sua concentração no aprendizado tende e a ser muito melhor. A programação em par também é extremamente importante para construir uma equipe mais sólida, que não depende de um único programador chave e, ao

20 19 mesmo tempo, contribui para a adição de uma pessoa à equipe. Como o conhecimento é disseminado ao longo de toda equipe, a presença de um programador chave se torna mais difícil e a adição de uma pessoa é facilitada, pois esta irá trabalhar em par com outros programadores e obter conhecimento do domínio do sistema. Efeito conhecido, gerado pela programação em par, a pressão do par é importante porque aumenta a produtividade das equipes já que as pessoas se sentem pressionadas por seus pares. Isso diminui o tempo perdido com atividades externas ao projeto, como verificação de e conversas. As pessoas ficam inibidas em parar suas atividades pois isto implicará em parar, também, o trabalho de seu companheiro. Alem disso, a programação em par aumenta a motivação da equipe e o relacionamento inter pessoal pois proporciona o convívio direto com as pessoas e aumenta a confiança no outro, gerando uma maior intimidade que dão início. Até mesmo, a conversas sobre lazer e vida pessoal. Além disso, o fato de desenvolverem uma solução, em conjunto aumenta, a confiança nas atividades que executam. Todos esses fatores geram um aumento de produtividade que compensa o uso de dois desenvolvedores em um mesmo computador, além de produzir software mais rapidamente e de melhor qualidade. Existem alguns fatores, como ego e competitividade, que podem tornar a programação em par problemática. A presença de programadores com egos extremamente elevados, que não aceitam ver seus códigos serem questionados, e a existência de um ambiente extremamente competitivo, onde as pessoas não querem ser vistas aprendendo com um companheiro de trabalho, podem atrapalhar o

21 20 andamento do trabalho em conjunto. E, ao mesmo tempo em que alguns não estão dispostos a aprender, também se recusam a ensinar, a um colega de trabalho, algo que ele poderia passar adiante. Código Coletivo Uma outra prática utilizada no XP, que complementa a programação em par, é a pratica do código coletivo. Em XP, ninguém é proprietário de um código. O código pertence a toda a equipe e todos podem alterá-lo, sem pedir permissão a ninguém, o que ajuda na formação de uma equipe coesa. Já que todos têm acesso ao código, e sempre há um revezamento de pares e do trecho de código que cada um está desenvolvendo, na hora que for necessário dar manutenção em algum trecho de código, várias pessoas poderão fazer pois já trabalharam naquele trecho em algum momento. Como pessoas diferentes alteram o mesmo trecho de código, a tendência é que o código fique cada vez mais simplificado, pois cada um que notar que algo está sendo feito de uma maneira muito complicada tentará simplificá-lo. Assim, o código fica cada vez mais simples e os erros são detectados mais rapidamente, pois as pessoas que irão alterá-lo farão uma revisão do código e poderão identificar erros que ainda não haviam sido detectados (BECK, 2000, p ). Essa prática também agiliza o processo de desenvolvimento uma vez que as pessoas não precisam esperar que outra altere alguma coisa para que eles realizem os seus trabalhos. Eles mesmos alteram. Temos que ressaltar que esta prática só deve ser usada se a equipe desenvolve seu sistema utilizando uma base sólida de testes, pois alterações em trechos de códigos que não foram desenvolvidos pela própria pessoa podem causar muitos erros, mas com um grande conjunto de testes esse problema é contornado,

22 21 porque a pessoa poderá identificar esses erros quando rodar os testes e consertá-lo antes de integrá-lo. Código Padronizado Projetos XP utilizam código padronizado. Essa padronização é determinada pelos próprios desenvolvedores, o que auxilia na programação em par e no código coletivo. Mas essas práticas também são importantes para que se tenha um código padronizado, já que um código encontrado fora do padrão pode ser alterado para que fique no padrão. Design Simples Quando os usuários solicitam um software, esperam, basicamente, que ele possua quatro características : Que faça a coisa certa; Que funcione; Que seja fácil de utilizar e Que possa evoluir com o tempo. As duas primeiras características são alcançadas com a utilização da prática de iterações curtas (TELES, 2005), assim rapidamente os clientes podem verificar se o que está sendo feito está correto e funciona. Porém, essa mesma técnica pode ser uma armadilha para se obter as duas últimas características. Uma vez que o processo é iterativo, corre-se o risco de que nas iterações futuras seja difícil inserir novas funcionalidades e fazer com estas sejam facilmente adaptadas ao que já existe. Isso poderia tornar o sistema complexo de se usar e muitas vezes engessado. Mas para resolver esse problema, o XP utiliza uma série de práticas que são usadas em conjunto para corrigir possíveis falhas das outras e, uma delas, é a do

23 22 design simples. Equipes XP procuram manter o design dos sistemas o mais simples possível para que nas iterações futuras fique mais fácil agregar novas funcionalidades. Esta prática consiste em fazer sempre o mínimo possível, deixando que decisões complicadas sejam tomadas na hora certa, sem tentar prever o que está por vir, ou tentar prever mudanças que poderão acontecer no futuro. Essas previsões acabam fazendo com que os desenvolvedores comecem a gerar funcionalidades genéricas, porque acreditam que no futuro essas funcionalidades serão utilizadas por outros procedimentos e, com isso, vão gerando códigos complexos e difíceis de serem mantidos. Esta prática também é muito importante na utilização da prática de iterações curtas, pois apenas possuindo um design simples é possível fazer análise, design, implementação, testes e depuração de um conjunto de funcionalidades, em uma ou duas semanas. O design simples é obtido utilizando-se outras práticas que veremos a seguir. Essas práticas juntas fazem com que o crescimento do custo de manutenções futuras seja linear, e não exponencial, como na maioria dos casos. Isso ocorre porque com um design, sempre mantido o mais simples possível, com uso de computadores rápidos pelo os desenvolvedores, que permite que estes realizem testes sempre que fizerem uma mudança no sistema, e a adoção dos testes automatizados, evita que manutenções no futuro sejam muito mais custosas que as feitas no presente (BECK, 2000). Desenvolvimento Orientado a Testes Uma das práticas citadas acima que ajudam na elaboração de um design simples e que reduz o custo de manutenções futuras é a prática de desenvolvimento orientado a testes (HUNT & THOMAS, 2003). Essa prática consiste na elaboração