Lançado o MentaBean - Persistencia simples via configuração programática

brunohansen wrote:
Minha pergunta ainda continua: Mauricio e Paulo se vcs protegem tanto os testes pq vcs não criticam tambem a versão em produção do JForum que não tem teste?

E voce acha que nao levo esporro por causa disso?

Deveria ter feito testes desde o inicio? sim. Fiz? Nao. E o resultado é a necessidade de testar tudo no braco, e contar com a ajuda da lua ou marte para tudo funcionar.

Em dado momento da tua carreira (geralmente quanto esta iniciando), aceitar e compreender corretamente a necessidade e importancia de testes é desafiador, principalmente pq faz parte da natureza do ser humano tomar atitude somente quanto a agua bate na bunda.

Porem, uma coisa eh nao compreender e nao usar pelos motivos citados, MAS utilizar ("antes tarde do que nunca"), e outra coisa é defender o ponto de que testes sao ruins e negar-se a adotar tal pratica.

Rafael

Rafael Steil wrote:
Em dado momento da tua carreira (geralmente quanto esta iniciando), aceitar e compreender corretamente a necessidade e importancia de testes é desafiador, principalmente pq faz parte da natureza do ser humano tomar atitude somente quanto a agua bate na bunda.

Porem, uma coisa eh nao compreender e nao usar pelos motivos citados, MAS utilizar ("antes tarde do que nunca"), e outra coisa é defender o ponto de que testes sao ruins e negar-se a adotar tal pratica.

Olha para tras e perceber que faziamos coisas que hoje achamos ruim, é sinal de evolução. Parabens Rafael.

Eu ainda vou blogar sobre isso, mas lembro da epoca que o Villela falava de testes unitarios e eu achava tudo isso ridiculo. Depois de um tempo, quando voce comeca a sofrer com alteracoes do core de algum sistema, comeca a pensar. E depois os testes passam a ser parte da diversao!

Algo que impede o pessoal a adotar testes é que o sistema ja comecou sem testes, ai é praticamente impossivel adotar TDD, porque o codigo ja esta naturalmente dificil de ser testado e muito acoplado!

renato3110 wrote:Saoj, e como vc testou isso depois? Executando à mão todos os 10.000 métodos dependentes?

Vc não entendeu. Eu criei um novo método. O método antigo continou lá intacto. A única coisa que poderia quebrar ali era o módulo que eu estava fazendo no momento, pois só ele estava usando o meu novo método, ou seja, criei esse método a fim de preservar o outro crítico, pois alterá-lo seria muito arriscado. Programação defensiva!

JavaBaby Membro desde: 08/04/2005 17:20:52 Mensagens: 78 Offline

saoj wrote:

renato3110 wrote:Saoj, e como vc testou isso depois? Executando à mão todos os 10.000 métodos dependentes?

Vc não entendeu. Eu criei um novo método. O método antigo continou lá intacto. A única coisa que poderia quebrar ali era o módulo que eu estava fazendo no momento, pois só ele estava usando o meu novo método, ou seja, criei esse método a fim de preservar o outro crítico, pois alterá-lo seria muito arriscado. Programação defensiva!

E se um dia seu chefe alterasse o metodo criado por ele? Ele teria que se lembrar de alterar o seu também? Como se você nem se quer avisou a ele? Será que isso é uma boa pratica? Isso me parece mais POG.

Falar a verdade eu gosto do mentawai, usei em alguns projetos da universidade, mas coisa simples, gostei, achei divertido trabalhar com ele.
Mas tive muitos problemas, quando era versão ainda 1.2, 2 bugs que eu descobrir e reportei lá, sendo que eram coisas bobas no voFilter e no filter do Hibernate, algo se tivesse testes não ia para produção com aquelas falhas.

Não acho o framework inutil, mas acho que você se livraria de diversos bugs reportados se estivesse feito rotinas de testes e obvio rodassem elas.

E o bug no vo filter foi algo como já discutido aqui, em uma versão anterior que ele estava funcionando redondo, na outra versão ele já estava dando bug.

Creio que se você juntamente com sua equipe, ao invés de gastar tempo com o mentaBean, poderia realizar as rotinas de testes, assim muitas pessoas que "não confiam" pensariam em adotar o uso framework. Quem sabe depois você voltaria a tentar no mentaBean, isso se você achar viavél.

saoj wrote:A única coisa que poderia quebrar ali era o módulo que eu estava fazendo no momento, pois só ele estava usando o meu novo método, ou seja, criei esse método a fim de preservar o outro crítico, pois alterá-lo seria muito arriscado. Programação defensiva!

Isso nao eh programacao defensiva. Em nenhuma das definicoes de programacao defensiva que eu consegui encontrar, "copiar codigo critico e fazer alteracoes na copia para evitar mudancas no design" nao esta la. Como o thiagoaos citou, isso eh mais tipico de uma gambiarra do que de um trabalho bem-feito, por trazer as consequencias citadas aqui:

http://en.wikipedia.org/wiki/Software_brittleness

Alias, se vc tiver um tempinho pra ler, isso aqui ajuda bastante:

http://en.wikipedia.org/wiki/Defensive_programming

saoj wrote:

renato3110 wrote:Saoj, e como vc testou isso depois? Executando à mão todos os 10.000 métodos dependentes?

Vc não entendeu. Eu criei um novo método. O método antigo continou lá intacto. A única coisa que poderia quebrar ali era o módulo que eu estava fazendo no momento, pois só ele estava usando o meu novo método, ou seja, criei esse método a fim de preservar o outro crítico, pois alterá-lo seria muito arriscado. Programação defensiva!

Programação defensiva é a única saída que se tem quando não se tem testes, isso é óbvio.

A questão é, isso é bom? Digo, tenho certeza de que você é alguém competente, mas todo mundo que trabalha, trabalhou ou trabalhará com você é tão competente? Muitas vezes não, né? E como assegurar a confiabilidade nesses casos?

Os testes mostram sua vantagem no longo prazo, de forma que você pode assegurar que, se um bug que aparece hoje é testado, ele não reaparecerá amanhã quando alguém fizer uma alteração em um método.

Sergio, não encare isso como um ataque pessoal, mas acredito que você ganharia bastante se revisse sua posição sobre testes.

Sobre o MentaBean, ainda não o olhei em detalhes. Depois eu emito uma opinião sobre o próprio.

Aos usuários: por favor, vamos nos respeitar mais, sem transformar isso aqui numa guerra de egos. Eu fico triste em ver egolatria em um forum técnico.

E se um dia seu chefe alterasse o metodo criado por ele? Ele teria que se lembrar de alterar o seu também? Como se você nem se quer avisou a ele? Será que isso é uma boa pratica? Isso me parece mais POG.

Os métodos viraram duas coisas indepedentes, e não a mesma coisa duplicada.

Concordo que duplicação de código é ruim. Isso foi apenas um exemplo de um caso isolado. É claro que isso não é o dia a dia, até porque raramente se tem a necessidade de alterar uma classe crítica. O máximo que faz é estende-la respeitando os contratos, e se vc analisar por essa ótica foi basicamente o que eu fiz. Precisava de um método para fazer algo parecido mas diferente. O certo seria estender esse método, mas no meu caso a alteração era no algoritmo.

Só quiz exstrapolar mostrando que as vezes é melhor ser prático e obter resultados concretos de forma segura, do que ser um belo teórico que modifica uma parte crítica, roda os testes e perde o emprego.

Como eu disse: "Alguns vão me tacar na fogueira da inquisição da informática por isso".

E o bug no vo filter foi algo como já discutido aqui, em uma versão anterior que ele estava funcionando redondo, na outra versão ele já estava dando bug.

Fizemos uma alteração crítica, por opção, nessa versão. Basicamente trocamos a estratégia de injection de PULL para PUSH. Mais sobre isso em: http://forum.mentaframework.org/posts/list/482.page

Sim, concordo com vc! Testes poderiam ter ajudado nessa mudança. A questão é que fazer altearções críticas como essa que foi feita é RARO. Se vc faz modificações críticas no seu sistema toda hora (ou uma vez por semana que seja), algo está errado. Ou com o seu sistema (problemas de arquitetura) ou com vc (maluco!).

Talvez tenhamos chegado a uma boa conclusão aqui. Testes podem ser importantes na fase inicial de um projeto, onde a arquitetura/funcionalidades/etc ainda não estão muito maduras, e as chances de ter que modificar partes críticas são maiores. Graças a Deus o Mentawai já passou dessa fase. O core está congelado, estável, sem bugs em aberto. Ninguém faz modificações críticas no core sem apresentar motivos bem fortes para isso. O Rubem fica meio puto comigo por causa disso. Mas isso é disciplina, organização e comprometimento com os ccontratos. Sem testes...

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

Por mais raro que seja, as alterações críticas, justamente por serem críticas, não devem nunca quebrar o sistema. E pra mim um software que não está aberto à modificação de qualquer de suas partes, mesmo as críticas (uma "burguesia" no código?), é um software atrofiado. Você deixa de aceitar ou ter boas sugestões por acreditar que aquela parte do código é "santa".

thiagoaos wrote: Será que isso é uma boa pratica? Isso me parece mais POG.

Epa!! Não fala mal de POG não hein!! rss!!!

renato3110 wrote:Por mais raro que seja, as alterações críticas, justamente por serem críticas, não devem nunca quebrar o sistema. E pra mim um software que não está aberto à modificação de qualquer de suas partes, mesmo as críticas (uma "burguesia" no código?), é um software atrofiado. Você deixa de aceitar ou ter boas sugestões por acreditar que aquela parte do código é "santa".

Sua colocação foi muito boa. Não tenho como descordar disso. Acho que é uma simples questão de estilos. Se todo mundo pensasse igual no mundo, as coisas seriam chatas demais.

Fico pensando aqui: Vc acha que o Kernel do Linux é santo, ou um belo dia o cara acorda com uma coceira lá, olha o código e fala assim: "PQP, isso está uma merda. Vou refatorar!"

Eu rescrevi o Lohis do zero umas 3 ou 4 vezes. A cada nova reescrita eu olhava pra coisa e falava assim: "PQP, o anterior estava uma merda, esse aqui ficou 10 vezes melhor, que legal!". Depois da quarta reescrita o código tava bem bonito, até plugin suportava, mas o projeto nunca chegou a lugar nenhum.

Acho que quando vc tem um sistema não-pequeno, vc pode melhorá-lo quase que eternamente. Sempre dá para melhorar mais um pouco, refatorar aqui e ali. A questão é: o que vc realmente quer com esse sistema? Melhorá-lo eternamente ou cumprir sua proposta?

JavaGuru Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

Por que colocas "Melhorá-lo eternamente ou cumprir sua proposta" como propostas mutuamente exclusivas?

bzanchet wrote:Por que colocas "Melhorá-lo eternamente ou cumprir sua proposta" como propostas mutuamente exclusivas?

Alguns conseguem equilibrar isso, e esses talvez sejam os mais certos.

Outros caem mais para um lado do que para o outro.

Eu acabei caindo para o lado da proposta, do resultado. Foi uma escolha pessoal influenciada pelo meio-ambiente.

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

saoj wrote:Fico pensando aqui: Vc acha que o Kernel do Linux é santo, ou um belo dia o cara acorda com uma coceira lá, olha o código e fala assim: "PQP, isso está uma merda. Vou refatorar!"

Eu não sei como funciona, na verdade eu não entendo como uma coisa dessas escrita em C consegue funcionar tão bem! Devem ser alienígenas que programam! rsss

Aliás seria interessante saber como eles fazem pra saber se uma linha adicionada ou removida no kernel não ferra uma outra parte dele lá na PQP...e também os testes eternos do Debian até um release estável, que testes são esses???

saoj wrote:o que vc realmente quer com esse sistema? Melhorá-lo eternamente ou cumprir sua proposta?

As duas coisas devem andar juntas. Existe uma culltura entre muita gente de "finalizar" o sistema, considerando modificações no mesmo como o "o usuário não sabe o que quer" ou "do jeito que estava antes era errado".

Eu acredito numa noção de "software vivo". O usuário não saber o que quer, ou mudar de opinião é natural, o mundo gira, e o software tem que evoluir com as pessoas , com o tempo, e não o contrário. E do jeito que estava antes não era errado, era apenas uma etapa anterior da "vida" do sistema. Quando você "termina" um sistema na verdade está matando o software, mais ou menos como um Tamagochi

saoj wrote:É claro que isso não é o dia a dia, até porque raramente se tem a necessidade de alterar uma classe crítica.

De certa forma, o bom design OO dita que nenhuma classe no seu sistema deve ser critica: o Shoes provavelmente sabe muito mais disso que eu, mas vc provavelmente tem um problema serio de acoplamento se vc chama qualquer classe no seu sistema de "critica"; depois desse auê todo sobre bom design e boas praticas OO que vc fez, eu esperava mais de voce (e da sua equipe, que movimenta quatrilhoes de døøøøølares por nanossegundo).

JavaGuru Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

saoj wrote:

bzanchet wrote:Por que colocas "Melhorá-lo eternamente ou cumprir sua proposta" como propostas mutuamente exclusivas?

Alguns conseguem equilibrar isso, e esses talvez sejam os mais certos.
Outros caem mais para um lado do que para o outro.
Eu acabei caindo para o lado da proposta, do resultado. Foi uma escolha pessoal influenciada pelo meio-ambiente.

Eu perguntei o porque, mas apenas reafirmaste serem dois objetivos distintos e excludentes.

Modificando a questão: por que "melhorar eternamente" não pode ser parte de "cumprir sua proposta"?

depois desse auê todo sobre bom design e boas praticas OO que vc fez, eu esperava mais de voce (e da sua equipe, que movimenta quatrilhoes de døøøøølares por nanossegundo).

Me desculpe se te decepcionei. Ninguém é perfeito. O correto é subjetivo. Um pensamento e um estilo de um vai ser aprovado por alguns e condenado por outros. Em algumas empresas eu me sairia bem, já em outras eu não seria nem contratado. Levaria pau nas perguntas sobre UML e JUnit.

Acho que a única coisa que não é subjetiva é o DINHEIRO que uma empresa ganha. Isso todo mundo concorda, aprova e bate-palma. Desde que seja obtido honestamente... Dá uma procurada em google.finance.com. Veja o Google por exemplo: eles divulgam o faturamente anual da empresa lá, mas procurando bem não encontrei nenhuma métrica sobre a qualidade do sistema deles. Quantos BUGs foram detectados, se há testes e essas coisas não estão listadas lá...

Quando as pessoas gastam seu rico dinheirinho para comprar as ações da google, acho que a última coisa que eles pensam era se tem teste ou não...

Eu acho que no mundo coorporativo só uma coisa conta: RESULTADOS. E o ser humano convencionou DINHEIRO para se medir isso, pois caso contrário, isso tb seria subjetivo.

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