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

Assuntos Gerais Notícias
#201

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

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…

#202

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

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

#203

[quote=renato3110]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”.
[/quote]

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. :frowning:

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?

#204

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

#205

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.

#206

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

[quote=saoj]o que vc realmente quer com esse sistema? Melhorá-lo eternamente ou cumprir sua proposta?
[/quote]

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 :smiley:

#207

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

#208

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.[/quote]
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”?

#209

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.

#210

Na verdade, eu duvido que eles chegem a pensar nisso, porque todo mundo sabe que o Google |valoriza| |absurdamente| |testes| de software, então assume-se que é de conhecimento público que eles testam muito.

#211

[quote=bzanchet]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”?[/quote]

É que a maioria das pessoas acham que são 2 objetivos distintos e excludentes.

Eu penso diferente: acho que boas práticas (TDD inclusive) servem p/ que vc possa “cumprir sua proposta” e ainda assim conseguir “melhorar eternamente”.

#212

Ops, olha aqui um póbrema. Testes são ainda mais importantes quando um sistema está envelhecendo, porque eles garantem que velhos bugs não vem a tona mesmo depois que novas funcionalidades foram adicionadas ou que alterações, críticas ou não foram feitas. E convenhamos, código que não se altera de jeito nenhum é lenda.

Mas eu acho que precisamos de um novo conceito aqui, o que é uma alteração crítica? Crítica no sentido de que? De quebrar o sistema?

Eu já vi até a adição duma “,” quebrar um sistema inteiro. Isso é uma alteração crítica?

#213

[quote=Maurício Linhares]

Mas eu acho que precisamos de um novo conceito aqui, o que é uma alteração crítica? Crítica no sentido de que? De quebrar o sistema?

Eu já vi até a adição duma “,” quebrar um sistema inteiro. Isso é uma alteração crítica?[/quote]

Essa discussão não vai ter fim. Tá pior que, vasco e flamengo, eclipse x netbeans, etc. Acho que chegou a hora de focarmos nossas energias em outras coisas mais produtivas…

Eu já me convenci de que teste é BOM. Ruim não pode ser. Não consigo ver uma desvantagem de um sistema que possua testes… A 6 meses atrás o Rubem falou que ia fazer os testes unitários do Mentawai. Eu dei a maior força…

O problema é que eu não sei, não gosto e não tenho tempo no momento para pensar em testes. E isso a constituição me garante o direito, assim como garante liberdade religiosa. Se amanhã eu mudar de idéia ou de religião, vcs vão ficar sabendo, e daí podem jogar esse papo louco aqui na minha cara, pois vou merecer… Até lá, vamos debater outras coisas … :slight_smile:

#214

Aeeeeeeeeeee!!! THE END!!! :smiley:

#215

[quote=saoj][quote]
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).
[/quote]

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.

[/quote]

Eh… vejo que vc é adepto do POG… “Está funcionando ? então está certo.”

#216

E lá vem pedrada…

#217

[quote=saoj][quote=Maurício Linhares]

Mas eu acho que precisamos de um novo conceito aqui, o que é uma alteração crítica? Crítica no sentido de que? De quebrar o sistema?

Eu já vi até a adição duma “,” quebrar um sistema inteiro. Isso é uma alteração crítica?[/quote]

Essa discussão não vai ter fim. Tá pior que, vasco e flamengo, eclipse x netbeans, etc. Acho que chegou a hora de focarmos nossas energias em outras coisas mais produtivas…

Eu já me convenci de que teste é BOM. Ruim não pode ser. Não consigo ver uma desvantagem de um sistema que possua testes… A 6 meses atrás o Rubem falou que ia fazer os testes unitários do Mentawai. Eu dei a maior força…

O problema é que eu não sei, não gosto e não tenho tempo no momento para pensar em testes. E isso a constituição me garante o direito, assim como garante liberdade religiosa. Se amanhã eu mudar de idéia ou de religião, vcs vão ficar sabendo, e daí podem jogar esse papo louco aqui na minha cara, pois vou merecer… Até lá, vamos debater outras coisas … :-)[/quote]

Sérgio,

acredito que ninguem goste de fazer teste, e tbm que ninguem tenha tempo, todo mundo preferiria fazer algo novo a ficar fazendo aquelas chatices de testes unitários. Na verdade testes é algo que se faz necessário…

Eu respeito totalmente a sua opinião, mas queria fazer uma crítica construtiva a você. Eu acho que você se queimou um pouco nessa thread perante a comunidade Java afirmando que você é anti-testes e que se for preciso vc duplica código só pra não mexer em um lugar. É claro que cada um tem sua opinião, e se vc gosta de trabalhar assim, então ponto final. O grande problema é que vc é um dos principais desenvolvedores de um framework que é bastante conhecido, e talvez essas duas declarações possam gerar danos a imagem do Mentawai…o que seria uma pena…mas eu acredito que isso jah tenha acontecido. Muitos não irão mais usar o Mentawai depois dessas suas declarações…

Não quero gerar polêmica, apenas quis ajudar, pq acho realmente muito legal a sua contribuição para a comunidade Java. Você faz e não simplesmente fala fala e fala…

#218

Acho que o resto da equipe desenvolve funcionalidades novas mais rapido do que eu escrevo teste. Falta animo e folego para comecar o trabalho :stuck_out_tongue:

#219

Com todo respeito a sua opinião e a sua crítica “construtiva”, vc está enganado. Muitos já usam e muitos continuarão usando. Pode acender uma vela aí, fazer macumba, pensamento negativo, e tudo mais, ok? Se vc não quiser usar, fique a vontade. Há muitas outras alternativas (boas tb) por aí… Lembre-se que quando fiz o mentawai, muita gente falou que eu era maluco. Acho que valeu a pena não acreditar nelas, do mesmo jeito em que não acreditarei nessa sua crítica “construtiva”.

Não dependo do Mentawai para nada. O Mentawai é um filho pra mim, algo de que tenho orgulho. Tenho emprego que nada tem haver com o Mentawai. Tenho outros negócios dentro e fora da área de tecnologia, logo o Mentawai não é o meu ganha pão. Se ele acabasse amanhã já teria valido muito a pena para mim, para os membros fiéis da equipe de desenvolvedores, e acho que para a comunidade também.

Veja no nosso fórum que recebemos muitos emails e mensagens de incentivo. E vou te dar um dica: quando vc faz essa crítica “construtiva”, esse incentivo e apoio, não existe nada mais forte, nada mais poderoso para me incentivar a ir ainda mais longe com o projeto. Obrigado por essa verdadeira injeção de ânimo!

#220

Testes automatizados na verdade poupam tempo, não gastam tempo. Além disso, desenvolvedores não gostarem de testar não é novidade. Eu não conheço nenhum que goste. Mas isso é totalmente diferente de escrever testes automatizados, que é resolver um problema realmente inconveniente (testar) escrevendo umas poucas linhas de código que resolvam o problema através de automação (um caso de teste), que é justamente o que programadores adoram fazer. Em suma, testar != escrever testes. Testar é ruim, escrever testes é bom. Ah, a sensação de ver a barrinha do JUnit verdinha ao rodar os mais de 500 testes do sistema (ou mesmo se forem 10, no início) após fazer um bug fix ou uma boa refatoração não tem preço. Embora eu não ache que código sem testes seja inútil, eu sinto como se não tivesse concluído trabalho algum se não acompanho a adição de uma nova funcionalidade com seu caso de teste correspondente.

Para aqueles que querem se dar uma chance de aprender e gostar de testes automatizados, recomendo um único artigo: Test Infected (http://junit.sourceforge.net/doc/testinfected/testing.htm).

[quote=microfilo]
Acho que o resto da equipe desenvolve funcionalidades novas mais rapido do que eu escrevo teste. Falta animo e folego para comecar o trabalho :stuck_out_tongue: [/quote]

Isso é porque todos os desenvolvedores deveriam ter responsabilidade de escrever testes. Eu trabalhei por três anos no projeto Eclipse (http://eclipse.org/eclipse), e lá se espera que todos os desenvolvedores acompanhem modificações significativas com novos casos de testes (também fazem análise, projeto, implementação, testam manualmente, dão suporte no newsgroups e fazem triagem de bugs, mas isso é outra estória). Ter um desenvolvedor ou um time dedicado a somente escrever testes é equivocado pela minha experiência.