Benefício Mútuo (Princípio – 3)

Cada atividade deve ser benéfica para todos os envolvidos em um projeto de software. Este é o mais importante princípio da XP, e o mais difícil de cumprir.

Há sempre soluções mais fáceis em que alguns ganham e outros perdem para qualquer problema. Apesar de tentadoras, principalmente quando as pressões externas são intensas, estas soluções sempre causam mais perdas que benefícios, já que, além das perdas diretas, existe a perda causada pela deterioração das relações de trabalho.

Desenvolver software é um negócio focado nas pessoas e que depende muito das relações entre os envolvidos, por isso, deve-se adotar práticas que beneficiem ambos, criadores e clientes do software, agora e no futuro. Programação em par, por exemplo, beneficia os programadores de inúmeras formas. Mas, também beneficia os clientes, porque costuma ser raro encontrar bugs em funcionalidades implementadas em par, e gerentes, já que a disseminação do conhecimento fruto da programação em par, torna o projeto menos suscetível a perdas em função da saída definitiva ou temporária de um dos desenvolvedores [IMPROVE IT, XP; BECK, 2005].

Documentação abrangente no código é um exemplo de uma prática que viola o princípio do benefício mútuo. Esta prática costuma diminuir a velocidade de desenvolvimento consideravelmente, objetivando que no futuro seja mais fácil fazer alterações. Realmente existe um possível benefício futuro, desde que a documentação ainda esteja válida, mas nenhum benefício para o presente.

A XP recomenda para resolver o problema anterior de maneira mutuamente benéfica, agir da seguinte forma [BECK, 2005]:

· Escrever testes automatizados que ajudam a melhorar o design e implementação no presente. Deixar estes testes para os futuros programadores, para que estes possam ter uma documentação sincronizada com o código e um mecanismo de verificação automatizado que dá segurança para qualquer possível alteração futura.

· Refatorar cuidadosamente para eliminar qualquer complexidade acidental, isto gera satisfação e menos defeitos no presente, além de tornar o código mais fácil de compreender e modificar no futuro.

· Escolher nomes de um conjunto coerente e explícito de metáforas relacionadas ao domínio da aplicação. Isto aumenta a velocidade de desenvolvimento no presente e torna o código mais claro para o futuro.

Abraços,
Vinicius AC
Universidade Federal de Sergipe (
Graduando)

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s