Desenvolvimento

2 ago, 2012

Reaproveitamento de código: conheça a visão da empresa e a do desenvolvedor

Publicidade

Caro leitor, eu gostaria de falar hoje um pouco da minha experiência sobre reaproveitamento de código. Se você desenvolve software, sabe que o mesmo código feito para um cliente pode ser reaproveitado para outro. Quero dizer, o mesmo projeto, mas com configurações diferentes, como outro tipo de cliente, outro banco de dados, outros tipos de informações e tudo mais.

Existem dois pensamentos: um referente ao desenvolvedor e outro referente à empresa que está vendendo o software (como de caixinha).

Visão de desenvolvedor

Falando um pouco sobre a visão de desenvolvedor, o programador pode criar API juntando todas as funcionalidades reaproveitadas em vários projetos. Como eu fiz com a API que acessa dado: criei uma API que pode acessar dados no banco de dados de forma mais simples e fácil.

Essa API pode acessar o Oracle, SyBase, MySQL, SQL Server, Access, SDF (móvel) e Fireboard. Se o meu sistema hoje, que está funcionando em SQL Server, for migrado para o banco de dados Oracle, basta informar na API a mudança e migrar o banco. O único trabalho para o desenvolvedor seria mudar a chave no arquivo de configuração, enquanto o DBA (Gestor do Banco de Dados) teria que migrar todo o banco, procedures, tabelas, triggers, views e mais do próprio banco.

Essa API desenvolvida pode ser usada em qualquer tipo de projeto. Isso porque criei um projeto do tipo CLASS LIBRARY, com classes separadas e pastas. Ao compilar esse tipo de projeto, todo o código vira DLL, que pode ser importada nos outros projetos e ficará disponível para uso – basta referenciar o nome da classe que deseja usar e chamar o(s) método(s) disponível(is). Lógico que, os métodos que irão aparecer para quem está usando são os públicos. Os internos e privados não aparecem. O método de uso interno da própria CLASS LIBRARY não precisa ser exposto. O melhor é deixar interno ou privado.

A fim de ficar melhor ainda, criei outro projeto CLASS LIBRARY, responsável por criptografar e decriptografar dados usando chave de 128 bits. Acabei incluindo esse projeto dentro do primeiro. Isso faz com que a minha string de conexão fique sempre criptografada.

Acontece que, se um hacker conseguir invadir o seu site pelo FTP, ele vai ter acesso ao arquivo de configuração onde fica a string de conexão aberta; isto é, com usuário, senha, nome do banco e servidor. Com esses dados o hacker pode invadir o seu banco, mudar scripts e infectar computadores que acessam o seu site… Isto é uma tremenda falta de segurança de dados que, querendo ou não, está aberta no arquivo de configuração.

A API de criptografia é usada para criptografar a string de conexão e no momento de abri-la com o banco de dados, usando outra API de dados, a string é decriptografada em memória. O arquivo de configuração não será alterado.

Essa é uma preocupação que o programador deve ter. O que vale muito dinheiro hoje é informação. Cansamos de ver por ai grandes empresas comprando outras só porque tem muitos usuários e informações confidenciais. Então, procure sempre proteger as informações.

A minha dica é: depois de analisar o projeto e o sistema antes de ser criado, procure ver o que pode ser feito na API para ser reaproveitado em outros projetos.

Visão de empresa

O reaproveitamento de código para a empresa consiste em outro tipo de visão. Muitos analistas e gerentes pensam que seria melhor copiar todo projeto já escrito para um cliente e colocar para outro.

Ninguém pensa em fazer o projeto de forma genérica, isto é, que comporta qualquer tipo de cliente e qualquer tipo de informação. Quando for fazer um projeto, o que é melhor fazer um projeto genérico ou específico?

Projeto do tipo genérico na maioria dos casos, demora mais para ser desenvolvido do que um projeto específico. Isso porque o projeto do tipo genérico precisa atender todas as possibilidades analisadas, enquanto o projeto específico só atende a um determinado cliente ou regra.

De qualquer jeito, nenhum sistema vai atender todas as regras possíveis. Um projeto grande pode demorar pelo menos 50% a mais desenvolvendo do modo genérico. Algumas vezes é melhor desenvolver o software específico e depois alterá-lo para fazer o genérico. Dependendo do prazo para desenvolver o projeto, você poderá decidir se é melhor desenvolver o específico ou genérico. Prazo maior, genérico; prazo menor, específico.

O que vai acontecer depois de pronto para a empresa é: não precisar mais desenvolver o mesmo software, basta reaproveitar o projeto para vários clientes. Assim a empresa ganha dinheiro vendendo o mesmo produto fabricado uma vez.

Depois do projeto específico pronto e em produção, basta usar o mesmo para desenvolver o genérico se quiser. Como se fosse um produto de “caixinha”.

A vantagem do produto específico para um cliente é que o produto pode ser customizado, enquanto o produto de caixinha sempre vai ser aquele e pronto. De acordo com o mercado hoje, para a empresa ter lucro, ela tem que estar apta para adaptar o seu produto para o cliente, da melhor maneira possível. Levantando em conta o custo, prazo e facilidade.

Querendo ou não, o reaproveitamento de código veio para facilitar, ajudar empresas e desenvolvedores de software. Procure sempre reaproveitar código e sistemas.

Espero que tenham gostado do artigo e qualquer dúvida é só falar!