A Zona de Fluxo do programador

A Zona de Fluxo do programadorTodos 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.

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.

O que é 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, 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.

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 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
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!


Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

10 comentários

  1. Muito obrigado pelas dicas.
    Feliz Natal e Feliz Ano Novo!

    Dois programadores por tela melhoria a qualidade do sistema, mas o quanto mais caro esse mesmo sistema sairia para o cliente que está pagando a conta?

    1. Feliz Ano Novo pra você também, Roberto!
      Alocar dois desenvolvedores em Pair Programming significa o dobro do custo de mão-de-obra para desenvolvimento, certo? Bom, depende! Empresas que trabalham com XP já incluem essa estimativa de esforço no custo do projeto, principalmente baseado em métricas. Dessa forma não haverá “surpresas” para o cliente ou prejuízos no projeto.
      Por outro lado, é correto também pensar da seguinte forma: o Pair Programming minimiza erros potenciais no código e aumenta a confiabilidade, evitando o retrabalho e o tempo desperdiçado com bugs identificados. Logo, é visível a vantagem tanto no tempo quanto na qualidade. O gestor de projetos pode encurtar prazos ou aumentar a quantidade de histórias do cliente (ou a Sprint Backlog, no Scrum) para cada entrega.
      Obrigado pelo comentário!

  2. Por isso que se dividi o software em camadas lógicas, pois de acordo com o gênero do problema fica mais fácil resolver um problema devido a fragmentação do software e,m camadas

    1. Olá, Lindemberg.

      Camadas lógicas, quando bem empregadas, realmente facilitam a resolução de problemas. Porém, existem situações em que as regras do segmento do cliente é bastante complicada. Isso nos faz entrar na Zona de Fluxo não por questões técnicas, mas pela complexidade do negócio.
      Além disso, vale ressaltar que padrões de arquitetura facilitam a manutenção e sofisticam a estrutura do projeto, mas, mesmo assim, não poupam os desenvolvedores da necessidade de depurar uma aplicação para descobrir o motivo de uma exceção. Essa atividade sempre existirá.

      Abraço.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.