Parte 2 — A entropia do software
Ainda que comparado com engenharias que tratam mais do mundo físico (como a Engenharia Civil), a Engenharia de Software está imune a praticamente todas as leis físicas. Entretanto uma delas nos atinge em cheio quando se trata de “complexidade” são elas as leis da entropia.
Entropia (do grego εντροπία) significa o grau de desordem de um sistema.
A entropia é uma característica inerente a sistemas complexos (assim como o software) que são caracterizados pela sua grande quantidade de componentes e relações/interações entre si.
As leis da entropia garantem que no universo a entropia tende ao máximo. E quando a entropia aumenta (a palavra complexidade é muito genérica e muito má utilizada em diversos contextos) o grau de controle do que se está observando cai.
Para ilustrar a questão de complexidade analisemos a figura abaixo:
Perceba que para N nós de uma rede, se todos estes nós se comunicarem uns com os outros, seguimos uma quantidade de relações que seguem a fórmula onde o número de conexões total é dado por C = (N x (N — 1)) / 2, ou seja, ao passo que introduzimos novos componentes em um sistema a quantidade de relacionamentos e dependências também tende a aumentar.
Estendendo um pouco esta discussão (não tratada no livro), podemos imaginar nossas arquiteturas atuais, sistemas distribuídos, baseados em SOA ou até mesmo em Microsserviços (SOA feito da maneira correta), APIs e etc onde possuímos inúmeros pequenos componentes independentes e distribuídos que são organizados de modo a resolver os desafios específicos de cada sistema.
Outra característica interessante de se comentar são as propriedades emergentes de sistemas complexos. Pense em um avião, que é um sistema complexo, a união de todas seus componentes fazer com que ele seja capaz de voar, mas se pegarmos apenas uma turbina, ou apenas as asas, ou somente um pequeno conjunto de seus componentes, essa capacidade emergente não aparece, sendo necessária a união de tudo o que há no avião para que essa capacidade se manifeste.
O mesmo ocorre com seu sistema, apenas um de seus algoritmos, ou um de seus serviços, não resolve o problema por completo. Apenas a junção e organização de seus componentes serão capazes de resolver o desafio enfrentado por completo.
Muitos são os fatores que contribuem para a Entropia no software e os mais importantes aparentam ser os psicológicos e os culturais. Todos nós já vivenciamos projetos que mesmo muito bem planejados acabam em uma desordem total, ou então projetos que apesar de seus problemas e dificuldades, terminam com boa organização e código bem escrito.
Então, o que faz a diferença par “controlar” a Entropia no software?
Você já ouviu falar da “Teoria da Janela Quebrada”?
Pesquisadores chegaram a conclusão que edifícios limpos e bem conservados podem rapidamente se tornarem feios e destruídos e tudo começa com uma simples janela quebrada.
O que isso quer dizer? Pense em um belo prédio, agora imagine que uma janela desse prédio seja quebrada. Nesse momento ele deixa de ser tão belo, certo? E se essa janela não for rapidamente consertada, o que pode acontecer? Esse é o ponto central desta teoria. A partir deste momento, quando uma janela não for rapidamente consertada as pessoas que ali convivem e interagem com aquele espaço, mudarão rapidamente sua visão sobre a conservação do prédio e até mesmo a sua utilidade e poderão passar a vandalizar o local, quebrando não somente as janelas mas com o passar do tempo levando o prédio a uma completa destruição.
No software é exatamente o mesmo que acontece, tudo começa com um bom plano e a melhor das intenções quanto ao que será desenvolvido, mas com o passar do tempo e conforme as dificuldades vão surgindo, acabamos assumindo débitos técnicos e tomamos decisões que nem sempre são as melhores, com a ideia de que no futuro (doces mentiras) conseguiremos tempo para corrigir e colocar as coisas em ordem como deveria.
É aí onde mora o perigo. A partir desta decisão postergada, próximas pessoas que terão contato com aquele software já declaradamente com problemas não dará importância ao que está fazendo, afinal, o que é uma gambiarra a mais ou a menos?
Resumindo, desordem só gera mais desordem.
E se o software estiver “impecável”, com boas decisões de arquitetura, boa orientação a objetos, tecnologias bem aplicadas e etc? Neste caso, todos que entrarem em contato se sentirão no dever de manter aquela bela forma, de cultivar as boas práticas e organização que ali foi plantada.
Desta forma, anotemos mais uma das dicas dos autores:
#4 — não conviva com janelas quebradas
Contribuindo um pouco mais com esta ideia, no Livro “Código Limpo” do Uncle Bob (recomendo a leitura) ele cita a regra dos escoteiros: “Deixe o lugar mais limpo do que estava quando você chegou”
Esta regra nos serve também como mais um mantra para o dia a dia, tenhamos em mente sempre manter a organização daquilo que estamos fazendo e deixá-la melhor do que a encontramos. Seja um código, arquitetura, documentação ou processo.
Não convivamos com janelas quebradas! :)
E se você gostou desde texto deixe 20 claps para ajudar a espalhar a palavra e compartilhe este texto! ;)
PS. Comentários são bem vindos! E se você gostou deste texto, leia a continuação dele “Parte 1 — Uma filosofia pragmática”!
