Padrões de Desenvolvimento

Paradigmas e mais paradigmas. Os padrões de desenvolvimento estão na moda. Façade, Abstract Factory, MVC, Gang of Four etc etc.

Mas onde vai parar tudo isso? Como podemos pensar em um padrão de desenvolvimento em camadas se nem sequer conseguimos decidir o padrão para os nomes dos campos das tabelas ou mesmo das variáveis?

Eu digo que o buraco é mais embaixo. Um pouco de história deve ajudar.

Esse modelo de desenvolvimento vem do Java. Nada disso é novo para os programadores e arquitetos especializados em Java.

Os programadores Microsoft estão experimentando isso pela primeira vez. Natural virar moda, afinal de contas finalmente essas disciplinas saíram do baú, ou seja, saíram daquelas panelinhas de profissionais que apenas eles conseguem devorar tanta informação e digitar tanto código em tão pouco tempo.

Resumidamente, essas tecnologias saíram das faculdades de gênios e intelectuais e caíram na mão do povo! Dê ao povo o que é do povo!

Agora nós mortais temos acesso a essas novas (velhas) formas de arquitetar e programar software.

Isso na verdade aconteceu pois a Microsoft enveredou por um caminho de Orientação a Eventos como o Visual Basic enquanto o Java rumava para a Orientação ao Objeto. E diga-se de passagem o Java venceu a batalha. Mas a Microsoft deu a volta por cima e fez o que ela sabe fazer melhor: copiou tudo do Java e criou uma tecnologia fantástica chamada .Net!

A Microsoft foi além, criou o C# para dar um xeque-mate no assunto. Pronto, nem precisa dizer qual tecnologia eu prefiro e que será assunto dos meus posts nesse blog.

Passada essa etapa, voltemos ao problema dos padrões de campos de tabela e variáveis.

Resolvi tocar nesse assunto para dissertar sobre um problema que estou vivenciando. Atualmente estou fazendo o papel de programador em uma equipe de desenvolvimento. Equipe esta que conta também com mais um programador e um arquiteto.

Até aí tudo normal. O interessante da história é que o arquiteto veio do mundo Java. Não preciso falar mais nada depois de ter escrevido esses eloquentes parágrafos anteriores.

Mas nós estamos nos dando bem e não tenho nada contra o mundo Java, apenas não o conheço. Esse é o único motivo da minha aversão.

O objetivo desse post é falar sobre um assunto em especial. Nomenclatura de campos e variáveis. É um ponto onde o arquiteto e eu discordamos.

Ele criou um padrão de nomenclatura dos campos utilizando um acrônimo para o nome da tabela, seguido de um underline e depois o tipo do campo abreviado e finalmente o nome do campo.

Então se temos um campo Nome do tipo varchar na tabela Usuario, o nome do campo fica assim: USU_ChaNome.

O conceito é interessante, pois temos todas as informações do modelo no nome do campo.

Fico me perguntando porque isso seria necessário? Porque o campo Nome da tabela Usuário precisa ter conhecimento de todo o modelo?

Esse conceito pode ser interessante quando utilizando na programação espagueti, onde existe tanto código embarcado que o nome do campo precisa trazer junto uma série de informações adicionais para lembrarmos o que estávamos fazendo. Para que não precisemos procurar essas informações em outras camadas, pois é tanto código escrito, que demoraria muito.

No .Net isso não funciona. Os frameworks estão encapsulando todos os códigos adicionais e fica muito fácil achar as coisas nas poucas linhas de código que escrevemos.

Isso sem falar no fato de que para o progrador é muito mais fácil de pensar no modelo de cima para baixo e não de baixo para cima, como é o ponto de vista do arquiteto.

Então na hora de programar é muito mais fácil escrever Usuario.Nome do que Usuario.USU_ChaNome.

Seguindo a linha de raciocínio do programador, quando este precisa de uma informação ele primeiro precisa pensar na classe do modelo. Se ele já pensou isso, porque ele precisa pensar de novo na classe do modelo ao escrever o nome do campo? E ainda mais, lembrar o tipo do campo. Só então escrever o nome do campo. Nessa hora o programador já até esqueceu qual era o campo mesmo?

Talvez isso seja herança remanescente do modelo relacional de pensar. O banco de dados deve ser abstraído para o modelo orientado ao objeto. E essas heranças da época do código espagueti precisam morrer, assim como esses políticos brasileiros. O tempo deles acabou, agora é a era dos mais jovens.

Até a próxima!
Renato Graccula