Venho por meio deste, fazer uma denuncia! Diante da situação do sistema encontrado na empresa “X”, torna-se necessária uma analise de criticidade do projeto de software adotado atualmente. O mesmo expõe vários sintomas que nos fazem acreditar que o projeto esta apodrecendo e embora ele ainda funcione corretamente por um tempo, vem se tornando uma bomba relógio.
O software citado acima possui as seguintes características:
Rigidez
Um projeto errôneo de estrutura da informação acarreta uma mudança em um módulo que provoca outras mudanças no formato cascata em módulos subseqüentes. No cenário atual, um erro “infantil” causa grande transtorno quando se torna necessária uma mudança em pequenos blocos de conteúdo no layout do sistema em questão. Conteúdos estáticos que poderiam ser resolvidos com uma simples “masterpage” e estilos CSS, alterados módulos a módulos.
Fragilidade
As falhas seguem e notamos que a falta de padrão de projeto é visível. Uma simples mudança de usuário, senha ou mesmo nome de base de dados implica em seguidos erros de conexão dentro do projeto, visto que para há varias formas a mesma e não há um arquivo de configuração único para armazenar tais detalhes.
Imobilidade
A falta de padrão peca em mais alguns detalhes do projeto. Vários desenvolvedores participaram de se desenvolvimento, cada um com o que eles próprios chamavam de POO e naturalmente desenvolveram tinham milhares de dependências ou mesmo, eram tão específicos que os impediam de ser reutilizados em outro projeto semelhante.
Viscosidade
Alterações em determinados módulos se tornam tão custosas que são evitadas ou até mesmo, se arruma um “jeitinho” para evitar uma refatoração de código que levaria um tempo considerável diante da situação atual, mesmo sendo uma opção válida para a situação.
Requisitos Variáveis
A falha na comunicação durante o levantamento de requisitos torna ainda mais difícil lidar com os requisitos variáveis do projeto. As idas e vindas de uma regra ou outra de negócio e a guerra de “egos” entre os stakeholders para atender ou não um requisito violam o projeto original, e tudo termina por alterações grosseiras de código para criar uma funcionalidade e atender uma especificidade de uma determinada área.
Gerenciamento de Dependências
Podemos notar que o projeto em questão convive diariamente com os quatro cenários acima, nos fazendo repensar a continuidade de seu desenvolvimento. A falta de planejamento e padrões durante o seu desenvolvimento tornou alguns dos mais importantes módulos desnecessariamente dependentes de outros menores.
OCP
O principio base desta técnica garante a criação de “módulos” que são extensíveis, sem serem alterados. Com um pouco de planejamento podemos adicionar funcionalidades ao código, sem alterá-lo, apenas adicionando novo código.
LCP
Garante que um objeto de uma classe base deve continuar a funcionar corretamente se o mesmo é instanciado através de uma classe derivada. Outro principio que deveria ser observado durante o desenvolvimento do projeto.
Túlio César Gaio
Nenhum comentário:
Postar um comentário