Este post não é sobre código, mas um ponto de vista sobre criar versões de sistemas.
Uma das piores coisas que se tem é ter um projeto que logicamente é dividido em modulos, mas fisicamente é um bloco de código comportando todos estes modulos.
As requisições, os testes, as versões são sempre em modulos, mas a implementação do código é feito tudo em bloco.
Como assim em bloco?
Imagine um projeto que comece com a visão de funcionalidades simples:
"Uma pessoa realiza um atendimento, depois passa para um processo de cadastro e por fim gerar um certificado."
Processo simples... Um projeto WEB feito em camada no melhor estilo MVC resolve o problema, certo? Errado.
Conforme o sistema vai crescendo, são acrescentados outros modulos conforme a vontade do cliente ou foi planejado por uma equipe de analise, mas não repassado ao arquiteto ou os desenvolvedores para uma analise de como iniciar a arquitetura do projeto. Desta forma vai entrando um modulo de cada vez e aquele bloco pequeno vai crescendo até num determinado momento em que seria melhor trocar para um estilo mais em modulos, como ficou definido logicamente.
Infelizmente é tarde! Não é mais possível trocar, pois o projeto cresceu de uma determinada maneira que se parar para trocá-lo pode demorar um tempo considerável que o cliente pode não aceitar esta "perda de tempo" (o sistema está rodando, por que alterar) ou fica inviável devido a complexidade das regras que o projeto se tornou.
Aquele pequeno inicio utilizando o padrão MVC já não serve mais, precisa ser um sistema mais "plugavel", que comporte a entrada de modulos e tenha uma implementação independente. Pena que só quando chega a um ponto deste é que percebemos que deveriamos fazer este sistema "plugavel" desde o inicio, mas quem poderia prever isto? A turma inicial de analise poderia, mas geralmente esta turma fica mais voltada para a venda que para eles é tudo uma coisa só. Não existe estruturas interna, apenas telas para serem exibidas e suas regras de negócios.
Por este ponto de vista, continuar projetos que já estão com uma estrutura definida e este não se encaixa ao modelo de "plugável" precisa de muita paciência para gerar suas versões de disponibilização conforme o modelo lógico de separação em modulos. Seria interessante o quanto antes alterar o projetos para um padrão em modulos e para projetos novos já planejar a estrutura para comportar os modulos, mesmo que seja apenas um.
2 comentários:
Sofro do mesmo mal, frequentemente, mas acho q o problema é mais embaixo. A gente não percebe ou não sabe quais módulos são necessários até bem tarde no projeto.
Então, do meu ponto de vista, temos que ter uma maneira de refatorar a coisa. OU, como vc disse, criar com módulos a partir do começo.
Nesse ponto eu gosto muito de sistemas web. Você consegue reduzir eles sempre a: banco->processo->tela ou tela->processo->banco. Acho q se planejarmos essas pequenas partes para agirem mais "independentemente", fica mais fácil de plugar e desplugar coisas.
Não sei se consegui me fazer entender. Mas é isso aí ;)
Bem.., o que costumo ver em projetos grandes e para vários clientes são necessidades em comum e necessidades individuais, isso cria um problema para se controlar a versão de um único sistema parecido com o que o Dadario comentou. Uma das soluções é sempre quebrar os "branchs" no sistema de controle de versão (SVN, CVS, etc), com isso teremos várias árvores caminhando em paralelo com funcionalidades novas implementadas para cada cliente, mas sempre deixando uma árvore principal onde as alterações que podem servir para os demais são feitas "merge". Isso resolve em partes o controle de vesão, mas continua o problema dos analistas que "querem vender" ;)
Postar um comentário