[Desenvolver] Velocidade vs. Qualidade

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

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.

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

Respondendo na minha opiniao:

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

Não, sao menos produtivos. Voce pode ate pensar que eles estao fazendo rapido, mas antes mesmo da aplicacao ir pra producao eles ja estao enrolados em bugs, e o processo passa a ficar mais lento.

Quando o assunto é manutencao de software em producao, talvez eles sejam mais produtivos enquanto voce perde algum tempo refatorando. Mas isso se inverte em pouco tempo e cada vez mais a medida que voce vai refatorando e conhecendo as gambiarras.

O meu conselho quando pegar esses softwares monstros, cheios de gambiarra, é ter paciencia e ir arrumando devagar, sem tentar uma ruptura na marra. A nao ser que ele ja esteja em colapso.

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

A maioria dos erros está em falhas na comunicacao, nao necessariamente nessa fase ou naquela, mas falhas de comunicacao durante todo o processo.

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

Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado. Fora isso, qualquer coisa que se diga sobre qualidade é blablabla.

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

Só pra concluir.

Sobre produtividade dos programadores: nao subestime um programador só porque voce pensa que leu mais livros que ele, ou porque ele pouco ouviu falar em Martins Fowlers. Pra que voce tenha produtividade é preciso ter dominio absoluto das ferramentas com as quais voce trabalha. Se voce esta sendo lento em relacao a outro programador algum motivo tem pra isso e raramente vai ser só porque ele esta fazendo gambiarras.

Praticas como TDD invariavelmente tornam o desenvolvimento mais rapido, se voce nao consegue ser produtivo, veja onde voce esta enroscando e estude a tecnologia ou a metodologia pra que possa melhorar.

Cuidado ao apontar o dedo a programadores baseado em conhecimentos teoricos, pode chegar a hora em que voce vai enroscar num problema que ele vai resolver de olhos fechados porque ja viu aquilo 300 vezes, mesmo sem nunca ter ouvido falar em Design Patterns.

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

YvGa

Eu acho o que o TDD quando usado com uma alta cobertura, torna o desenvolvimento mais lento e tedioso.

E mesmo assim sempre aparecem os bugs, por mais senior que o desenvolvedor possa ser.

Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado.

Isso tem muita gente que faz. O foda e que as vezes fica um código ou modelagem muito ruim, mas funciona e atende.
E por voce ter que manter acaba tendo que usar parte disso.

Também não ajuda muito toda essa propaganda de ferramentas RAD milagrosas, que geralmente só fazem o feijão com arroz. E acabam sendo usadas em tudo.

Qualidade igual aplicação muito bem testada?

O prazo ainda é o item mais importante?

YvGa wrote:
Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado. Fora isso, qualquer coisa que se diga sobre qualidade é blablabla.

Consigo imaginar em pelo menos duas situacoes onde codigo de baixa qualidade atende todos seus requisitos: 1) seguranca: seu cliente pode estar feliz da vida enquanto seu software pode ser hackeado facilmente; 2) manutencao: no dia seguinte do prazo combinado, qualquer mudanca no sw eh tao complicada que vale mais a pena jogar fora e comecar do zero.

Ou isso tudo eh blablabla tambem?

já vi bastante isto, geralmente em início de projeto, quando já se passaram umas 3 iterações, e começa a correr atrás da velocidade copiando e colando código afim de justificar sua boa produtividade, sem se importar com a quantidade de redundância gerada e consequente overhead por consequente bugs clonados e bugs gerados por manutenções, tendo consequente novos bugs recorrentes de iterações anteriores.

pelo gerente, quando este é um idiota, você será bem visto porque acabou rapidamente, mas depois, serás xingado pelos 2 caso tenha antecipado algo que não irá funcionar ou ficou bem feito.

primeiro a eficiência + inovação, a partir daí busca trabalhar eficazmente, melhorando seu tempo de resposta.
busque sempre a automatização manual de tarefas complementares, faça os scripts fazerem por você pequenas coisas.

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

s4nchez wrote:

YvGa wrote:
Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado. Fora isso, qualquer coisa que se diga sobre qualidade é blablabla.

Consigo imaginar em pelo menos duas situacoes onde codigo de baixa qualidade atende todos seus requisitos: 1) seguranca: seu cliente pode estar feliz da vida enquanto seu software pode ser hackeado facilmente; 2) manutencao: no dia seguinte do prazo combinado, qualquer mudanca no sw eh tao complicada que vale mais a pena jogar fora e comecar do zero.

Ou isso tudo eh blablabla tambem?

Realmente, da forma que falei pareceu aquele velho, "entrega isso aí, depois a gente vê o que faz." Mas nao foi isso que eu quis dizer. Atender as espectativas do cliente inclui tambem a seguranca e agilidade na resposta as alteracoes solicitadas.

O que eu quis dizer é que nao adianta ficar inventando moda, fazendo metrica, leitura disso ou daquilo pra comprovar qualidade. Qualidade se comprova através do que esta pronto e atende aos requisitos.

Eu acho o que o TDD quando usado com uma alta cobertura, torna o desenvolvimento mais lento e tedioso.

Isso pode ser questao de gosto, mas eu nao vejo assim, talvez voce esteja usando de forma diferente, eu nao consigo ver TDD como tedioso, alias acho mais divertido. E lento não tem como ser, é mais rápido sem duvidas. Talvez voce precise dar uma reavaliada na sua abordagem, nao sei. Talvez se voce estiver escrevendo os testes depois da implementacao as coisas podem ficar entediantes mesmo, ou se estiver escrevendo testes demais.

O prazo ainda é o item mais importante?

O prazo é tão importante quanto qualidade, com a diferenca que se houver algum problema ele pode ser renegociado (eu nao gosto disso, e se for preciso faça com antecedencia e jogue limpo com o cliente), já a qualidade nao pode ser negociada.

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.

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

Minha opinião:

Com relação ao mercado infelizmente é valorizado apenas Velocidade em detrimento da Qualidade.

Com relação aos programadores é o que comentaram, o cara ruim que não se importa em fazer de qualquer jeito até pode conseguir produzir coisas mais rápido - e agradar ao chefe por isso - mas lá na frente na manutenção ou na performance, segurança etc é que o bixo pega.

Como quase a maioria dos gerentes, coordenadores, etc não tem essa visão a longo prazo...

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

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.

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

vitu wrote:YvGa

Eu acho o que o TDD quando usado com uma alta cobertura, torna o desenvolvimento mais lento e tedioso.

E mesmo assim sempre aparecem os bugs, por mais senior que o desenvolvedor possa ser.

Ha pouco vc afirmou que a maioria dos erros esta em falhas na comunicação mas TDD é uma otima ferramenta para comunicação e disseminacao de conhecimento entre programadores. Acho que vc esta sendo negligente com sua afirmação ao não considerar as caracteristicas do projeto.

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Online

para mim o software se resume em:

a) arquitetura - Não dará dor de cabeça para mim futuramente;
b) teste - não dará dor de cabeça para o cliente, sendo assim, para mim tmb não.

É difícil uma empresa colocar essas duas variáveis acima da c - velocidade e prazo.

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

mochuara wrote:

vitu wrote:YvGa

Eu acho o que o TDD quando usado com uma alta cobertura, torna o desenvolvimento mais lento e tedioso.

E mesmo assim sempre aparecem os bugs, por mais senior que o desenvolvedor possa ser.

Ha pouco vc afirmou que a maioria dos erros esta em falhas na comunicação mas TDD é uma otima ferramenta para comunicação e disseminacao de conhecimento entre programadores. Acho que vc esta sendo negligente com sua afirmação ao não considerar as caracteristicas do projeto.

Quem afirmou que a maioria dos erros esta nas falhas de comunicacao fui eu, o texto que voce "quotou" é do vitu.

Eu acho TDD imprescindivel, ele nao nos livra de todos os problemas, nem chega perto, mas muitos dos problemas corriqueiros que enfrentamos durante o desenvolvimento se evaporam usando TDD.

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

juliocbq wrote:para mim o software se resume em:

a) arquitetura - Não dará dor de cabeça para mim futuramente;
b) teste - não dará dor de cabeça para o cliente, sendo assim, para mim tmb não.

É difícil uma empresa colocar essas duas variáveis acima da c - velocidade e prazo.

Uma boa arquitetura e testes aumentam a velocidade do desenvolvimento e potencialmente diminuem o prazo de entrega. O problema é que muita gente nao usa os testes para desenvolver, usa apenas na esperanca de "caçar bugs", e ficam naquele debate sem fim, sobre o padrao isso é melhor que o padrao aquilo, essa flechinha tem que ser pintada, aquela nao.

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.

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.

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.

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