[Desenvolver] Velocidade vs. Qualidade

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

tnaires wrote:

mochuara wrote:

tnaires wrote:Uma coisa que o Fábio Akita sempre fala é que os programadores tendem a ficar mais preguiçosos na medida que se tornam mais experientes. Quando estamos começando a programar, temos toda aquela energia e disposição pra fazer códigos enormes, muitas vezes baseados no ctl+c, ctrl+v. O tempo vai passando e "perdemos" um pouco essa energia, pois passamos a evitar tarefas repetitivas desenvolvendo soluções que realizem essa repetição para nós.

Grande besteira isto, alguns programadores ficam com o ego mais inflado com o tempo, isto sim. Pensam que para ser um hacker é mais importante saber programar do que identificar qual o problema.

Não sei qual foi o sentido que você entendeu, mas ao citar o Fábio Akita eu me referi a algo que eu realmente vejo nas pessoas que começam a programar - e é absolutamente normal - que é copiar e colar código sem se preocupar em escrever algo reutilizável. Também não quis dizer que a pessoa fica foda quando perde essa característica.

Geralmente não perdem. Apenas passam a se denominarem "preguiçosos" e trabalham em cima de várias camadas de reutilização.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

YvGa wrote:
Com TDD a velocidade é muito maior, porque se voce tomou a decisao errada, voce vai ver muito cedo e arrumar, antes que tenha montado toda a infra-estrutura baseada naquela decisao.

Isto considerando que o teste esta correto, o que estaria em suspeição a partir do momento que uma decisão foi tomada errada. Testes unitarios (e TDD) não vai isentar ninguem do trabalho dificil que é desenvolver software, ele apenas atua na facilitação da comunicação da equipe e manutenção futura. Inevitavelmente voce vai tomar a decisão errada várias vezes durante o desenvolvimento mas com testes vc pode mudar o design da aplicação com certa segurança. Não da pra negar que escrever testes incorrem em custos mas considerando um projeto grande é algo imprescindivel.

Entusiasta Java Membro desde: 02/06/2009 16:28:55 Mensagens: 22 Offline

Eu acho que qualidade de verdade a gente só consegue enxergar depois de algumas iterações. Como o pessoal aí já disse, as pessoas acabam entregando código para atender o prazo e acabam deixando a qualidade um pouco de lado (afinal, o gerente e o cliente normalmente só vão olhar para o prazo e verificar se o sistema está funcionando). Você vê se existe qualidade ali se nas próximas iterações você perde muito tempo pagando débito técnico (ou seja, tentando sumir com as gambiarras e repetições feitas na pressa) para conseguir entregar as novas funcionalidades. A velocidade que se ganhou no começo fazendo as coisas de qualquer jeito uma hora você pode ter que pagar com juros.

JavaTeenager Membro desde: 02/10/2007 10:56:53 Mensagens: 162 Offline

TDD é desenvolver atraves de testes e nao testar pra ver se tem erro. A arquitetura emerge (que chique) dos testes, não do debate infinito numa mesa de reunioes sobre qual seria a melhor arquitetura, pois os testes vao mostrar qual a melhor arquitetura.

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

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.
Quando resolvo fazer o refactoring, consigo reaproveitar bastante parte do código, porem boa parte dos testes são jogados fora.

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.

Java Ninja Membro desde: 20/06/2005 20:10:58 Mensagens: 294 Offline

Para os chefes da empresa o programador é bom se faz a tarefa rápido e não da pau na hora.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

vitu wrote:
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.

vitu wrote:
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.

vitu wrote:
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.

vitu wrote:
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.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

vitu wrote: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.

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"

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

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".

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Leonardo3001 wrote: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.

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.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

André Fonseca wrote: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.

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

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

Leonardo3001 wrote: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.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

YvGa wrote:

Leonardo3001 wrote: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.

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

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

mochuara wrote:

YvGa wrote:

Leonardo3001 wrote: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.

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

Eu disse que se resumia?

Notícias, artigos e o maior fórum brasileiro sobre Java