Se arquitetura do software não evoluir, eles virão!

O software está no ar, tem clientes… muitos clientes, e não existe espaço para nada mais nada que manter o software no ar enquanto os novos requisitos de negócio vão acontecendo no código.Quais as consequências dessa visão?

Code base que só cresce
Se o número de linhas de código só aumenta e se o crescimento é da taxa de 100 linhas por dia(o que é pouco numa grande empresa, concorda?), em um ano a empresa terá que lidar com um software de 36  mil linhas. Se isso já não fosse problema suficiente ainda podemos somar outras características.

Software se torna cada vez mais complexo
Numero de linhas não é exatamente uma medida de aumento de complexidade. A medida final da complexidade é a dificuldade de ler e entender o software sem o auxílio de muletas e esse cenário se torna mais distante quando o design não acompanha o crescimento do software(reflexo de novos requisitos de negócio), mais ou menos como se uma cigarra que cresce não trocasse de exoesqueleto e ele fosse se tornando contenção ao invés de suporte de vida.

Códigos que tratam o efeito é ignoram a causa
O codebase tem cada vez mais linhas, ele é cada vez mais complexo e a empresa, como medida de seu sucesso, realiza cada vez mais e mais rápido. Não há tempo para perder e isso aponta para situações onde os bugs “são corrigidos” nas camadas acima de onde eles realmente existem. Problemas com um tipo errado de informação se torna um “if no controller” e uma regra de negócio que entrega o valor com um medida fixa de distorção/erro se torna “adicionar 10% direto ao resultado da regra e ta pronto”.

Tempo de desenvolvimento maior
Adicionar um recurso simples é procurar a ponta em um novelo de lã depois do gato brincar com ele. Nada mais é simples como parece quando se fala. Surgem as discussões entre os times de negócio e o técnico. A comunicação não funciona por que o software é surreal, mas ninguém aceita o fato de que é necessário um refactoring do software… do seu design, por que isso “não adiciona valor ao negócio”Como não?Como não?Como não?Como não?Como não?Como não?

Arquitetura rígida
Até que em dado momento nada mais é aceitável. O tempo que demora para adicionar algo simples não é aceitável. Ficar sem a funcionalidade no tempo necessário não é aceitável. Um refactoring não é aceitável. Dead lock! Dead lock! Dead lock! Dead lock!

Deixar os débitos técnicos se acumularem é o caminho para a multiplicação dos gremilins. Ter isso em mente é importante tanto para o cara de negócio quanto para o desenvolvedor.

Como desenvolvedor você deve export que estão sendo criados débitos técnicos e o impacto disso no futuro da aplicação. Deve deixar claro  argumentar que isso não é importante é como dizer que o futuro da empresa não é importante.

Se você esquecer disso:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s