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. A mente do programador deve ser flexível para comportar todos estes aspectos.
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?
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.
Leitores, obrigado pela visita. Abraço!
Publicado originalmente no blog do André Celestino
11 Comentários
Excelente texto.A situação descrita,é realmente existente,eu já a percebí diversas vezes,principalmente na fase de codificação e também na depuração.Mas é muito bom manter a mente objetiva em tempo integral,pelo menos para mim,isso é uma constante.
Obrigado pelo comentário, jortron.
Devo assumir que a Zona de Fluxo já me ajudou algumas vezes, porém, por outro lado, já me fez perder tempo e produtividade em várias situações. Atualmente, quando me encontro na entrada da Flow Zone, procuro envolver outro(s) desenvolvedor(es) para fazer um brainstorming da melhor solução ou aposto no Pair Programming.
Abraço!
Essa “Zona de fluxo” geralmente é necessária quando o código do sistema está muito complexo, quando fizeram muita coisa errada e no fim ficou uma porcaria de dar manutenção, pois em sistemas que foi bem programado, código desacoplado, com uma cobertura de testes decente. Dificilmente será necessário utilizar tal técnica.
Ótima questão levantada, Robson. Infelizmente essa é a dívida técnica de um código mal escrito. Às vezes entramos na Zona de Fluxo simplesmente para desmistificar o código-fonte. Se o desenvolvedor responsável pelo código ainda estiver na empresa, basta pedir uma orientação. Porém, caso ele não esteja mais disponível, a única saída é (tentar) interpretar o código e aplicar técnicas de refatoração e Clean Code quando possível.
Passou recentemente na TV fechada e aberta .. se trata da relação entre sentidos e atenção. O cérebro tende a filtrar informações, gerar aproximações, que para nós não são importantes para que possamos focar no que parece que é importante naquele momento. Na verdade o cérebro faz isto o tempo todo, com a visão, audição, etc. Vemos e ouvimos aquilo que nos é conveniente … não é necessário criar um estado de transe para isto, apenas não somos tão multitarefas quanto pensamos. Agora .. sobre os pontos positivos e negativos .. realmente são vários. Por exemplo .. em um algoritmo interessante que esteja imaginando, basta uma interferencia para perder o raciocínio e ficar sem a solução do problema. Geralmente você não consegui recriá-lo de jeito algum. O ideal é que não hajam interferências justamente por que elas te fazem perder o seu melhor momento criativo. Já quanto ao par programming .. ele é bom pelo motivo citado, permite ter mais de uma visão sobre o mesmo problema .. mas, no caso, é desfavorável à atenção, causa muitas interferências, muitas vezes desnecessárias, inconvencientes e altamente prejudiciais. Pelo que já estudei e experimentei .. não faria par programming em tempo integral .. mas discutiria o problema em par ou grupo onde tomaria todas as decisões, depois ficaria sozinho e construiria a solução, posteriormente voltaria a me reunir para avaliar os resultados. Discutir em grupo sim, interferência em tempo integral .. não, obrigado.
Olá, Felipe, agradeço pelo comentário, mas discordo a respeito da sua crítica ao Pair Programming. Essa técnica só é desfavorável em casos nos quais os desenvolvedores não sabem como conduzi-la, ou seja, se os desenvolvedores estiverem mais interessandos em terminar uma funcionalidade ao invés de implementá-la com qualidade e integridade, o Pair Programming realmente é desnecessário.
Na minha carreira, como disse no artigo, obtive ótimos resultados com o Pair Programming. Acredito que também tenha sido positivo para outros desenvolvedores, visto que essa técnica é amplamente empregada nos dias atuais por várias empresas como parte do contexto Agile.
A sua sugestão sobre reunir-se com um grupo também é bastante viável, porém, atente-se pelo fato de que “ficar sozinho e construir a solução” não te poupará do risco de entrar na Zona de Fluxo. Muitas vezes, mesmo com uma solução em mente, ainda ficamos propensos a visitar a Zona de Fluxo devido à regra de negócio, interpretação de código-fonte, sequência lógica de eventos ou recursos da linguagem de programação.
Abraço.
Ótimo texto André e parabéns. Agora entendo melhor meu filho, pois toda vez que eu lhe interrompia, ele reclamava da concentração.
Grande abraço.
Parabéns, ótimo artigo André. Estou começando a ler os artigos existentes aqui no site e um dos que mais me chamou a atenção foi esse, percebi uma abordagem com argumentos que nos mostram casos ocorridos em nosso cotidiano que muitas vezes nem são notados.
Como experiência própria já me deparei com situações onde passei cerca de 10,12, 14 e até mesmo 19 horas procurando desenvolver uma solução, e ao dar uma parada de 5 minutos para tomar uma água e desligar um pouco a solução me é mostrada… Como dito por Albert Einstein: “Penso 99 vezes e nada descubro. Deixo de pensar, mergulho no silêncio, e a verdade me é revelada.”
Quanto ao Pair Programming, cheguei a utilizá-la em parte de uma forma menos prática, somente com conversas e debates a respeito de alguns códigos. E, mesmo sem o relacionamento integral entre ambos tivemos resultados bastante proveitosos, além disso não tivemos problemas com Zonas de Fluxos, o que já rendeu bastante tempo e esforço. Só pela aplicabilidade, considero o XP a melhor metodologia de desenvolvimento. (^_^) /
Olá, Túlio!
Gostei muito da frase de Einstein que você compartilhou, e acredito que ela se identifica bastante com a questão da Zona de Fluxo! Assim como você, muitas vezes encontrei a solução enquanto estava longe da estação de trabalho, até mesmo em momentos inusitados, como na fila do supermercado ou dirigindo.
O XP realmente oferece um grande acervo de práticas relacionadas às atividades de desenvolvimento que ajudam a impulsionar a produtividade. Além do Pair Programming, também destaco a padronização de código, integração contínua e refatoração como ótimos pilares técnicos da metodologia.
Grande abraço!
Boa tarde ! Olá André , me chamo Paulo e gostaria por gentileza de tirar uma dúvida a respeito do desenvolvimento de software. Veja bem : eu me escrevi na faculdade para a área de redes , só lá a turma não formou , fui forçado a entrar nessa área de desenvolvimento de software na qual me prometeram que novas turmas iriam surgir, ´só que ate momento nada . Já se passaram 3ª semestre eu estou cheio de dificuldades inicialmente ao tentar programar algo .Será que você poderia me dar uma dica para que possa me desenvolver melhor .
Olá, Paulo.
Sinto muito por toda essa demora para iniciar o curso. Porém, enquanto isso, você pode, sim, já estudar conceitos na área de desenvolvimento de software e aplicá-los na prática.
Eu não sei exatamente quais são as suas dificuldades, mas vou indicar dois cursos online.
O primeiro é um curso gratuito de lógica de programação na Softblue:
http://www.softblue.com.br/site/curso/id/6/CURSO+LOGICA_DE_PROGRAMACAO_BASICO_ON_LINE_LO06
O outro, voltado para a linguagem de programação Java, é uma apostila aberta da Caelum:
https://www.caelum.com.br/apostila-java-orientacao-objetos/
Espero que elas sejam úteis. Abraço!