O software principal, esse sacana
Nada mais importante para uma empresa digital que seu software principal. "O software que executa aquilo pelo que o cliente paga é prioridade, acima do backoffice, acima dos sistemas de deploy, do monitoramento de hardware e tudo o mais". Essa é mais uma daquelas afirmações feitas por que "todo mundo sabe que…". A falácia do conhecimento estabelecido.
O software principal se beneficia da sua importância na realização de negócios para, de maneira muitas vezes agressiva colocar os outros no lugar. Se softwares fossem pessoas, você cruzaria com o script shell e o sistema de migration conversando baixinho no café e quando você chegasse na máquina para pegar seu expresso, eles trocariam de assunto.
O software principal, meu caro, as vezes age como um sacana.
Não é por que ele é mal, é só por que ele não reconhece que o todo é feito de partes, alias, isso é uma culpa compartilhada entre todos os pais e mães que ele teve. Criaram um filho que acreditava ser independente, mas você ai sabe o quão utópico é algo em desenvolvimento de software ser independente. O quanto improdutivo é reescrever a roda para não ter "aquela dependência".
A pergunta que não quer calar é: Por que, tanto trabalho realizado no software principal da empresa não impacta no ecossistema de softwares como um todo?
Não foi uma, mas várias, as vezes em que encontrei softwares com mania de grandeza. Um controller com lógica de negócios só para ele. Uma implementação de comunicação transacional cheia de regras que impediam o reaproveitamento. Tabelas de um banco de dados com campos de nomes distantes da realidade de negócio, document sendo chamado de Oompa-Loompas.
Talvez, a grande sacada seja perceber que existe mais de uma camada e que camada define o objetivo de uma classe de código. Quando o programador percebe isso, as coisas deixam de ser monolíticas e vão sozinhas na direção da componentização.
De repente o software não é mais o sacana, ele precisa conversar com outros dentro do ecossistema de software em que vive.
De repente, cada novo recurso se torna um novo recurso para todos os softwares.
De repente, as histórias andam mais rápido e de uma maneira mais segura.
De repente, você se vê praticando uma metodologia ágil não porque um profissional trouxe ela para dentro da empresa, mas por que ela emergiu das profundezas das más experiências, que foram sendo aprimoradas por efeito de uma coisa que você não sabia nomear, mas que era PDCA, um treco lá de 1950 que eu acho útil bagarai.
E isso me lembra que reconhecer isso tudo é a parte mais fácil. Como esvaziar a força monolítica daquele software sacana que é difícil. É como trocar uma ideia com Hal-9000 ele sabe tudo, mas tem um defeito. Você pode extrair os bancos de memória dele e levar para outro lugar.
A ferramenta para realizar essa façanha é o refactoring e tem esse ótimo livro aqui para você começar.
Enquanto você estiver utilizando refactoring para repensar o software principal em componentes especializados, distribuídos em camadas com objetivos como negócios, infraestrutura e apresentação, lembre do Hal-9000 argumentando com o Dave, e não confie nele. Esse software sacana vai querer te convencer que ele é bonzinho. O resto, você já sabe.
