Meu primeiro contato profissional com desenvolvimento server-side foi em 2004, quando comecei a trabalhar como estagiário em uma agência de design, onde aprendi muito sobre clientes, gráficas, prazos e internet.
Eu já havia “programado” em PHP, na verdade tudo o que eu tinha feito foi um CMS bem meia boca para um blog, com um sistema de comentários. Nunca gostei do blogger e na época não conhecia o WordPress (ele existia em 2002?).
E eu aprendi errado. Aprendi a programar com um designer, não com um desenvolvedor “de verdade”. Faltava conhecimento técnico para quem me ensinou e eu mal tinha noção da vida, quem dirá de se preocupar com fazer um script correto. Funcionou? Beleza, deixa. Essa é a ética POG.
Hey, antes de ler saiba que…
Esse texto é FOR DUMMIES. Ou um bom exemplo de piada para desenvolvedores mais experientes. É um pouco da minha experiência desde que comecei a programar. Apresento aqui um caso de script BIZARRO, e comento sobre os problemas dele e suas gambiarra.
Se você é ninja pode achar um desperdício do seu precioso tempo continuar a leitura, então recomendo que você vá para a Home e procure algo do seu nível.
Ou continue a leitura e se mije de rir.
Boas soluções lógicas porém debilidade técnica, eis é a fórmula da gambiarra.
Ontem, quando comecei a desenvolver o novo blog do And After (antecipo que o novo blog será sobre Arquitetura de Informação, com uma galerinha que manja muito! 😀 ) fui dar uma olhada em uns script antigos, desenvolvidos na época do meu estágio, e isso me levou a escrever este artigo.
Ah, e antes que me acusem: eu defendo o estágio, e aprendi muito quando o fiz.
Leia outros artigos sobre estágio:
Estágio é só exploração?
Na vida de um estagiário… (vídeo)
Encontrei uma SUPER GAMBIARRA em um script de paginação (ASP) que era utilizado na empresa que eu trabalhava. Vou repetir: SUPER GAMBIARRA. POG de mestre em POG.
Isso é uma gambiarra.
Vamos lá, como NÃO fazer um script de paginação:
A primeira coisa que precisamos para fazer uma paginação é saber o total de dados e quantos dados vamos exibir em cada página, correto? E já neste início está a gambiarra que eu quero apresentar, para quem está começando jamais utilizar.
Não faça isso também.
Primeiro, cria-se uma consulta no banco para pegar todos os dados, aí está o primeiro problema. Uma consulta extensa e inútil.
set rs = conntemp.execute("SELECT * FROM imoveis WHERE aprovado = 1 ORDER BY data desc")
Agora vamos ver qual o total dos resultados, par saber quantas páginas iremos criar, veja só o que não fazer.
max= 10
total = 0
do while not rs.eof
total = total + 1
rs.movenext
loop
Na época mesmo sem entender NADA eu pensei: tem que ter um comando para contar as linhas de uma consulta. E óbvio, isso existe.
Bom, vou pular a parte normal do código e partir para a próxima gambiarra. Vou chamar essa consulta de todos os dados de super consulta. Nunca use uma super consulta. É desnecessário. Se estava na página 1, o script era o seguinte para exibir os dados:
For x = 1 to max
Response.write rs(“dados”)
rs.movenext
next
Onde max é a variável que define o número de itens exibido por página. Achou ridículo? Calma, tem mais.
Se o usuário vai para a página 3, já imaginou como é feito? Isso mesmo, a consulta com todos os resultados continua e calcula se quantos movenext serão necessários para chegar na linha desejada. Veja como fica esta obra de arte POG:
for z = 1 to pagina
for dado = 1 to max
if not rs.eof then
rs.movenext
end if
next
next
O que esta gambiarra faz? Se você está na página 3, o script por três vezes repete o comando movenext por 10 vezes (a variável max). Depois disso, repete-se o loop do max, para exibir os itens.
Se você não entendeu porque isso é prejudicial (você é noob), vamos lá, vou falar um pouco de otimização.
Explicando os problemas
Problema #1 – A super consulta
Não precisa ser nenhum gênio para pelo menos imaginar que diversas consultas no banco de dados prejudicam o desempenho de um script. A super consulta pode ter como resultado 9 linhas como 999.234.765 linhas. E você vai usar apenas 10 destas linhas.
Outra coisa muito comum (para quem desenvolve aplicações pequenas e não tem conhecimento técnico) é utilizar o SELECT * FROM. Exemplo, você faz a pesquisa que resulta em 9 colunas por linha. E você precisa apenas de duas, nome e ID.
Solução #1
Retorne os resultados com apenas com os dados que precisa, utilize o comando LIMIT sempre!
Se você vai utilizar somente os 10 primeiros resultados e quer apenas o a coluna ID e o NOME utilize a seguinte consulta:
SELECT id,nome FROM tabela LIMIT 10
Problema #2 – A contagem das linhas
Ficar percorrendo todas as linhas de uma consulta e criar um contato estilo x = x+1 definitivamente não é uma boa opção. Na verdade não deveria nem ser considerado uma opção.
Solução #2
Como contar as linhas sem utilizer a SUPER CONSULTA? Simples, pequeno gafanhoto.
Utilize o comando COUNT, veja o exemplo abaixo.
SELECT count(ID) as total FROM tabela
Fazendo isso você utiliza o total como umas coluna da tabela, por exemplo:
total = rs(“total”)
Problema #3 – Chegar na linha desejada
Tudo bem, você conseguiu fazer a consulta e pegar o valor total, se a página for a 1 você utiliza o LIMIT, mas quando a página for maior que 1 não tem jeito, você vai utilizar a SUPER CONSULTA e contar os movenext, certo?
NOT!
Nada de SUPER CONSULTA, jamais nesta vida.
Solução #3
Para chegar na linha desejada utilizaremos novamente o comando LIMIT, suponto que você está na página 3 e o máximo de itens exibidos por página é 10. Você precisa pegar da linha 21 até a 30. Sua consulta:
SELECT id,nome FROM tabela LIMIT 21,10
Simples assim, o LIMIT pode não somente limitar o número de resultados, utilizando o formato acima ele seleciona exatamente quais linhas serão resultados da consulta.
Conclusão
Jamais confiem em um designer programando server-side.
Brincadeira! 🙂
Sou formado em design e está fazendo 5 anos que programo em ASP (clássico). Sim, ASP clássico, eu sei, estou OLD e já passou da hora de me atualizar.
Mas meus códigos de hoje são limpos, são orientados não por uma pessoa, mas por fóruns, blogs e muitas Googleadas. Este ano comecei a estudar .NET (estou começando, na verdade 🙂), li artigos e um livro de SCRUM, testei scrum solo. Acompanho blogs de desenvolvimento, ano passado comecei a estudar mais a fundo javascript (e jQuery). Ah, fiz um pequeno framework para desenvolver as intranets de meus clientes, está funcionando bem, de forma modular, permitindo diferentes configurações. Além do aprendizado (javascript, ASP, SQL) depois um BOM tempo com o aprendizado comecei a utilizá-la para meus clientes, o retorno financeiro começou no final do ano passado.
O que eu quero dizer é: estude. Estude muito.
Duvidem do código que estão vendo. Duvidem da primeira solução que encontrar.
Se tiverem oportunidade participem de um projeto de porte médio ou grande, ou façam um teste de carga em seus scripts. Gambiarra só “funciona bem” em aplicações pequenas, pois guando o bicho pega vai tudo pro pau.
Estude.
Leia metodologias, baixe scripts, teste soluções novas para problemas antigos.
Aprenda a economizar consultas ao banco de dados.
Aprenda a utilizar cache. Invente um modelo de cache. Mas não gambiarras.
Estudem.
E claro, assinem o FEED do O Desenvolvedor, pois o Chris Benseler manda muito bem. E ele não é um designer metido a programador como eu. 🙂
Atenção 2
Jamais utilize os códigos que estão em VERMELHO neste artigo. Se você fizer isso provavelmente você perderá o emprego. A honra. E sua conta naquele fórum bacana de desenvolvimento que você participa.
