Projeto Pragmático - Pragmatic Design

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

seufagner:

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.

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

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.

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.

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:

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

valeuz…

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