Campus Party no Brasil

A maior festa tecnológica do mundo

A Bienal do Ibirapuera será transformada numa grande cidade tecnológica de 11 a 17 de fevereiro de 2008, quando acontece a Campus Party Brasil - o maior encontro de comunidades da Internet do mundo.

Com o mesmo espírito da festa que já acontece há 11 anos na Espanha, a Campus Party Brasil será um espaço de encontro e de aprendizagem. Durante 7 dias e 7 noites, milhares de participantes acampam em suas barracas, com seus computadores a tira-colo, trocando momentos, idéias e experiências.

site oficial http://www.campusparty.com.br/

Com atenção especial para a Área "Software Livre", onde teremos oficinas de Ruby on Rails, Construção de Clusters Livres, Coding Dojo (Programação em Pares -XP) .

E entre as conferências nesta área vale destacar uma com o Bruno Souza sobre o futuro da linguagem Java, e uma conferência com Jon Hall líder da Linux International, sobre a importancia do Software Livre. E outra com Dairton Bassi sobre metodologias ágeis...

Vale a pena conferir, a brincadeira sai por R$ 100,00 a semana e se você quiser incluir a refeição é só pagar mais R$ 100,00 . Só não esqueça de levar o micro....

Diversão garantida !!!

TDD – Test Driven Development

•Test-Driven Development (TDD) é uma metodologia que utiliza os testes para auxiliar os desenvolvedores tomar as decisões certas na hora certa. TDD não é somente testes, É sobre utilizar os testes para desenvolver software de uma maneira simples e incremental. Não somente maximiza a qualidade e o design do software, como também simplifica o processo de desenvolvimento.
A beleza do TDD é que com pequenas mudanças na sua metodologia de desenvolvimento a algumas ferramentas adicionais o desenvolvedor é capaz de produzir software de maneira rápida e veloz.
TDD é uma das práticas do Extreme Programming (XP).As práticas do XP foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências no desenvolvimento de uma sistema de pagamento para a Chrysler. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento simples e manter um processo contínuo de desenvolvimento em um ciclo curto que fornece um feedback constante do estado do software. As idéias do TDD tem ganho uma grande aceitação nos meio dos desenvolvimento e projetos de software.

A Metodologia do Test-Driven Development

TDD é uma metodologia muito simples que se resume em dois conceitos:
Testes unitários e refatoração.
TDD é basicamente composto nos seguintes passos:
–Escrever um teste que define como você acha que pequeno pedaço da aplicação deveria se comportar.
–Fazer o teste rodar da maneira mais fácil e rápida que você pode. Não se preocupe com a qualidade do código, apenas faça funcionar.
–Enxugue o código. Agora que o código esta funcionando corretamente, dê um passo para trás e refatore para remover qualquer duplicação ou qualquer outro problema que foi apresentado para tornar o teste executável.
TDD é um processo iterativo e você repete estes passos inúmeras vezes até que você fique satisfeito com o novo código.
A maneira que TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito.
Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos beneficios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.


Convencendo as pessoas a utilizar TDD

Desenvolver software é um risco assumido. É quase impossível entregar um projeto dentro do orçamento e do prazo. De acordo com um estudo da Gartner Group, 30% dos projetos falham e não chegam aos seus objetivos, e 70% são entregues em atraso ou fora do orçamento previso. Claramente existe a necessidade de melhorar este processo, mas a questão é como. TDD pode ser parte da resposta, mas antes de convencer as pessoas a utilizar TDD é preciso entender e apresentar os problemas do processo atual. Uma vez entendido as falhas do processo corrente, é preciso entender como utilizar TDD para suprir estas falhas e utilizar este conhecimento para convencer as outras pessoas que isso irá funcionar.

Encontrando as falhas no processo corrente.

O processo mais usual quando não se pratica TDD é o famoso modelo cascata (análise dos requisitos, modelo, código e o teste). A maioria dos problemas relacionados ao desenvolvimento de software é má comunicação da equipe e uma execução falha. Para entender as falhas do processo corrente, devemos responder algumas perguntas básicas como:
–Qual é a maior causa dos bugs no softwares ?
–Qual é a maor causa dos atrasos no cronograma ?
–Qual é a média de bugs a cada 1000 linhas de código escrito ?
–Como o processo reage a uma mudança de requisito.
–Qual a fase do projeto que mais tenho problemas ? (Desing, código, integração, etc..)

Uma vez que estas perguntas foram respondidas, é provável que você tenha uma idéia melhor dos problemas no processo corrente. É muito importante entender estas questões antes de entender como e se o TDD pode ser utilizado para resolver os problemas.