28 de setembro de 2010, por Denis Ferrari em Design, Tecnologias

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.


Comentários:
5 Comentários postados em "Como um software nasce legado"
Osias on setembro 29th, 2010 at 16:09 #

um texto com esse título que não menciona testes?

I am dissapoint


Denis Ferrari on setembro 29th, 2010 at 16:15 #

Realmente… :( De qualquer forma já tinha falado sobre isso em posts anteriores. :)


Josué on setembro 30th, 2010 at 9:13 #

Só faltou uma coisa para mim. A definição de Feathers para código legado. Não ter testes automáticos.

No meu ponto de vista testes automáticos (de unidade e aceitação) são ferramentas valiosas demais para que possamos manter/evoluir o sistema. Por melhor que vc seja em arquitetura e por mais que tenha pensado nas coisas faladas no post, sempre algo passar despercebido. E se forem construídos com TDD e ATDD/BDD melhor ainda.

Então os testes servem como uma rede de segurança para que, mesmo que eu não tenha feito as melhores escolhas hoje, possa trabalhar depois com segurança para estruturar da melhor forma. E, SEMPRE, vão existir coisas a serem melhoradas/modificadas.


Antonio Jr on outubro 2nd, 2010 at 7:17 #

Seu Post + Comentário Osias + Comentário Josué = 10.

Parabéns moçada.


Vinicius Gama on outubro 3rd, 2010 at 16:27 #

Ótimo post Denis,

Já vivenciei isto recentemente, ser legado realmente não necessariamente tem ligação com tempo.

Parabéns,


Deixe um comentário

Nome: 
Email: 
URL: 
Comentário: