A Zona de Fluxo do programador

Todos nós sabemos o quanto a atividade de programação exige concentração e raciocínio. Enquanto escrevemos código, é necessário levarmos em consideração a qualidade do software, regras de negócio, requisitos não-funcionais e validações. É bastante coisa.
Este artigo aborda um estado de consciência do programador conhecido como “Zona de Fluxo”, ou Flow Zone, em inglês. Em linhas gerais, trata-se da fixação da linha de raciocínio em uma atividade complexa de programação.

O que é Zona de Fluxo?

Desde que iniciei a minha carreira na área de programação, notei o quanto este trabalho exige uma linha de raciocínio constante. Geralmente, antes de escrever o código, o programador precisa entender a regra de negócio, interpretar o código já existente, estudar uma solução, implementá-la e testá-la. E mais, todos estes itens devem obedecer aos requisitos funcionais, não-funcionais e restrições exigidas na especificação. A mente do programador deve ser flexível para comportar todos estes aspectos.

Você já deve ter se encontrado em um estado no qual parece que está infiltrado no código-fonte, não é? Você foca tanto na leitura e interpretação das linhas do código que acaba esquecendo o mundo ao seu redor. Se estiver ouvindo uma música, deixa de prestar atenção nela. Se uma pessoa lhe chamar pelo nome, você ouve, mas a sua mente ignora. Apesar de assustador, essa é a Zona de Fluxo. Essa zona é algo que construímos quando trabalhamos de modo constante em uma solução ou quando buscamos compreender a causa de um bug no software. Nesse estado de consciência, somos altamente produtivos e escrevemos muito código.
Será?

Exemplo

Antes dos prós e contras, vale citar um exemplo.
Imagine que você esteja respondendo um e-mail importante para o seu chefe e alguém lhe interrompe. Quando você volta a escrever o e-mail, é necessário ler pelo menos o último parágrafo para lembrar o contexto da sua resposta, não é? Esse é o ponto onde quero chegar. Entretanto, no caso de desenvolvimento do software, “ler o último parágrafo” não é o suficiente para retomar a atividade. A linha de raciocínio deve ser reconstruída, e isso leva tempo.

Suponha que você foi alocado para corrigir uma exceção na gravação de um novo cliente no software. Primeiro, a análise da situação: a aplicação cria alguns objetos e chama uma série de métodos antes de persistir os dados no banco. E então, você começa a depurar o código para descobrir qual dos métodos contém inconsistências. Durante esse tempo, você levanta uma linha de raciocínio em cima do problema e constrói uma matriz lógica da sequência de eventos para identificar a causa da exceção. Esse é o momento de entrada na Zona de Fluxo.

A Zona de Fluxo é necessária?

Dependendo da complexidade do problema, sim. Muitas vezes, o programador precisa consultar a sua linha de raciocínio para lembrar o que cada método, objeto ou condição executa na aplicação. É como se fosse uma área de cache: assim como o browser “lembra” dos últimos sites acessados (para que possa abri-los mais rápido), a nossa mente também precisa lembrar-se dos últimos códigos que interpretamos. Portanto, se você estiver em plena concentração e alguém lhe interromper, a linha de raciocínio é quebrada, ou seja, você sai da Zona de Fluxo e apaga o seu cache.

Para retomar a linha de raciocínio leva algum tempo. É preciso rever os métodos e códigos para chegar no ponto em que estava. No cenário organizacional (onde há prazos, métricas e estimativas), perder tempo com o resgate da linha de raciocínio pode ser ruim. Além do tempo, lembre-se que você gasta energia mental para raciocinar. É por isso que quando programamos demais, sem as pausas adequadas, nossa produtividade cai.

Lado ruim

A Zona de Fluxo, apesar de importante para a resolução de alguns problemas, pode resultar em alguns impedimentos. Quando você está altamente focado, é bem provável que você perca a visão do problema como um todo. Em outras palavras, a linha de raciocínio se estreita e lhe faz pensar que a solução irá resolver o problema, quando, na verdade, poderá complicar ainda mais. É importante realçar que a solução encontrada na Zona de Fluxo nem sempre é a mais adequada. Ela pode, por exemplo, tratar o problema no código local, mas afetar outros métodos que utilizam este código. É aquela velha história: “arruma de um lado, bagunça do outro”.

Muitos autores recomendam evitar a Zona de Fluxo para que o programador considere o problema de forma ampla, mesmo que isso seja menos produtivo do que “morar” dentro dela. Segundo estes autores, a Zona de Fluxo somente aparenta trazer uma produtividade maior, já que limita o campo de raciocínio. Logo, o programador provavelmente terá que rever suas decisões e ter o retrabalho de verificar se a solução realmente foi viável.

Para evitar a Zona de Fluxo, dê uma volta, navegue na internet, tome um café ou converse com alguém assim que perceber que está entrando nela. Quando você retornar ao código, suas faculdades mentais poderão enxergar o problema de outra forma. E isso faz sentido! Algumas vezes já encontrei a solução durante o horário de almoço ou enquanto ia ao banheiro. Sério! Isso acontece principalmente quando não consigo encontrar uma solução na primeira tentativa. Só pelo fato de parar um pouco e respirar, novas abstrações surgem.

XP vs Zona de Fluxo

O eXtreme Programming (XP) traz uma técnica eficiente para enfrentar a Zona de Fluxo: Pair Programming! Quando dois programadores trabalham em uma mesma solução, a comunicação é constante e impossibilita a entrada na Zona de Fluxo. Além disso, são duas mentes raciocinando e cada uma pode cobrir dimensões diferentes do problema. Eu, particularmente, já tive ótimos resultados trabalhando com Pair Programming. Algumas vezes, enquanto implementava uma função qualquer no código, o meu par dizia: “André, isso pode causar problemas no método X. Você não acha melhor refatorar e utilizar a passagem de parâmetros?”, e isso me fazia refletir sobre a linha de raciocínio que eu estava seguindo. Sem dúvidas, o Pair Programming já me poupou de muito erros e incoerências.

Aproveitando, deixo meu agradecimento ao Mecias Bueno, grande companheiro de programação com quem compartilho soluções para o projeto que trabalhamos atualmente.

Pessoal, compreendo que há muito mais o que falar sobre este assunto, mas o espaço é curto.
Fico por aqui. Um Feliz Natal para todos vocês!

Abraço!