[Desenvolver] Velocidade vs. Qualidade

[YvGa]

Como assim? Não seria; Casos de teste, Arquitetura, e ai sim testes?

Depende de como voce faz cada uma dessas fases. Eu faco historia(definindo alguns testes que ela deve passar), um pequeno esboco (bem rapido) dos objeto que vao participar da historia, isso se for necessario conversar com outros membros da equipe, se nao o modelo fica so na cabeca mesmo. Aí escrevo os testes e nele vai sendo implementada a funcionalidade da historia.

Se voce perder horas debatendo sobre a arquitetura e tentar aprofundar demais, detalhando formas de implementacao, antes de por a mao no codigo, vai estar perdendo tempo, e ai vai dizer que os pangarés programam mais rapido porque nao planejam. Uns nao planejam, outros planejam demais. Se voce planeja com testes, vai se aproximar do ideal do planejamento. E com as facilidades das IDEs te garanto que escrever uma classe com funcionalidade implementada e testada, é tao rapido quando desenhar uma com qualquer ferramenta de uml do mercado, que voce fica clicandinho e abrindo box pra alterar propriedades. A diferenca é que está implementada e testada.

Quanto a escrever os testes antes, isso comigo não funciona. Durante a implementação preciso seguimentar certas funcionalidades que sempre geram mais uma penca de testes.

Se nao escrever os testes antes fica mais dificil saber se errou o design, pois voce vai testar aquilo que ja fez, e se fez errado vai testar errado, é so ver se nao tem erro de logica no algoritmo.
Escrevendo o teste antes voce vai ver como deve e como nao deve ser a api do seu modelo, vai por ali decidir qual a melhor maneira de expor as funcionalidades de um objeto, vai “sentir” que a abordagem que escolheu nao é a mais adequada.
E por que? Porque escrevendo o teste antes voce vai pensar em como a classe vai ser usada antes de implementa-la, voce comeca com uma perspectiva de usuario do seu modelo, e nao parte de uma solucao pre-estabelecida que pode nao ser a melhor solucao.

Quando resolvo fazer o refactoring, consigo reaproveitar bastante parte do código, porem boa parte dos testes são jogados fora.

Alguns testes sao jogados fora mesmo quando voce muda o design, mas se isso ocorre com muita frequencia, voce esta escrevendo testes demais.

Acho que isso pode ser reflexo de não ter tanta experiência quanto um profissional sénior, e ao escrever meus testes, e não ter tanta visão quanto um.

Eu tbm nao sou, nem me julgo profissional senior, nem me importo o titulo que vao me dar. O que quero é desenvolver melhor e mais rapido, a descoberta de TDD é um divisor de aguas pra mim. Eu recomendo que voce pegue o livro e leia com calma, é uma tecnica que aumenta muito a produtividade, juntamente com a qualidade do que desenvolvemos.

[andre_salvati]

[quote=vitu]Gostaria de saber a opinião de vocês quanto a esse assunto, especificamente para análise programação.

Realmente maus programadores são “produtivos”?

A maioria dos erros estão na análise e entendimento do negocio?

E qual seria uma boa definição para qualidade hoje. (No Brasil).

Nota: Sei que já existem alguns tópicos sobre o assunto, mas não quis ressuscitar para ter uma ideia da comunidade nesse momento.
[/quote]

Eu já falei diversas vezes por aqui:

“O maior problema que deve ser resolvido para se obter software de qualidade é o GERENCIAL e não o técnico”

[Leonardo3001]

Velocidade e Qualidade não são coisas opostas, ou você tem os dois, ou não tem nenhum. Sempre quando dá aquele sentimento de “dar o gás”, os programadores irão “avançar” no “cronograma” cortando testes e análise cuidadosos. E aí, antes mesmo do prazo final, vão perceber que aquela gambiarra não funciona em todos os casos, que aquele relacionamento de tabelas não permite escrever aquilo que está na tela, que o código atual não permite a correção dos próprios enganos cometidos.

O TDD é bom porque permite uma visão do software “top-down”, de cima para baixo, ou da visão do usuário. Programadores inexperientes sempre fazem o contrário, pensam em “bottom-up”, ou de baixo para cima, ou o cliente-que-se-vira-com-a-visão-maluca-que-eu-fiz. No começo, é normal, “top-down” é mais difícil que “bottom-up” e este último sempre será aprendido primeiro. O problema é quando o programador programa “bottom-up” sempre! O sintoma típico é: não escrever uma linha de código enquanto todas as tabelas não estiverem sido criadas. Isso é ruim, pois o sistema que emerge pode não ficar adequado ao usuário e, quando isso acontece, exige gambiarras para arrumar. O TDD é um jeito de pensar “top-down”. (Existem outras mais antigas, como escrever em pseudocódigo e quebrar essa transcrição em rotinas e objetos menores. Mas isso era coisa do meu antigo professor de cabelos grisalhos.)

Também, de nada adianta chamar um pessoalzinho na salinha e “definir o escopo” pros programadores fazerem TDD. (Isso não é TDD!). A atividade de construção de testes é a atividade de arquitetura e design do software. E quando isso é compreendido entre os programadores, a velocidade aumenta.

EDIT.: nem percebi que escrevi “são são” na primeira linha! O correto é “não são”.

[Andre_Fonseca]

[quote=Leonardo3001]Velocidade e Qualidade são são coisas opostas, ou você tem os dois, ou não tem nenhum. Sempre quando dá aquele sentimento de “dar o gás”, os programadores irão “avançar” no “cronograma” cortando testes e análise cuidadosos. E aí, antes mesmo do prazo final, vão perceber que aquela gambiarra não funciona em todos os casos, que aquele relacionamento de tabelas não permite escrever aquilo que está na tela, que o código atual não permite a correção dos próprios enganos cometidos.

O TDD é bom porque permite uma visão do software “top-down”, de cima para baixo, ou da visão do usuário. Programadores inexperientes sempre fazem o contrário, pensam em “bottom-up”, ou de baixo para cima, ou o cliente-que-se-vira-com-a-visão-maluca-que-eu-fiz. No começo, é normal, “top-down” é mais difícil que “bottom-up” e este último sempre será aprendido primeiro. O problema é quando o programador programa “bottom-up” sempre! O sintoma típico é: não escrever uma linha de código enquanto todas as tabelas não estiverem sido criadas. Isso é ruim, pois o sistema que emerge pode não ficar adequado ao usuário e, quando isso acontece, exige gambiarras para arrumar. O TDD é um jeito de pensar “top-down”. (Existem outras mais antigas, como escrever em pseudocódigo e quebrar essa transcrição em rotinas e objetos menores. Mas isso era coisa do meu antigo professor de cabelos grisalhos.)

Também, de nada adianta chamar um pessoalzinho na salinha e “definir o escopo” pros programadores fazerem TDD. (Isso não é TDD!). A atividade de construção de testes é a atividade de arquitetura e design do software. E quando isso é compreendido entre os programadores, a velocidade aumenta.[/quote]

Oi

Não acho que velocidade e qualidade sejam coisas opostas. Eu acho que se você tem um processo de desenvolvimento de software e de gerenciamento de equipe bem definido você pode com o tempo ter uma idéia de quanto rapido a sua equipe pode desenvolver um sistema e ir aos poucos cortando aquelas tarefas que tomam tempo e podem ser desconsideradas.

Esse sentimento que falou, de dar um gas, é a prova maior de que as coisas não foram planejadas corretamente no início. Eu acho que quando você tem uma equipe homogênea, onde as pessoas já estão acostumadas com o processo, depois de alguns sistemas desenvolvidos as coisas caminham quase que automaticamente.

O Scrum acho que fala bastante disso, os projetos anteriores servem de métricas para definir os prazos dos projetos futuros.

[Leonardo3001]

[quote=André Fonseca]Oi

Não acho que velocidade e qualidade sejam coisas opostas. Eu acho que se você tem um processo de desenvolvimento de software e de gerenciamento de equipe bem definido você pode com o tempo ter uma idéia de quanto rapido a sua equipe pode desenvolver um sistema e ir aos poucos cortando aquelas tarefas que tomam tempo e podem ser desconsideradas.

Esse sentimento que falou, de dar um gas, é a prova maior de que as coisas não foram planejadas corretamente no início. Eu acho que quando você tem uma equipe homogênea, onde as pessoas já estão acostumadas com o processo, depois de alguns sistemas desenvolvidos as coisas caminham quase que automaticamente.

O Scrum acho que fala bastante disso, os projetos anteriores servem de métricas para definir os prazos dos projetos futuros.[/quote]

Concordo com você, é que escrevi errado mesmo! Eu já editei para o correto.

[YvGa]

Velocidade e Qualidade não são coisas opostas, ou você tem os dois, ou não tem nenhum.

Perfeito.

Repito, se os testes estao tornando o desenvolvimento mais lento do que seria sem eles, tem algo errado na abordagem. A velocidade aumenta muito.

[mochuara]

[quote=Leonardo3001]Velocidade e Qualidade não são coisas opostas, ou você tem os dois, ou não tem nenhum.

Perfeito.

Repito, se os testes estao tornando o desenvolvimento mais lento do que seria sem eles, tem algo errado na abordagem. A velocidade aumenta muito.[/quote]

concordo com a afirmação do Leonardo. Mas qualidade não se resume a possuir testes. Vc esta misturando as coisas.

[YvGa]

[quote=YvGa][quote=Leonardo3001]Velocidade e Qualidade não são coisas opostas, ou você tem os dois, ou não tem nenhum.

Perfeito.

Repito, se os testes estao tornando o desenvolvimento mais lento do que seria sem eles, tem algo errado na abordagem. A velocidade aumenta muito.[/quote]

concordo com a afirmação do Leonardo. Mas qualidade não se resume a possuir testes. Vc esta misturando as coisas.[/quote]

Eu disse que se resumia?