Na minha vida como desenvolvedor já tive a oportunidade de trabalhar com vários outros desenvolvedores, utilizando diferentes linguagens, diferentes ferramentas, diferentes arquiteturas ... no entanto, uma coisa que é comum em todas estas experiências, diz respeito com integração de códigos.
Modelar um software, e dividir a implementação entre vários desenvolvedores é bastante comum. Na teoria, agiliza o desenvolvimento. Cada um implementa sua parte, realiza seus testes, acha tudo perfeito, e quando vai integrar, tudo começa a dar errado. E daí quando você tem que mexer no código que outra pessoa fez, daí é que tudo vai pro espaço.
Para minimizar estes problemas, é bom adotar algumas práticas de programação e desenvolvimento. Definir bons testes de unidade antes de iniciar a implementação, utilizar códigos de programação, etc ... Tendo em vista este problema, um bom artigo é o post "Producing and maintaining high-quality code", do blog Ozone. O autor lista 10 dicas sobre como escrever bons códigos, e em decorrência, gerar bons softwares.
Uma das dicas interessantes é a de número 3 - Talk to your cardboard friend, que eu conhecia como "Técnica do ursinho". Esta técnica aprendi através de um professor, que relatou que um outro professor que lecionava na universidade em que ele fez doutorado tinha um ursinho de pelúcia que ele levava nas aulas de laboratório. Toda vez que um aluno tinha uma dúvida, ele tinha que explicar o problema pro ursinho. Com isso, boa parte dos alunos conseguiam enxergar o problema, só explicando o mesmo pro ursinho.
Voltando ao artigo, é bastante interessante, e pode ser bastante útil. O autor inclusive sugere ferramentas que podem facilitar a vida dos desenvolvedores. E você, tem mais alguma dica para compartilhar? Dê seus comentários.
Assinar:
Postar comentários (Atom)
3 comentários:
Bom, já que você está mencionando especificamente a parte de integracão, não tem como deixar de citar Pair Programming, que vem do pessoal de Agile.
A idéa é que você não deve nunca programar sozinho. Sempre deve haver 2 pessoas no computador, conversando e programando juntas, sendo que uma, o "driver", maneja o teclado.
Inicialmente a idéia parece estúpida. Você deve pensar "pô, mas eu vou estar pagando 2 salários pra uma pessoa programar". Bem, o povo de Agile (como XP) alega que essa prática traz inúmeros benefícios e que compensa pagar "em dobro". Entre os benefícios estão:
1) um programador aprende muito do outro. Programadores novatos tendem a entrar no "ritmo" dos mais experientes rapidamente;
2) se você fizer rotacão de pares em um projeto, tanto no sentido de que um programador deve fazer "sessoes" com todos os outros e de que todos os pares devem implementar partes em todos os níveis do software (camada de apresentacao, negocios, etc), então voce nunca vai ter problemas de integracão, pois todos os programadores vão ter uma visão global do sistema. Isso, aliado com unit tests e compilacões sucessivas em curto prazo, praticamente eliminam os problemas de integracao (alegam os XPrs).
Bem, eu nunca pus isso na prática e confesso que tenho alguma dúvida de como isso funcionaria. Mas creio que voce poderia fazer um bom teste com 4 desenvolvedores, em um projeto de baixo risco e ir aumentando gradativamente.
Abracao!
Bart
Sorococô! tenho uma excelente dica para a situação descrita: compre um
ursinho de pelúcia e utilize a dica do
Bart, contratando o ursinho de pelúcia do professor. Dessa maneira o SEU ursinho de pelúcia aprenderá com o experiente ursinho do professor e vc só precisará pagar um salário, para o urso professor, levando em conta que o outro é seu mesmo.
ah! esqueci de me despedir.. um abraço. :-)
Postar um comentário