Entropia é um termo da física que se refere ao nível de “desordem” em um sistema, e como desenvolvedores, sabemos bem que a organização e a qualidade são chaves para uma boa aplicação, certo?
Quem assume a autoria do nosso Blog hoje é o Alexandre, CTO aqui na nata e responsável pelo nosso time de engenharia.
Quer entender melhor o que é e como a entropia de software pode interferir no seu trabalho de desenvolvimento? Então é só continuar a leitura.
O que é entropia de software?
Entropia do software é a ideia de que o software sofre um processo de deterioração com o passar do tempo e a adição ou modificação de funcionalidades, caso não exista cuidado suficiente para manter a coerência com o design do produto e os princípios de design estabelecidos.
Efeitos da entropia do software
Alguns efeitos podem indicar uma situação de entropia alta. Não acredito que devemos atribuir uma relação de causalidade perfeita entre os efeitos e o nível de entropia, mas podemos utilizá-los como um termômetro para a tomada de decisão.
- A quantidade de tempo gasta na implementação ou modificação de funcionalidades está crescendo de forma desproporcional ao que foi feito no passado
- A quantidade e gravidade de bugs e regressões se intensifica
- A percepção da equipe técnica de que está cada vez mais difícil trabalhar com o sistema aumenta (neste ponto é importante enfatizar que o consenso da equipe é necessário para evitar que percepções pontuais individuais prevaleçam)
Outros fatores como tamanho das equipes, tamanho do sistema, complexidade funcional e não funcional do escopo, entre tantos outros, podem ser associados.
Ponto sem volta
Esta é a situação mais temida! Se a entropia for ignorada por muito tempo, temos um sintoma final onde seu projeto pode congelar. A quantidade de falhas, comportamentos inesperados e correções necessárias afoga o time de desenvolvimento inviabilizando novas iniciativas.
Você pode pensar: “ok, sem problemas! Paramos, consertamos e seguimos em frente e tudo bem.”
O problema é que nem sempre isso é possível. As falhas se acumulam tanto e se enraízam em camadas tão profundas que às vezes alcançamos um ponto sem volta.
O custo financeiro de recuperação inviabiliza a existência ou evolução do sistema em questão. E nem todas as organizações têm a prerrogativa de reescrever todo um sistema.
Por isso, olhos atentos ao crescimento da entropia!
Relação com a dívida técnica
Existe uma relação diretamente proporcional entre a dívida técnica e a entropia. Logo, podemos pensar que toda e qualquer dívida técnica é inaceitável, não é mesmo? Para mim a resposta é não!
Uma abordagem mais adequada seria tratar do gerenciamento de dívida técnica. Ela sempre vai existir em algum nível, sempre é possível olhar para trás e encontrar pontos de otimização e melhorias.
Uma boa pergunta é: “quanta dívida estamos dispostos a contrair dadas as circunstâncias atuais?”
O que a dívida técnica nos dá trocando o futuro pelo presente é:
- Flexibilidade (especialmente quando a direção da base de código está turva)
- Velocidade para atingir prazos de entregas e atender as necessidades de negócios
A imagem a seguir pode facilitar o entendimento do trade off em questão.
Essa discussão pode despertar uma certa inquietude. Alguns podem interpretar todo o argumento como um pretexto para não construir software com qualidade e, por ser grande defensor de práticas que promovem o desenvolvimento com qualidade, asseguro-lhes que não é sobre isso.
Então porque não fazer tudo perfeito de primeira e pronto?
Limitação da racionalidade
Apropriando-se do arcabouço da economia comportamental para aplicar de forma livre, a racionalidade pessoal está limitada por três dimensões:
- A informação disponível.
- A limitação cognitiva da mente individual.
- O tempo disponível para a tomada de decisão.
Dadas essas limitações seria difícil acreditar que é possível “fazer tudo perfeito e pronto”.
O conjunto de informações para a especificação/produção de software não é completo, preciso e muda com o tempo.
O conjunto de habilidades dos indivíduos que compõem uma equipe é diverso e a forma como a informação é processada e as soluções são desenhadas também.
Não temos tempo e recursos financeiros infinitos para avaliar e desenvolver uma solução.
Busque a qualidade máxima no conjunto de restrições existentes. Não busque perfeição.
A importância de se começar bem
Muitos dos problemas associados à entropia se acumulam em um comportamento de bola de neve. Quanto maior a entropia maior é a velocidade do aumento da entropia.
Por isso a importância de se começar bem.
Para os desenvolvedores de plantão que estão começando um novo projeto isso pode se traduzir em (mas não somente):
- Organização de diretórios e arquivos
- Estratégia de testes adequada para o projeto
- Utilização de padrões arquiteturais consolidados
- Escolha justificada de tecnologias, bibliotecas e ferramentas
- Code formatting / Linters
- Cultura DevOps
Quando tomar ações em relação a entropia?
Para gestores de projetos ou produtos:
Partindo do pressuposto de que já existe um processo de classificação e metrificação das atividades realizadas, passe a monitorar os eventos listados na seção de “efeitos da entropia do software” para decidir quando uma iniciativa que visa controlar a entropia deve ser iniciada.
Para desenvolvedores:
Todos os dias. Conter e endereçar o aumento da dívida técnica é um esforço contínuo. Por aqui brincamos com a analogia do escoteiro. O bom escoteiro sempre deixa o acampamento igual ou melhor do que encontrou. Pequenas refatorações, realizar code review e seguir boas práticas de desenvolvimento vão ajudar a manter a saúde do projeto.
Além disso, sempre avalie a necessidade de refatorações antes de começar grandes iniciativas de desenvolvimento (sejam novas ou modificações) para que as funcionalidades possam coexistir de uma boa forma.
Conclusão
A entropia do software é o nível do caos do seu sistema. Controlar o nível de caos é fundamental para garantir a longevidade do sistema em questão.
Ações extraordinárias para o combate ao caos não devem ser vistas como perda de tempo e normalmente vão gerar retorno positivo, mas é necessário avaliar a criticidade, momento de realização e estratégia.
Referências
https://www.toptal.com/software/software-entropy-explained
https://lostechies.com/jimmybogard/2009/02/11/entropy-in-software/
