Um bom sistema depende, também, de um banco de dados bem estruturado


Nesses meus anos de trabalho com desenvolvimento de sistemas, tenho visto que cada vez menos as empresas se preocupam em estruturar um banco de dados corretamente.

Hoje em dia, boa parte dos desenvolvedores querem trabalhar com SharePoint que é a programação do momento. Porém, muitos desses desenvolvedores não sabem dizer se um sistema terá mais qualidade se desenvolvido em uma linguagem ou em outra.
Nem sempre, SharePoint é a melhor solução para o desenvolvimento de um sistema.

Outro ponto é que, quando se monta um site, ou portal, ou seja lá o que for no SharePoint, (não generalizando, mas em boa parte deles) o “desenvolvedor” entra em uma parte administrativa e fica clicando nos links para criar um novo site, criar uma nova página, adicionar uma webpart, etc, etc, etc. Nisso, ele não faz a mínima ideia de como isso está entrando no banco de dados (e muitas vezes nem tem vontade de saber) e não sabe nem como é estruturado um banco de dados para SharePoint.

Vamos deixar uma coisa clara: Não sou contra o SharePoint. Muito pelo contrário. Defendo muitas utilizações dessa ferramenta. Um exemplo básico é um portal de colaboração. Se fosse montar um portal de colaboração no .NET por exemplo, pode ter certeza que você teria muito trabalho, mas muito mesmo. Já no SharePoint, o negócio fica bem simples, ainda mais que existem diversos templates que precisariam de pouquíssimas customizações para ficar da maneira como você gostaria. Alie tudo isso a um bom Designer e você poderá ter portais ou até sites de internet com uma qualidade excepcional.

Mas o que estou discutindo aqui é o seguinte: Desenvolvedores, que trabalharam só com desenvolvimento nativo de SharePoint e depois dizem que tem experiência em bancos de dados. Isso é absurdo!

Esses dias, me deparei com uma base de dados (desenvolvido por um programador .NET se a mínima experiência em Banco de Dados e depois ajustada por um desenvolvedor SharePoint que julga saber Banco de Dados) que tinha a mesma informação em 3 tabelas diferentes, não havia relacionamentos e ainda existiam tabelas que não estavam sendo utilizadas para nada. Esse banco serviria para uma parte de um portal desenvolvido em SharePoint e essa parte é totalmente desenvolvida com webparts 100% customizadas em .NET para atender a necessidade do projeto. Conclusão, informações desencontradas, perda de informações importantíssimas e performance deplorável. Aí vem o chefe e te pergunta: “O que precisamos fazer para arrumar esses problemas?”. E claro, a resposta: “Primeiro estruturar direito esse banco de dados. Estruturando corretamente, pode ter certeza que 99% do que foi desenvolvido vai para o lixo. Em outras palavras, precisamos desenvolver do zero.”. Claro que em projeto atrasado, a sugestão não foi aceita.

Bom… Vamos voltar ao foco do nosso post. Um bom sistema desenvolvido em algum ferramenta que não seja SharePoint, é 90% uma boa estrutura de banco e de sistema. Os outros 10% é a qualidade da lógica de programação do(s) seu(s) desenvolvedor(es).

Vamos colocar em ordem macro o que devemos nos atentar bastante no desenvolvimento de um projeto.

1. Modelagem do banco de dados
Se você monta um banco de dados muito bem estruturado (que não é simples, mas essencial), você previne alguns erros que os desenvolvedores podem vir a cometer, além de diminuir o tempo do seu desenvolvimento do sistema, aumentar a sua performance, a possibilidade de expansão estruturada do seu sistema, etc.
Perca um pouco mais de tempo na modelagem do seu banco para não perder muito mais tempo no final do projeto para corrigir os problemas que poderiam (e deveriam) ter sido resolvidos com algum tempo a mais olhando para o seu banco.

2. Estrutura de classes do projeto
Aqui faço uma pergunta: Pra que criar uma estrutura extremamente complexa, com diversas camadas se o seu sistema não terá integração com nenhum outro sistema e acessará apenas um banco tipo de banco de dados?
Veja bem: Se existe a possibilidade de esse seu sistema um dia acessar outro tipo de banco de dados ou ter integração com algum outro sistema, aí sim você precisa mesmo pensar em algo mais complexo, mas em boa parte dos projetos que participei, esses não eram os casos.
Se você cria uma estrutura extremamente complexa para um sistema extremamente simples, corre-se o risco de perder muito, mas muito tempo mesmo no meio do projeto em diversos casos, como por exemplo, a troca de um recurso de desenvolvimento. Até o recurso novo entender a estrutura inteira do projeto para a simplicidade do resultado que o projeto vai oferecer lá se foram dias ou até semanas de tempo do projeto.
Não estamos dizendo que não temos priorizar a qualidade, mas estou dizendo que temos que priorizar o máximo da simplicidade que o projeto permita. Isso pode aumentar sensivelmente a qualidade do seu projeto, levando em consideração que provavelmente nem todos os recursos tem a mesma experiência que você.
O que realmente tem que ser muito bem pensando em todos os projetos que se iniciam é a estrutura base de classes para poder amparar as classes mais específicas, como as classes de webforms por exemplo. Perca um pouco mais de tempo aqui também para prevenir duplicação de código, facilitar a manutenção e também melhorar o tempo de desenvolvimento do meio para o final do projeto.
Um exemplo aqui seria uma classe base que fornece os perfis do usuário logado para todas as classes de formulários, métodos comuns, globalization, localization, e por aí vai.

3. Teste, teste e teste novamente
Nessa fase, muitos gerentes de projeto erram em um ponto crucial do projeto. Nem sempre o teste é mais rápido do que o tempo de desenvolvimento. Um exemplo. Suponhamos que temos um relatório que mostrará valores diferentes, dependendo de onde o dado foi colocado e do perfil do usuário que colocou o dado em cada um dos lugares em poderia. O desenvolvedor vai pensar em tudo isso e colocar no relatório, testar alguns perfis e alguns lugares que foi colocado o dado. Não encontrando o nenhum problema, poderá passar para o tester. Na sua vez, o que o tester deverá fazer? Testar apenas alguns pontos de dados em alguns perfis? Ou ele terá que testar todos os pontos de inserção de dados em todos os perfis? Quem demora mais nessa tarefa? Desenvolvedor ou tester? Pior que esse exemplo colocado é quando há alteração no projeto. Às vezes, o desenvolvedor levar 2 horas para fazer uma alteração no projeto, mas o tester vai levar 2 dias para ver se tudo está correto. 
Por isso que eu digo que muitos gerentes de projetos erram. Costumam generalizar o tempo do tester em 20% ou 30% do tempo de desenvolvimento e em 99% das vezes, seu cronograma vai falhar aqui.
Outra coisa que muitas vezes acontece é que o tester se preocupa muito em achar problemas no funcionamento do sistema e esquecem de uma parte básica da coisa. O layout do sistema que ele está testando. Um erro de português, uma tabela desalinhada, diferenças de tamanhos de campos são tão “erros” quanto um campo preenchido incorretamente na montagem de uma página.

Alguns dos diretores da minha empresa sempre defendem que a diferença entre 99% e 100% é imensa. Demorou um pouco para eu entender o que isso queria dizer, mas no momento em que diversos clientes começaram a procurar a empresa para fazer um segundo, terceiro, quarto, ou enésimo projeto, a diferença começou a ficar clara.
Se você achar que 99% já está bom, pode ter certeza que uma hora, esses “1%” vai te fazer falta.

Bom, hoje vou ficando por aqui.

[]´s

Anúncios

2 Responses to Um bom sistema depende, também, de um banco de dados bem estruturado

  1. DARKSQUALL disse:

    EU QERIA SABER O QUAIS SISTEMA Q DEPENDEM DO USO DE UM BANCO DE DADOS?
    E UMA FICHA TECNICA DE UM BANCO DE DADOS MSQL?

    • Sistemas que precisam de bancos de dados são sistemas que precisam armazenar dados. Existem sistemas que somente fazem pontes entre duas aplicações ou sites de internet simples que não tem dados para serem armazenados, ou seja, são praticamente somente páginas estáticas e esses não precisariam de um banco de dados, porém, hoje em dia, a maior parte dos sistemas necessitam de uma conexão com um banco de dados.
      As diferenças entre versões dos bancos de dados SQL 2008 da Microsoft podem ser conferidas em http://www.microsoft.com/sqlserver/2008/en/us/editions.aspx.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: