O que é Complexidade?

Recentemente, terminei de ler "A Philosophy of Software Design" e no segundo capítulo ele explora o tema Complexidade de Software. 

O livro "A Philosophy of Software Design" define a complexidade de forma prática:

"Complexidade é qualquer coisa relacionada à estrutura de um sistema de software que o torna difícil de entender e modificar."

Em outras palavras, a complexidade pode assumir muitas formas e não necessariamente tem nada a ver com desempenho, seu código pode ter desempenho e ainda assim ser complexo

Gostaria de compartilhar neste artigo algumas definições e insights importantes do livro. Mas primeiro, vamos imaginar uma situação comum na qual provavelmente você já esteve…

Uma curta história de terror

Vamos mergulhar em uma história de terror que muitos de vocês provavelmente já vivenciaram ou irão vivenciar.

1. Tudo começou com um aplicativo simples de gerenciamento de tarefas CRUD. O código era limpo, modular e fácil de manter. A equipe de desenvolvimento ficou satisfeita e o sistema funcionou perfeitamente para os clientes iniciais.

2. Os problemas começaram quando a equipe de vendas vendeu o sistema para uma grande empresa, alegando que ele tinha integração de calendário, notificações por e-mail e um gerador de relatórios incrível. Com a venda finalizada, esses recursos tiveram que ser implementados rapidamente.

3. Integração com calendário: A equipe teve que se integrar ao Google Agenda e ao Outlook. Diferentes desenvolvedores implementaram as soluções, resultando em abordagens inconsistentes.

4. Notificações por email: Notificações por email foram adicionadas em seguida. Um desenvolvedor usou uma biblioteca específica, enquanto outro criou uma solução personalizada. As abordagens mistas tornaram o código confuso.

5. Gerador de relatórios: Para o gerador de relatórios, os desenvolvedores usaram várias tecnologias: PDFs, exportações de Excel e painéis interativos. A falta de uma abordagem unificada tornou a manutenção um pesadelo.

6. Crescente complexidade: Cada recurso foi desenvolvido isoladamente e rapidamente, levando a dependências entre recursos. Os desenvolvedores começaram a criar "soluções rápidas" para fazer tudo funcionar, aumentando a complexidade e o acoplamento do sistema.

O desenvolvimento de software não acontece no vácuo; vários fatores internos e externos influenciam isso. Todos nós já estivemos ou estaremos em uma situação como esta.

O Começo do Fim

Então começaram os problemas:

1. Mudanças em uma parte do sistema afetaram outras partes inesperadamente.
2. Pequenas alterações exigiram modificações em muitos outros arquivos, dificultando as estimativas.
3. Mês após mês, o código se tornou mais difícil de entender, muitas vezes corrigido por tentativa e erro.
4. A produtividade diminuiu e todos temiam as tarefas de manutenção.
5. O apelo inevitável para "Precisamos refatorar".
6. Certas tarefas só poderiam ser realizadas por desenvolvedores específicos (clássico)
7. Com o tempo, o software que antes era lindamente escrito e bem documentado se tornou um desastre.

Nomeando os sintomas

Está claro que agora temos um sistema complexo.

Agora vamos “dissecar” essa complexidade para facilitar sua identificação e mitigação.

Bem, "mitigar" significa:

"Para tornar menos grave, sério ou doloroso; para aliviar."

Acredito que a complexidade geralmente é inerente ao código. Algumas coisas são complexas por natureza. Seu papel como desenvolvedor não é apenas criar código que o computador possa executar com eficiência, mas também criar código com o qual futuros desenvolvedores (incluindo você mesmo) possam trabalhar.

“Controlar a complexidade é a essência da programação de computadores.”

-Brian Kernighan

O autor do livro mencionado afirma que a complexidade normalmente se manifesta de três maneiras, que exploraremos aqui.

Alterar amplificação

A amplificação da mudança ocorre quando uma mudança aparentemente simples requer modificações em muitos lugares diferentes.

Por exemplo, se o Product Owner solicitar um campo de "prioridade" ou "data de conclusão" e suas entidades estiverem fortemente acopladas, quantas alterações você precisaria fazer?

Carga Cognitiva

Carga cognitiva refere-se à quantidade de conhecimento e tempo que um desenvolvedor precisa para concluir uma tarefa.

Então imagine este cenário: um novo desenvolvedor se juntou à equipe e foi designado para corrigir um bug no gerador de relatórios. Para concluir esta tarefa, o desenvolvedor precisava:

• Entenda as diferentes integrações de calendário (Google e Outlook).
• Compreenda as diferentes abordagens para notificações por e-mail.
• Navegue pelo código fragmentado do gerador de relatórios, lidando com PDFs, Excel e dashboards.
• Integre essas diversas tecnologias e estilos para encontrar e corrigir o bug.

É o cenário clássico "impossível de estimar", onde a tarefa pode levar um ponto ou oito - melhor rolar um D20 e responder de acordo.

Desconhecidos desconhecidos

Incógnitas desconhecidas são quando você não sabe o que não sabe.

Esta é a pior manifestação de complexidade porque você pode alterar coisas que não deveria, fazendo com que tudo quebrasse.

Exemplo: um desenvolvedor modificou o código de envio de e-mail para adicionar uma nova notificação, sem saber que isso afetaria o gerador de relatórios, que dependia dessa função. Isso causou problemas significativos para os clientes, exemplificando a pior forma de complexidade emergente.

Causas da Complexidade

Tendo visto a história de terror e os três sintomas principais, vamos ver o que causa a complexidade.

1. Dependências

Dependências são essenciais em software e não podem ser completamente eliminadas. Eles permitem que diferentes partes do sistema interajam e funcionem juntas. No entanto, as dependências, quando não gerenciadas adequadamente, podem aumentar significativamente a complexidade.

Definição:

Existe uma dependência quando o código não pode ser entendido ou modificado isoladamente, exigindo consideração ou modificação do código relacionado.

Tipos de dependências:

• Direto: O Módulo A depende diretamente do Módulo B.
• Transitivo: O Módulo A depende do Módulo B, que depende do Módulo C.
• Cíclico: Os módulos A, B e C são interdependentes de maneira circular.

2. Obscuridade

A obscuridade ocorre quando informações importantes não são óbvias. Isso pode dificultar a compreensão da base de código, levando ao aumento da carga cognitiva e ao risco de incógnitas desconhecidas.

Definição:

A obscuridade ocorre quando informações importantes não são óbvias.

Exemplos de obscuridade:

• Nomenclatura inadequada: Variáveis ​​e funções com nomes pouco claros.
• Efeitos colaterais ocultos: Métodos que executam ações inesperadas.
• Estado global: Uso excessivo de variáveis ​​globais.
• Herança profunda: Comportamento espalhado por vários níveis nas hierarquias de classe.

Lembre-se: a complexidade é incremental

• A complexidade raramente é causada por um único "erro" ou má decisão.
• A complexidade aumenta "lentamente" por meio de más decisões e dependências ao longo do tempo.

Como é incremental, é fácil pensar: “só desta vez, não importa”. Mas quando acumuladas, consertar uma ou duas dependências por si só não fará muita diferença.

“Tudo é uma troca na engenharia de software.”
— Não me lembro do autor

Conclusão

Eu poderia escrever muitas regras, estratégias e frameworks que você provavelmente já viu na internet sobre como evitar complexidade: SOLID, Design Patterns, YAGNI, KISS, etc.

No entanto, você pode unificá-los todos em um princípio orientador (conforme mencionado em "The Pragmatic Programmer."): "O que estou implementando é fácil de mudar?" Se a resposta for não, então você provavelmente está aumentando a complexidade.

Garantir que seu código seja fácil de alterar simplifica a manutenção, reduz a carga cognitiva dos desenvolvedores e torna o sistema mais adaptável e menos sujeito a erros.

Obrigado!