Necessidade e Comodidade

É incrivel, como nos acostumamos com uma coisa e deixamos de enxergar as outras. Eu, nos meus projetos, sempre me pergunto: “Dessa maneira, o usuário ficará satisfeito?”, “Não estou desperdiçando recursos do servidor?” e até mesmo a famosa “Será que estou sendo muito preguiçoso publicando uma solução assim?”.

Pois bem, vou citar dois exemplos:

1 – Você precisa de uma página e sem pestanejar, cria um ASP.NET WebForm, sendo que uma página HTML com um pouco de HTML resolve seu problema.

2 – Você somente se preocupa em fazer funcionar e não em ter uma solução que não irá se comportar bem quando for altamente requisitada.

No primeiro caso, o que ocorre é que nós, desenvolvedores nos esquecemos de analisar pura e friamente qual a necessidade da página que estamos criando. Recentemente, eu precisei de uma página que iria aceitar alguns parâmetros e então solicitar um relatório ao Crystal Entreprise. A minha primeira escolha foi criar um ASP.NET WebForm e colocar toda a lógica que eu precisava lá e pronto. Mas, depois, pensando bem, eu percebí que não precisava de uma Ferrari para ir até a esquina, somente precisava de uma bicicleta, patinete ou simplesmente um chinelo…

Pois então, criei a danada da página como HTML, pura e simplesmente e com toda a lógica de tratamento dos campos sendo feito em javascript.

Mas o que eu ganhei com isso? Simples, nada! Mas o usuário e o meu servidor web agradeceram, já que para uma página HTML ser servida, ela consome menos recursos do que qualquer página ASP, ASP.NET ou seja lá qual for a linguagem de desenvolvimento utilizada.

No segundo caso, que eu classifico como tão grave quanto o primeiro, o principal problema é que você pode se deparar com uma grande ou total reescrita do aplicativo, apenas porquê não se preocupou com a performance durante a fase de desenvolvimento. É muito mais fácil e mais barato para o projeto, e consequentemente para o desenvolvedor, ajustar a aplicação para uma melhor performance e uma segurança mais elaborada enquanto está codificando a solução do que quando a devida solução está pronta e precisa ser reescrita. Não importa se é uma pequena, média, grande ou total reescrita de código, o desenvolvedor gosta de coisa nova e dar manutenção em sistema é geralmente chato.

Por isso, minha dica, e olha que já sofrí um bocado com problemas de performance é:

1 – Não utilize, nas suas instruções T-SQL, “Select * From [Tabela de Tal]” – Isso compromete a sua velocidade e a manutenção desse aplicativo, já pensou se algum desavisado vai na sua tabela e cria mais 50 campos cada um ocupando 4000 posições alfanuméricas? O que o seu comando “Select *“ vai começar a trazer quando isso acontecer?

2 – Após criar a sua Stored Procedure ou comando T-SQL, verifique o plano de execução da mesma, faça o Tunning antes da aplicação entrar em produção, verifique a quantidade de leituras e escritas que são exibidas no plano de execução para ter certeza de que está utilizando a melhor solução possível para a pesquisa.

3 – Se coloque no lugar do usuário, muitas vezes, os testes são viciados, em um cadastro de Notas Fiscais por exemplo, testamos sempre com uma, duas, talvez com cinco. Mas e se acontecer uma caso em que o usuário precise cadastrar 50, 100, 1000 notas? A sua solução ainda será razoável? Use sempre essa dica do 50, 100, 1000 para testar se a sua solução atende a todos os seus usuários, cenários atuais e cenários que possam aparecer.

Por isso pessoal, nada como se colocar na “pele” do usuário, afinal, quantas vezes não reclamamos do site do banco em que somos clientes, mas não olhamos para a nossa aplicação e verificamos que nela existem os mesmos defeitos ou até mesmo, defeitos piores.

Bem, era só isso… um abraços e até mais…

Chilá!@!