Não somos capazes de prever o futuro, mas analisando os erros cometidos no passado, podemos determinar os efeitos colaterais que uma decisão tomada no início de um projeto terá no longo prazo.
Quando iniciamos um projeto de software, vários aspectos precisam ser resolvidos: As tecnologias envolvidas, o processo que será utilizado, como o projeto será organizado, etc. Uma decisão errada em qualquer um desses aspectos pode causar danos irreversíveis no projeto e reduzir sua vida útil consideravelmente. Muitas vezes, decisões “simples” de design/arquitetura voltam para nos assombrar quando o sistema precisa ser adaptado para uma nova situação que não havia sido pensada originalmente (Já viram essa história?).
Quando organizamos um projeto de software, o termo “Separação de responsabilidades” deve ser nosso mantra. Não criar dependências desnecessárias e usar indiretamente as tecnologias envolvidas são atitudes simples que auxiliam na manutenção do projeto e na substituição dos componentes quando necessário. Indo um pouco mais fundo no aspecto responsabilidade, cada coisa em um projeto tem o seu lugar, e esse lugar deve fazer sentido. Uma consulta SQL não pode estar na camada de apresentação, assim como regras de apresentação não podem estar no domínio, assim como regras de negócio não podem estar no banco de dados, etc. O próximo programador que trabalhar no projeto não deve ter que adivinhar onde escolhemos guardar as coisas, elas simplesmente devem fazer sentido de acordo com as camadas do projeto.
Preservar ao máximo a camada de domínio também deve ser considerada uma missão crítica, afinal de contas, o domínio é o coração do software. Quando desenvolvemos um SI para qualquer área, investimos tempo aprendo sobre o domínio. Esse investimento deve ser preservado ao máximo, mas para isso, o domínio não pode ser infectado com as tecnologias envolvidas no projeto. Vincular o domínio de um projeto a uma tecnologia é fazer com que o domínio do projeto não possa ser resolvido sem ela. Já ouviu falar de algum software que funciona em uma tecnologia muito antiga e a empresa não quer substituí-lo por que investiu um bom dinheiro naquele sistema? Agora, já pensou se esse domínio estivesse isolado e as demais camadas do software pudessem ser substituídas?
Não dominar as tecnologias escolhidas para o projeto também é um pecado grave. Nunca fazemos o melhor que pode ser feito, fazemos o melhor que o nosso conhecimento permite, e mesmo com muito conhecimento, corremos o risco de não fazer “o melhor”, imagine então quando somos iniciantes no que estamos nos propondo a utilizar. Algumas lições poderão ser aprendidas tardes demais. As tecnologias são criadas para facilitar o nosso trabalho, mas não podemos ser dependentes dela. Muitos fornecedores prometem produtividade extrema com suas ferramentas, mas na minha experiência, produtividade amarrada ao fornecedor é extremamente prejudicial no longo prazo.
Concluindo, um software pode nascer legado simplesmente por não o organizarmos de forma decente ou usarmos as tecnologias de forma errada. A fase inicial de um projeto é onde precisamos de toda a nossa atenção e de toda ajuda necessária para fazer com que o investimento feito no projeto seja duradouro.
Denis
Já vi muito esta história. Muitos sistemas nascem velhos.
Por isso Ackoff, Krick e outros dizem que formular o problema é metade da solução.
Vc percebeu bem a questão.
Para não cometer esses erros os sistemas precisam ser planejados. Nem sempre é possível, principalmente em empresas desorganizadas. A conta sempre sobra para quem está ligado ao projeto, a empresa dificilmente faz mea culpa por não darem condições aos profissionais de trabalharem dentro das normas do desenvolvimento de sistemas, as vezes fazem mea culpa na teoria mas não na prática. Para resolver essas questões só com a busca do conhecimento, profissionais com anos de experiência trabalham muitas vezes sem nenhum padrão de desenvolvimento, coisa que uma graduação poderia resolver. Por isso defendo a regulamentação da Tecnologia da Informação no Brasil.