The Principle Of Too Much Magic

Many programmers have a tendency to be Too Smart. Being Smart, they introduce various kinds of Magic into their software. This will usually lead to a software design that is more generic, dynamic and flexible than is needed, has more features than is needed, and is hence much more complex than is needed.

Muito bom!!! Deveria ser leitura obrigatória para o povo que curte os modismos da tecnologia!!!

Fiquei chateado. :?

Achei interessante o comentario do carinha que desnvolve o commons-attributes. Mais tb temos que olhar pelo outro lado, se não for essa coceirinha que muitos desenvolvedores tem de criar novas soluções para seus projetos, muitas vezes mais complexas porem inovadoras e flexiveis. A tecnologia não iria avançando tão rápido e dando um leque de oportunidade. Ele pode nem usar o commons-attributes, mas esse projeto pode servir de ponto de partida para novas ideias e contribuir para o crescimento da tecnologia de uma maneira ou de outra.

Acho que o recado é bem vindo e eu mesmo vou procurar sempre refletir quanto a isso. valeu pelo link Rafael!

Falando nisso, alguem teria algum material sobre Dynamic proxying :twisted: :?:

O codigo fonte do Nanning - http://nanning.codehaus.org

Super fácil de entender, mas em alguns lugares parece uma queda de braço entre a java.lang.reflect.Proxy e a java.lang.ThreadLocal

uhaqhahaha eu tb

CV, seu calo foi " …your collegues call you Harry Potter" ?!?

Tá tá … ele tem uma razão bem parcial.

Eu tenho programado usando o frameworks em cima de framework em cima de framework e meu código não está mais complexo … muito pelo contrario, vc abre e ja bate o olho na lógica do meu negocio pois soh isso existe, o resto esta tudo configurado nos frameworks.

Se nao vai ser qq um q vai conseguir ver/ler/dar manutencao eu nao to nem ligando … minha equipe (eu e mais um) consegue entao todo mundo pode conseguir.

O problema nao eh nem usar magica, mas como o titulo diz, magica demais. Parece ocorrer muito nos casos onde o cara subiu um level e quer botar em pratica tudo o que ele aprender, ou entao quando eh um super cara em uma equipe nao tao super.

Claro, isso eh uma generalizacao e seria injusto querer dizer que tudo mundo eh/sera assim. Como disseram no post anterior, se nao tivesse a “magica”, codar seria algo bem mais pe-no-saco.

Rafael

“smota”:

Se nao vai ser qq um q vai conseguir ver/ler/dar manutencao eu nao to nem ligando … minha equipe (eu e mais um) consegue entao todo mundo pode conseguir.

concordo plenamente :!: :idea:

Outro problema é usar mágica pelo simples fato de usar mágica.

Pode ser muito legal você ter escrito um sistema de geração de código que trabalha com um meta-meta-modelo definido em xml schemas, depois você escreve o meta-modelo em xml e por último o modelo também em xml para finalmente isso ser tranformado em texto usando templates escritos em velocity.

Parece surreal? Mas existe, e está em produção right here, right now.

Ha ! um detalhe MUITO importante é:
a mágica serve para elevar nosso ego !!!
ou vai me dizer q alguém conhece uma pessoa q faça algo diferente e legal q não fique orgulhosa de si mesmo. E todo mundo precisa se orgulhar do q faz, senão o trabalho fica massante…

Exatamente.

Mas o melhor argumento é:

Alguém deveria mostra isto para o Gubi!!!
(Marcos Dimas Gubitoso, professor da usp, programador perl inveterado… reza a lenda que ele é o autor da exp regular para encontrar qualquer arredondamento do número pi).

Ainda…
Algumas palavras curiosas em perl (palavras-reservadas):
[list]
bless (abençoa uma estrutura de dados para era virar uma classe)
magic
study
die (funciona como uma ameaça para o programa: do or die.
ex: fopen (arquivo.txt) or die ("nao abri arrrrrr....."); )
[/list]
Dá para perceber que esta linguagem não é muito apropriada para análise de sistemas. Acho que seu uso é mais vinculado à cabalística…