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.
Respondendo na minha opiniao:
[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”?
[/quote]
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.
A maioria dos erros está em falhas na comunicacao, nao necessariamente nessa fase ou naquela, mas falhas de comunicacao durante todo o processo.
Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado. Fora isso, qualquer coisa que se diga sobre qualidade é blablabla.
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.
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.
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?
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.
[quote=s4nchez][quote=YvGa]
Entregar uma aplicacao funcional, que atenda as espectativas do cliente, dentro do prazo combinado. Fora isso, qualquer coisa que se diga sobre qualidade é blablabla.
[/quote]
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?[/quote]
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.
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 é 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.
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…
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.
[quote=vitu]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.
[/quote]
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.
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.
[quote=mochuara][quote=vitu]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.
[/quote]
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.[/quote]
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.
[quote=juliocbq]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. [/quote]
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.
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.[/quote]
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.
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.[/quote]
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.[/quote]
Geralmente não perdem. Apenas passam a se denominarem “preguiçosos” e trabalham em cima de várias camadas de reutilização.
[quote=YvGa]
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. [/quote]
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.
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.
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.
Para os chefes da empresa o programador é bom se faz a tarefa rápido e não da pau na hora.