« Desenvolvendo com JavaScript | Home | Como chegar ao sim »
O mesmo remedio para todas as doenças!
de Valter Lobo | Quinta, 9 de Outubro de 2008
Em todas as circunstâncias no desenvolvimento de um problema ( software), utilizar o framework padrão ou sempre a mesma solução( exemplo: Session Bean + DAO + Struts) designado pela corporação ou grupos de que se dizem arquitetos, independente do sistema e da condição que o software vai ser desenvolvido, como prazo, tecnologias e plataformas envolvidas, experiência da equipe e características do sistema, costuma causar prejuízos a empresa quando em produção ou no prazo de desenvolvimento.
Cada técnica deve ser aplicada a um determinado problema, aplicar uma técnica que não ajude ou atrapalhe, não soluciona o problema, adiciona mais problemas, acho que dai vem aquela velha frase:
“Informática e a solução para os problemas que você ainda não conhece”
Seria o mesmo que receitar aspirina para qualquer doença, porque para dor de cabeça, ela funciona muito bem, quanto a uma dor de barriga!
Tudo depende das condições de desenvolvimento e do tipo do sistema, uma arquitetura para os sistemas de uma empresa de telecom e bem diferente de uma empresa de varejo.Cada uma tem a sua característica inerente aos seus negócios, posso falar por experiência, que muitos sistemas na área de telecom ficam mais difíceis quando no processo de desenvolvimento for utilizado apenas a abordagem relacional, o que não e o caso de empresas de varejo que armazena dados e processa para geração de relatórios e apenas exibe a informação para o usuário do sistema. Sistemas de telecom envolve diversas plataformas e tipos de tecnologias e protocolos, enquanto que no ramo de varejo e mais servidores de banco de dados.
Utilizar artefatos desnecessários e modelar todos os sistemas seguindo um padrão determinado, como diagramas de seqüências para todo caso, causa sobrecarga de documentos desnecessários e desperdício de horas de trabalho e um acumulo de papel. Proteja a natureza!. Selecione o que realmente seja necessário para desenvolver e modelar no sistema para determinar a maior parte da energia no objetivo principal do sistema.
Frameworks proprietarios e outro caso que costuma costuma adicionar mais custos ao projeto ou para empresa, são mais horas gastas no desenvolvimento, e não consegue diluir este custo em diversos projetos como alguns argumentam, para saber se vale realmente a pena desenvolver um framework, coloque argumentos financeiros na sua proposta, prove com dados historicos da empresa, prove em numeros se vale a pena. E coloque todos este requisitos para que a solução seja otima para o negocio, e não somente em termos tecnologicos.
O arquiteto deve agir como medico, receitando uma arquitetura(solução) de acordo com o cliente e tipo de sistema.
Aviso! Compre bastante aspira para os programadores, quando eles tiverem que dar manutenção no sistema com o framework e soluções padrão.
Categorias: arquitetura | | Enviar por e-mail | Hits para esta publicação: 115