Notas ao ler: A Philosophy of Software Design - Capítulo 2

A Philosophy of Software Design é um livro que tenta ensinar como escrever código de qualidade. Aqui estão algumas das minhas notas ao ler o capítulo 2. Eu também estou postando esses e outros textos no meu Patreon (que é de graça).

O autor define complexidade como "qualquer coisa relacionada a estrutura do software que faz com que seja difícil de entender ou modificar tal sistema".

Em outras palavras, complexidade não está relacionado ao tamanho do sistema ou de uma funcionalidade, mas a dificuldade de lidar com ele ao fazer modificações ou consertar algo que deu errado.

O autor define formalmente complexidade como:

Onde a Complexidade do Sistema (C) é determinada pela complexidade de cada parte p, onde c é o tamanho da complexidade da parte e t o tempo em que o desenvolvedor gasta naquela parte do sistema. Essa formula é muito interessante porque mostra claramente que se caso algo seja extremamente complexo, mas o tempo em que o desenvolvedor gaste nela seja nulo ou próximo disso, essa complexidade é bem próxima de zero. Demonstrando a importancia de "esconder" complexidade do dia-a-dia.

Uma dica muito importante que o autor dá é que: "complexidade é mais aparente para o leitor do que para quem escreveu o código. Se alguém fala que o código que você escreveu é complexo, então ele é complexo.

Sintomas da Complexidade

1 Change Amplification: uma mudança que deveria ser simples, acaba gerando mudanças em diversas partes diferentes da aplicação. O autor dá um exemplo bem simples de entender (ao menos para os devs mais velhos). Dá época que a gente escrevia os HTMLs inteiros de um website a mão.

O exemplo: Imagina que um website é feito de várias páginas HTML, todas escritas a mão e que cada uma delas tem um banner. Se a gente quiser trocar a cor de fundo desse banner, a gente vai ter que trocar em cada página. Hoje em dia páginas não são mais feitas assim, e esse tipo de detalhe é configurado em somente um arquivo (e.g. um arquivo css).

2 Cognitive load: Quanto você precisa deixar em mente para executar uma tarefa? Sistemas complexos forçam o programador a manter MUITA coisa em mente. O autor cita o gerenciamento de memória em C, onde o programador tem que lembrar de liberar um pedaço de memória depois de usa-lo e não usar um ponteiro depois de liberar o espaço que ele aponta.

Uma observação importante: algumas vezes uma solução que exige que tem mais linhas de código pode ser mais simples justamente por causa do Cognitive Load.

3 Uknown unkowns: Sistemas complexos são cheios de coisas que não sabemos que não sabemos. Esse é o pior sintoma, pois é o mais complicado de se resolver. Sabe quando você tem que fazer uma tarefa, e não tem ideia de onde começar, quanto vai demorar ou até fica com medo de modificaralguma coisa e quebrar o sistema?

Um dos pontos mais importantes quando fazendo um system design é fazer com que ele seja óbvio, justamente para evitar esse problema.

Causas da Complexidade

Existem duas causas de complexidade: dependências e obscuridade. O livro define dependência como: quando um pedaço de código não pode ser entendido e modificado de forma isolada, o código está relacionado a outro de alguma forma, e onde outra parte do código deva ser mantido em mente e considerado quando uma mudança em outra parte é feita. No exemplo das páginas HTMl, a cor de fundo do banner cria uma dependência entre todas as páginas HTML.

Importante notar que existem dependências explicitas (e.g. uma função é utilizada em uma parte do código) e dependências não-explicitas: duas partes do código usam um mapa de string e precisam que a chave sejam exatamente iguais (e constantes não são utilizadas). Dependências não-explicitas são o pior caso possível.