Em bases de código complexas, interações complexas de efeitos colaterais são a coisa mais difícil sobre a qual acho. Só posso falar pessoalmente, dada a forma como meu cérebro funciona. Efeitos colaterais, estados persistentes, entradas mutantes e assim por diante me fazem pensar sobre "quando" e "onde" as coisas raciocinam sobre a correção, e não apenas "o que" está acontecendo em cada função individual.
Não consigo me concentrar apenas no "o quê". Não posso concluir, depois de testar minuciosamente uma função que causa efeitos colaterais, que espalhe um ar de confiabilidade por todo o código que a utiliza, pois os chamadores ainda podem abusar dela chamando-a na hora errada, no encadeamento errado, no errado ordem. Enquanto isso, uma função que não causa efeitos colaterais e apenas retorna uma nova saída dada uma entrada (sem tocar na entrada) é praticamente impossível de usar dessa maneira.
Mas eu sou do tipo pragmático, acho, ou pelo menos tento ser, e não acho que tenhamos necessariamente de eliminar todos os efeitos colaterais ao mínimo possível para raciocinar sobre a correção do nosso código (no mínimo Eu acharia isso muito difícil de fazer em idiomas como C). Onde acho muito difícil argumentar sobre a correção é quando temos a combinação de fluxos de controle complexos e efeitos colaterais.
Fluxos de controle complexos para mim são os de natureza gráfica, geralmente recursivos ou recursivos (filas de eventos, por exemplo, que não estão chamando diretamente os eventos recursivamente, mas são "recursivos" na natureza), talvez fazendo coisas no processo de atravessar uma estrutura de gráfico vinculada real ou processar uma fila de eventos não homogênea que contém uma mistura eclética de eventos a serem processados, levando-nos a todos os tipos de partes diferentes da base de código e a todos os efeitos colaterais diferentes. Se você tentasse desenhar todos os lugares em que acabaria no código, ele se pareceria com um gráfico complexo e, potencialmente, com nós no gráfico que você nunca imaginou que estariam lá naquele momento, e considerando que eles são todos causando efeitos colaterais,
As linguagens funcionais podem ter fluxos de controle extremamente complexos e recursivos, mas o resultado é tão fácil de entender em termos de correção, porque não existem todos os tipos de efeitos colaterais ecléticos ocorrendo no processo. É somente quando fluxos de controle complexos encontram efeitos colaterais ecléticos que considero indutor de dor de cabeça tentar compreender a totalidade do que está acontecendo e se sempre faz a coisa certa.
Portanto, quando tenho esses casos, geralmente acho muito difícil, se não impossível, me sentir muito confiante sobre a correção de tal código, muito menos muito confiante de que posso fazer alterações nesse código sem tropeçar em algo inesperado. Portanto, a solução para mim é simplificar o fluxo de controle ou minimizar / unificar os efeitos colaterais (ao unificar, quero dizer, causar apenas um tipo de efeito colateral a muitas coisas durante uma fase específica do sistema, não dois, três ou três). dúzia). Eu preciso que uma dessas duas coisas aconteça para permitir que meu cérebro simplório se sinta confiante sobre a correção do código que existe e a correção das alterações que apresento. É muito fácil ter certeza da correção do código que introduz efeitos colaterais, se os efeitos colaterais são uniformes e simples, juntamente com o fluxo de controle, da seguinte forma:
for each pixel in an image:
make it red
É muito fácil argumentar sobre a correção desse código, mas principalmente porque os efeitos colaterais são muito uniformes e o fluxo de controle é muito simples. Mas digamos que tivemos um código como este:
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
Então, esse é um pseudocódigo ridiculamente simplificado, que normalmente envolveria muito mais funções e loops aninhados e muito mais coisas que teriam que continuar (atualizando vários mapas de textura, pesos ósseos, estados de seleção etc.), mas mesmo o pseudocódigo torna tão difícil razão da correção por causa da interação do fluxo de controle complexo tipo gráfico e dos efeitos colaterais que estão ocorrendo. Portanto, uma estratégia para simplificar é adiar o processamento e focar apenas em um tipo de efeito colateral por vez:
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
... algo nesse sentido como uma iteração de simplificação. Isso significa que estamos passando os dados várias vezes, o que definitivamente gera um custo computacional, mas geralmente descobrimos que podemos multithread desse código resultante com mais facilidade, agora que os efeitos colaterais e os fluxos de controle assumiram essa natureza uniforme e mais simples. Além disso, cada loop pode ser mais amigável ao cache do que atravessar o gráfico conectado e causar efeitos colaterais à medida que avançamos (por exemplo: use um conjunto de bits paralelos para marcar o que precisa ser atravessado, para que possamos fazer as passagens diferidas em ordem sequencial classificada usando bitmasks e FFS). Mas o mais importante é que acho a segunda versão muito mais fácil de raciocinar em termos de correção, além de alterar sem causar bugs. De modo a'
E, afinal, precisamos que efeitos colaterais ocorram em algum momento, ou então teríamos apenas funções que geram dados sem ter para onde ir. Frequentemente, precisamos gravar algo em um arquivo, exibir algo em uma tela, enviar os dados por um soquete, algo desse tipo e todas essas coisas são efeitos colaterais. Mas podemos definitivamente reduzir o número de efeitos colaterais supérfluos que ocorrem e também reduzir o número de efeitos colaterais quando os fluxos de controle são muito complicados, e acho que seria muito mais fácil evitar erros se o fizéssemos.