Nós estamos em Flow Zone (Zona de Fluxo)

/applications/core/interface/imageproxy/imageproxy.php?img=https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-ash3/1619643_668983776478755_10366496_n.jpg&key=0872d364b62caa2bfc8c3374da07406d062c96fb2911d03b4e4d72cf5dcc0c61" alt="1619643_668983776478755_10366496_n.jpg" />

Muito interessante, resolvi postar, pois vai ajudar alguns irmãos.

Nós estamos em Flow Zone (Zona de Fluxo)

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á?
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, certo? Esse é o ponto onde quero chegar. Todavia, 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.
Ela é realmente 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.
E o lado negativo?

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 destacar 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 voltava do trabalho. 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.

Publicado originalmente no blog SubRotina