A sindrome do arquiteto astronauta

Desde que iniciei minhas aventuras com programação, na época que não fazia mais que encontrar novos meios de se usar a função SE no Excel 5, sempre gostei de pensar, inventar, descobrir e usar coisas novas. Cada novidade que eu podia experimentar, que podia tornar o código que eu escrevia mais agradável, me trazia satisfação. Não me bastava saber como criar uma tela de cadastro, isso já no Delphi, eu queria sempre buscar uma nova maneira, mais eficiente, de fazer isso, e ainda hoje tenho esse impeto pela inovação e pela maior eficiência. Arquitetura de Software sempre foi a minha praia dentre as várias que um desenvolvedor de software pode escolher. E claro, quem experimenta coisas novas erra muito mais que acerta. É necessário muita experimentação até se conseguir maturidade para identificar as chances de sucesso do próximo experimento, portanto coleciono muitas decisões equivocadas, das quais me orgulho pois cada uma delas contribuiu para os acertos seguintes.

Em meados de 2008, num período em que eu já me considerava capaz de criar soluções mais elaboradas, e já estudava com mais profundidade temas como padrões de projeto e boas práticas de desenvolvimento, me lembro estar construindo uma solução que, obviamente, tendia à perfeição. No entanto cada uma das imperfeições ainda existentes me incomoda absurdamente e cada dia eu gastava mais tempo tentando me livrar delas. Foi nesse período que alguém me disse: "você está sofrendo da síndrome do arquiteto astronauta, não deixe a busca pela perfeição te impedir de fazer um bom trabalho". Minha primeira reação foi pensar que aquilo simplesmente não fazia sentido, seja lá o que fosse a tal síndrome, já que buscando a perfeição, obviamente eu acabaria fazendo um bom trabalho. No entanto, na mesma época eu também passava por um processo de amadurecimento profissional forçado em que decidi aceitar toda crítica recebida independente de concordar ou não, buscando tirar algo positivo dela. Era mesmo possível que eu estivesse buscando algo desnecessário, ao menos para aquele contexto?

O arquiteto astronauta é aquele que vive no mundo da lua, fora da realidade, buscando soluções de outro mundo, vidrado demais em padrões e mais padrões, buscando sempre a solução mais perfeita possível sob o ponto de vista técnico. Para ele, se a solução pode ser melhorada, ela deve ser melhorada, e deve ser melhorada de imediato. Se uma tecnologia nova e interessante surge, ele vai querer usá-la, ainda que não tenha real necessidade. Se um novo padrão está bombando e se propõe a resolver o problema que ele enfrenta, ele irá querer usar tal padrão a qualquer custo. Assim cada vez mais novas tecnologias e padrões vão sendo agregadas a suas soluções, e dai começam a surgir as evidências de que sua super complexa, moderna e foda arquitetura, não é tão perfeita assim.

"Simples é melhor". "Mantenha isso simples, estúpido". "Você não vai precisar disso". São princípios listados entre as boas praticas que um bom arquiteto deve ter a obrigação de seguir, mas que normalmente são ignoradas pelo arquiteto astronauta. Hoje sei bem disso. Caso as ignore, suas soluções acabarão lotadas de tecnologias e padrões que tornarão seu código mais complicado de ser compreendido e modificado, a execução do software ficará mais lenta, dadas as camadas e mais camadas de abstração e linhas de execução, você mesmo ficará sobrecarregado em ter que gerenciar aquilo tudo.

Pra encerrar a história: Tenha sempre em mente a sua necessidade atual. Necessidades futuras mudarão, e suas soluções previamente implementadas podem se quer vir a atendê-las, quanto menos da melhor forma. "Você não vai precisar disso". Mantenha as suas soluções simples. Evite abstrações demais, que não se justifiquem na prática. E quanto aos princípios SOLID, lembre-se que eles existem para lhe orientar no processo de refatoração e melhoria de código, não no processo de construção. Evite otimizações antecipadas, antes de ter uma versão menos otimizada do código já funcionando, ou ainda, antes de identificar que tais otimizações são realmente necessárias. E o principal, evite criar situações apenas para lhe permitir usar um determinado padrão ou tecnologia. Não é por que programação distribuída lhe oferece diversas vantagens em diversos cenários que você deve executar cada procedimento em uma thread separada. Não é por que MongoDB é legal que você deve descartar o bom e velho Oracle sem pensar duas vezes.

Apague o seu código para torná-lo melhor

Menos é mais. Essa é uma máxima um pouco banal, mas as vezes é verdadeira. Uma das melhorias que tenho feito em nossa base de código nos últimos anos tem sido remover pedaços dela.

Escrevemos o software seguindo dogmas de XP, incluindo YAGNI (que quer dizer, You Aren’t Gonna Need It, Você Não Vai Precisar Disso). Mas sendo nossa natureza humana como é, inevitavelmente somos fracos em alguns pontos.

Observei que o produto estava levando muito tempo para executar certas tarefas, tarefas simples que deveria ser quase instantâneas. Isso por que estavam sobre-implementadas – enfeitada com firulas que não eram necessárias, mas que naquele momento pareciam ser uma boa ideia.

Então simplifiquei o código, melhorei sua performance, e reduzi o nível de entropia global do código simplesmente removendo as funcionalidades desnecessárias da base de código. Prestativamente, meus testes unitários me disseram que eu não havia quebrado nada durante essa operação. Uma experiência simples e plenamente satisfatória.

Mas por que o código desnecessário acabou lá em primeiro lugar? Por que um programador sentiu a necessidade de escrevê-lo, e como isso passou pelos processos de revisão de código e programação em pares? Quase certamente algo do tipo:

- Era um coisa legal de se escrever e o programador queria escrevê-la. (Dica: Escreva código porque agrega valor, não porque você que agrada);

- Alguém imaginou que isso seria necessário no futuro, então sentiu que seria melhor escrever isso já agora. (Dica: Isso não é. YAGNI. Se você não precisa disso agora, não escreva isso agora);

- Não parecia que o “extra” era tão grande assim, então seria mais fácil implementar isso agora do que ir até o cliente para ver se isso era realmente necessário. (Dica: Sempre leva mais tempo escrever e manter código extra. E o cliente na verdade é bem acessível. Uma pequena porção de código extra vira uma bola de neve com o tempo e se torna uma grande porção de código a ser mantido);

- O programador inventou requisitos extras que não estavam nem documentados nem discutidos para justificar a funcionalidade extra. O requisito era na verdade falso. (Dica: Programadores não definem requisitos, o cliente define);

No que você está trabalhando agora? Isso é realmente necessário?

Pete Goodliffe

97 Things Every Programmer Should Know: Collective Wisdom from the Experts, Kevlin Henney, O'Reilly Media, Fevereiro de 2010, pág. 78

Aprendizado Contínuo

Vivemos em tempos interessantes. À medida que o desenvolvimento é distribuído pelo mundo, percebemos que há muitas pessoas capazes de fazer o nosso trabalho. É preciso continuar aprendendo para se manter no mercado. Caso contrário, nos tornamos dinossauros, presos no mesmo trabalho, até que, um dia, deixamos de ser necessários ou temos nosso trabalho terceirizado para uma fonte mais barata de recursos.

Sendo assim, o que fazer a respeito? Alguns empregadores são generosos o suficiente para fornecer treinando para ampliar nosso conjunto de habilidades. Outros podem não ser capazes de dispor do tempo ou dinheiro para nos oferecer qualquer formação. Por segurança, precisamos assumir a responsabilidade sobre nossa própria educação.

Aqui está uma lista de dicas de como se manter atualizado. Muitas destas podem ser obtidas de graça na Internet:

• Leia livros, revistas, blogs, feeds do Twitter e sites. Se você quiser se aprofundar em um assunto, considere se juntar a uma lista de discussão ou de notícias.
• Se você realmente quiser ficar imerso em uma tecnologia, coloque a mão na massa – escreva algum código.
• Sempre tente trabalhar com pessoas mais experientes; ser o melhor pode paralizar seu aprendizado. Embora você possa aprender com qualquer pessoa, aprenderá muito mais com alguém mais inteligente ou mais experiente que você. Se não conseguir encontrar um mentor onde trabalha, considere seguir outros caminhos.
• Use mentores virtuais. Procure autores e desenvolvedores na Web que você goste de ler. Assine seus blogs.
• Conheça os frameworks e bibliotecas que você usa. Saber como algo funciona faz com que você saiba como usá-lo melhor. Se forem código aberto, melhor ainda. Use o depurador para percorrer o código para ver o que está acontecendo por baixo dos panos. Você vai começar a ver códigos escritos e revisados por pessoas realmente inteligentes.
• Sempre que você cometer um erro, corrigir um bug, ou tiver um problema, tente entender o que aconteceu. É provável que alguém já tenha passado pelo
mesmo problema e tenha postado na web. o Google é bastante útil nesse momento.
• Uma boa maneira de aprender algo é ensinar ou falar a respeito. Quando as pessoas lhe ouvem e lhe fazem perguntas, você fica mais motivado
a aprender. Tente ensinar algo a seus colegas de trabalho, em um grupo de usuários, ou em uma conferência local.
• Faça parte ou inicie um grupo de estudos ou um grupo de usuários para uma linguagem, disciplina ou tecnologia em que esteja interessado.
• Vá a conferências. E se não puder ir, muitas conferências disponibilizam suas palestras online gratuitamente.
• Vai fazer uma longa viagem? Ouça a um podcast.
• Você costuma executar alguma ferramenta de análise estática de código, ou verifica os warnings na sua IDE? Entenda o que eles estão relatando e por quê.
• Siga os conselhos do “The Pragmatic Programmer”* e aprenda uma nova linguagem a cada ano. Ou ao menos aprenda uma nova tecnologia ou ferramenta. Esses estudos podem lhe dar novas idéias, que você pode usar com suas tecnologias atuais.
• Nem tudo o que estudar tem de ser sobre tecnologia. Entenda o domínio em que está trabalhando, assim você poderá entender melhor os requisitos e
ajudar a resolver problemas de negócio. Aprender a ser mais produtivo, como trabalhar melhor, é outra boa dica.
• Volte para a escola. Faça um novo curso.

Seria bom ter a capacidade que tem o Neo, em Matrix, e simplesmente baixar as informações que precisamos para nossos cérebros. Mas não temos, por isso temos que assumir um compromisso mais longo de aprendizado. Você não precisa gastar cada hora acordado estudando. Um curto período, digamos uma vez por semana, já é melhor que nada. Há (e deve sempre haver) uma vida além do trabalho.

A tecnologia muda rapidamente. Não fique para trás.

Clint Shank

97 Things Every Programmer Should Know: Collective Wisdom from the Experts, Kevlin Henney, O'Reilly Media, Fevereiro de 2010, pág. 36.