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.
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?
[quote=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. [/quote]
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
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.
Nunca otimize até ter uma solução não otimizada perfeitamente compreensível;
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;
Após tentar otimizar um trecho, meça o ganho de performance. Se você não conseguiu ganho, desfaça as modificações.
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.
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”)
