Projeto Pragmático - Pragmatic Design

Frank Teiti publicou um artigo no TheServerSide sobre "projeto pragmático", aonde ele diz que a maioria dos programadores OO estão mais preocupados em dar uma solução elegante ao problema (eu gostaria muito de acreditar nisso...) do que dar solução a problemas como requisitos não funcionais, como peformance, responsividade, independência de protocolos.

Texto completo: Pragmatic Desing

Infelizmente, tenho que discurdar da opinião dele, acho que primeiro resolve-se o problema de forma elegante e depois preocupa-se com performance. Agora, como você faz?

Concordo com vc. Afinal, se pensassemos o contrario, Java nunca teria chegado onde chegou.

Cara, tem verdade aí...

Conheço muita gente que trabalha com Java, 70 a 80%, e perde muito tempo especulando, querendo sempre aplicar "O Estado da Arte" e esquece fatores realmente significativos quando em Produção, forçando a barra para usar isto ou aquilo, aplicar padrões desnecessariamente etc.. O que muitas vezes aumenta a complexidade do sistema por inteiro, enquanto poderia dar uma solução simples.

Claro que deve-se pensar em uma forma elegante, mas de modo objetivo e mensurando os prazos corretamente (treinamento, implementação etc).

Fazer às cegas ou tentar ver além do horizonte é o ideal (soou tão clichê falar "nem um nem outro")

seufagner wrote:
Conheço muita gente que trabalha com Java, 70 a 80%, e perde muito tempo especulando, querendo sempre aplicar "O Estado da Arte" e esquece fatores realmente significativos quando em Produção, forçando a barra para usar isto ou aquilo, aplicar padrões desnecessariamente etc.. O que muitas vezes aumenta a complexidade do sistema por inteiro, enquanto poderia dar uma solução simples.

Bem, talvez eles não estejam tendo sucesso em fazer algo elegante, já que elegante é sempre simples.

Acho que o autor exagerou um pouco, de propósito, para provocar.

Eu acho que em primeiro lugar você deve, sim, fazer um design elegante. Não dá para negar a importância da refatoração ou dos patterns.

É muito mais fácil otimizar e identificar erros em um software elegante também.

Mas existe um limite. Muitas vezes não chegaremos a um design elegante até fazermos um não tão elegante assim. E muitas vezes teremos não só que refatorar o resultado, como refazer conceitos inteiros. Acho que é aí que morre o perigo. Muitos projetistas "travam" ao tentar chegar num grau de elegância que o conhecimento deles ainda não permite.

Pior ainda quando, em nome da elegância, tentam tornar o software "mais flexível" e "mais adaptável", montando um design elegantíssimo, mas ao mesmo tempo mais demorado, mais complexo e totalmente fora das necessidades do cliente. E o pior, fazem isso gastando a grana e o tempo desse próprio cliente...

Essa discussao 'e uma faca de dois gumes, muitas vezes voce precisa sacrificar sim a elegancia pra ter performance. principalmente quando voce nao ta trabalhando com java

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 521 Offline

Uma coisa é incontestável: em um código elegante é muito mais fácil de se otimizar a performance.

Se um código elegante atende os requisitos de performance (apesar de não ser a solução mais rápida), porque então sacrificar a elegância para ganhar um pouco de performance...

Em uma aplicação bem modelada, é muito mais fácil adicionar controles de cache, por exemplo, caso existam problemas com performance. Acho que a recomendação deve ser: crie um código flexível, pois quando ele precisar ser performático será muito mais fácil trabalhar com ele.

Smalltalk Membro desde: 19/10/2006 17:31:10 Mensagens: 2 Offline

uma velha máxima que todos conhecem KISS (Keep It Simple Stupid) se conseguir resolver dessa forma, com certeza ficará elegante

E tem as regrinhas da otimização:

1. Não otimize até que seja estritamente necessário;

2. Nunca otimize até ter uma solução não otimizada perfeitamente compreensível;

3. Os problemas de performance estão na menor porção do seu código e nem sempre os locais em gargalo são óbvios. Use um profiler para identificar qual é essa porção e otimiza-la;

4. Após tentar otimizar um trecho, meça o ganho de performance. Se você não conseguiu ganho, desfaça as modificações.

5. Documente que o código está otimizado, senão alguém pode refatora-lo no futuro para uma versão simples e recair novamente no problema de performance. Preferencialmente, coloque os requisitos de performance daquele método no Javadoc.

cristianmedeiros wrote:uma velha máxima que todos conhecem KISS (Keep It Simple Stupid) se conseguir resolver dessa forma, com certeza ficará elegante

Concordo com outras pessoas aqui que disseram que um design simples é um design elegante.

A simplicidade é um bem enorme. E "simples" não quer dizer ruim, mal feito, mas sim uma solução que vai direto ao ponto. O ponto que eu acho mais complicado é saber qual parte do sistema projetar para que fique flexível, pois muitas vezes é necessário conhecimentos de negócio para saber onde o sistema pode mudar futuramente, etc.

Patterns se aplicam onde são necessários.

O problema é que tem desenvolvedor xiita por DP e aplica a torto e à direito, aumentando desnecessariamente a complexidade.

Estes, em busca da "elegância", acabam no sentido contrário!

Porque é tão complicado simplificar? E porque é tão simples complicar?

Impressionante como o TSS perdeu qualidade após a saída do Marinescu. Este artigo é uma volta a 2002, completamente dispensável.

Enquanto isso no infoQ:

http://www.infoq.com/articles/Elssamadisy-adoption-patterns
http://www.infoq.com/minibooks/ruby
http://www.infoq.com/minibooks/grails
http://www.infoq.com/minibooks/domain-driven-design-quickly
http://www.infoq.com/minibooks/scrum-checklists
...

É aquela velha história: resolver, resolver de maneira elegante, resolver de maneira performatica.

valeuz...

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