[SP-pm] descubrir o tipo da variavel

Solli Honorio shonorio at gmail.com
Thu Jul 15 13:27:27 PDT 2010


Lucas,

Conselho (pode ler também como consultoria) custa caro, mas vou lhe dar a
oportunidade de tê-lo a um preço acessível (a um preço de uma cerveja no
próximo ES).

Isto que você está fazendo, muito de nós já fizemos e depois jogamos fora.
Fizemos quando o nosso tempo era abundante e o salário ridículo
(infelizmente é assim que funciona, o tempo ocioso é proporcionalmente
inverso ao teu rendimento). A tua solução tem vários problemas, vou tentar
enumerar alguns :

1o. tem um problema de estética. A tua solução é FEIA !!! Feio e Bonito em
engenharia de software não é uma questão de gosto, e sim de
facilidade/dificuldade na manutenção, escala e estabilidade, segurança, etc.
Quanto alguém recebe a missão de alterar/manter um código e diz 'Nossa, que
coisa horrível ! Como vou manter esta coisa ?', ou quando um script kid diz
'Hackear aquele site foi fácil, o código é ridículo !!!!'. Isto significa
que a estética de quem implementou a solução não é boa, ou seja,
tecnicamente falando ele não é um bom profissional. Você  não acredita
nisto, acha mesmo mesmo que a tua solução está segura, então dê uma olhada
no OWASP[1] e veja se você toma os cuidados mínimos;

2o. desperdício de recursos. Quando é colocado tempo e dinheiro numa solução
FEIA, isto é D.E.S.P.E.R.D.Í.C.I.O. Quando é colocado tempo e dinheiro numa
solução BONITA, isto é I.N.V.E.S.T.I.M.E.N.T.O. Invista o teu tempo e
dinheiro em algo bonito, escalável e estável, padronizado e com segurança.
Isto tornará a tua vida mais simples, eficiente e produtiva;

3o. desserviço para o Perl. Esta solução é feia, desperdiça os recursos e
portanto não contribui com a imagem de eficaz e eficiente que lutamos tanto
para associar ao Perl. Perl é bonito e eficiente com os recursos desde que
sejá utilizado as melhores práticas;

4o. foco errado. De todos os problemas, acho que este é o pior. Você está
focando no SQL e não no negócio. Não sei qual a tua experiência de
desenvolvimento, mas a discussão mais velha no desenvolvimento de
aplicativos de negócios é 'Onde ficará as regras de negócio'. Nestes anos
todos estas regras já estiveram em vários lugares, mas recentemente estamos
chegando a conclusão que na maioria das vezes o melhor lugar é no model
(utilizando o modelo MVC), pois em último caso a maioria do negócio está
resumido na qualidade dos dados (e por conseqüência processos de
verificação). Um ORM como o DBIx::Class permite você mapear a persistência
dos dados de maneira segura e fácil. A maneira como você está desperdiçando
os teus recursos (e do teu investidor) não permite colocar a parte de
negócios próximo aos dados, e isto terá um custo elevado no futuro próximo.


Espero que você tenha percebido que o problema não é de código, e sim de
tecnologia. Antes de defender a tua maneira de fazer, reflita sobre cada
ponto abordado aqui e tente defende-los de maneiras lógica e não passional.
Se você conseguir isto, eu lhe pago a cerveja.

Abraços,

Solli M. Honório

[1]http://www.owasp.org/index.php/Main_Page

2010/7/14 Lucas Moraes <mineiro em live.be>

>  Oi Blabos de Blebe, Obrigado pela ajuda.
> Oi Luis Motta Campos, voce esta certo, mais nessa tentantiva de criar meus
> proprios modulos para manipular banco de dados, eu acabei aprendendo muita
> coisa, eu não vou para de fazer esses modulos sem sentido para os
> expirientes da linguagem, porque alem de eu estar aprendendo cada vez mais e
> é de ideias bobas que sai grandes projetos. Eu quiz fazer, fiz, funcionou e
> pronto. Mais eu vou usar o DBI ou DBIx::Class.
>
>
> Um abraço.
>
> Deus é o limite
>
>
> ------------------------------
> Al je email accounts in 1 inbox. Het kan in Hotmail.
> <http://www.microsoft.com/netherlands/windowslive/Views/productdetail.aspx?product=Hotmail>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>



-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20100715/a1a76490/attachment.html>


More information about the SaoPaulo-pm mailing list