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 tarde 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.
Artigo originalmente publicado em heroisdati.
2 Comentários
Atraso na entrega de projetos também podem fazer com que o software já nasça legado. Muitas vezes quando o sistema entra em produção, os requisitos já mudaram ou os fornecedores de requisitos não são mais os mesmos e aquela solução não atende mais.
Realmente Rafael, em projetos, assim como na guerra, quanto mais rápido melhor para todos os envolvidos.