A maioria dos sistemas que trabalhei eram de apoio ao negócio (daqueles que mudam pouco, apenas uma vez por dia). Em todos eles um dos requisitos, normalmente formalizado, era “boa velocidade de acesso à informação”, “tempo de resposta pequeno” ou algo parecido. Porém, “boa” e “pequeno” não foram quantificados.
A meu ver, qualquer que seja o sistema, ele deve ter “boa velocidade” e “tempo de resposta pequeno”. Se isto não esta quantificado, exemplo: “tempo de resposta menor que 150ms”, então presume-se que o sistema deva responder em tempos humanamente aceitáveis, principalmente quando se trata de UI.
Mas o fato de não haver quantificação estimulou alguns desenvolvedores a quebrar a flexibilidade do sistema (padrões, camadas, abstrações ou qualquer outro conceito que a arquitetura de software pudesse ter), em troca de um único benefício: performance.
Será que foi uma boa troca? Sim, isto é uma troca. Não é possível ter uma arquitetura flexível do ponto de vista de negócio e ao mesmo tempo ter a melhor performance.
Mas como escolher corretamente?
Se você já desenvolveu qualquer módulo que seja, sabe que algumas funções são mais usadas do que outras. Algumas são mais custosas (em performance) do que outras. No atual sistema que desenvolvo, tenho a seguinte tabela em mente:
| Custo Performance | |||
| Freqüência de Uso da Função | Baixo | Médio | Alto |
| Baixo | F | F | F |
| Médio | F | F | F |
| Alto | F | P/F | P |
F = Flexibilidade
P = Performance
Como cada caso é um caso, o ajuste desses valores depende de algumas variáveis: tipo do sistema, disponibilidade de recursos computacionais, número de usuários, etc.
No meu caso, como mostra a tabela acima, prefiro escolher por flexibilidade. Mas conforme o ambiente muda, basta alterar o sistema, já que é mais fácil tirar flexibilidade e focar em performance do que o caminho contrário.
Agora, se você não sabe a freqüência de uso, então esqueça performance!
Will my app scale when millions of people start using it?
Ya know
what? Wait until that actually happens. If you've got a huge number of people overloading your system then huzzah! That's one swell problem to have. The truth is the overwhelming majority of web apps are never going to reach that stage.
And even if you do start to get overloaded it's usually not an allor-nothing issue. You'll have time to adjust and respond to the problem. Plus, you'll have more real-world data and benchmarks after you launch which you can use to figure out the areas that need to be addressed.
A sensibilidade da escolha, hora pendendo por flexibilidade, hora por performance, é uma das chaves para conseguir um bom sistema.
ps: os últimos textos estão perdendo a acides por motivos de preguiça. Prometo o tom de crítica volta assim que a lentidão mental passar.
0 comentários:
Postar um comentário