Conclusão do Curso de Especialista em Estratégias em Arquitetura de Software

Desenvolvo software desde 1998, profissionalmente desde 2002, mas apenas em 2008 identifiquei a área de Arquitetura de Software como aquela que mais me desperta interesse. Naquela época, ainda era uma área bastante marginalizada, ainda sendo um pouco ainda hoje. Afinal, quantas empresas possuem o cargo Arquiteto de Software? Quantas se quer sabem o que seria um Arquiteto de Software? Infelizmente ainda não parecem ser a maioria. Por conta disso, ainda é baixa a oferta de cursos de qualificação específica na área.

Ainda em 2008, soube da criação em Belo Horizonte do IGTI, uma instituição que passava a oferecer o primeiro curso de Estratégias em Arquitetura de Software do país, sendo uma das poucas a oferecer tal curso ainda hoje. Me interessei bastante, mas por inúmeros motivos não me matriculei. Até que, em 2012 soube que o mesmo curso passou a ser oferecido na modalidade de Ensino à Distância e com isso seria bem mais fácil conseguir o tempo necessário para me dedicar às aulas. Não havia mais desculpas. Fiz o curso e gostei bastante. Aprendi muito, ratifiquei boa parte do conhecimento que adquiri na prática ao longo dos anos, fiz bons contatos profissionais e bons amigos.

Desde os primeiros meses de curso, já falávamos a respeito do trabalho de conclusão, e aproveitei a oportunidade para estudar mais a fundo dois temas que muito me agradam, e que visivelmente contribuem para a melhoria da qualidade do meu trabalho e para o aumento de minha produtividade, que são as já bem conhecidas Boas Práticas para Desenvolvimento de Software e as nem tão conhecidas Especificações por Exemplo.

Desde meu primeiro contato com Especificação por Exemplo, então conhecidas por mim apenas como Behavior-Driven Development, já notei o quanto a técnica tornava mais simples a definição do que deve ser feito e como o trabalho deve ser divido, implementado e testado. Tendo uma boa técnica para verificar continuamente a qualidade do trabalho, fica bem mais fácil refatorar continuamente o código e aplicar continuamente as tão famosas Boas Práticas.

O resultado desse trabalho está disponível neste link. Confiram.

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.

Nada substitui o lucro

Se você é um programador apaixonado pelo que faz, já deve ter sofrido bastante ao ver seus chefes, coordenadores, gerentes, ou patrões ignorando questões técnicas de suma importância, para você, como a manutenção de um código fonte de qualidade por exemplo, para viabilizar o cumprimento de um prazo ou algum requisito contratual. Isso é realmente frustrante e deve lhe fazer reclamar bastante pelos corredores e reconsiderar sempre a possibilidade de mudar de emprego, certo?

Não adianta. Onde quer que vamos estamos sempre sujeitos a isso. Você pode até mesmo encontrar uma empresa bacana de se trabalhar, onde os valores técnicos são tão considerados quanto os valores gerenciais, mas se de repente essa empresa entra em crise, rapidamente começaram as demissões, estagiários brotando do chão, agilidade sendo substituída por métodos tradicionais e a qualidade sendo deixada novamente em segundo plano.

Nada substitui o lucro, e isso é algo que você desenvolvedor, por mais bem intencionado que esteja, por mais profissional que seja, e por mais comprometido que se mantenha com a qualidade do código que escreve, não deve deixar de considerar. E não veja isso como algo ruim, ou errado. De fato nada substitui o lucro. Nenhuma empresa é constituída com o objetivo de criar o melhor software se isso não for apenas um meio de levá-la ao lucro. No fim, o que toda empresa busca é o lucro. 

Como então criar software de qualidade se o que interessa à empresa para a qual você trabalha é apenas lucrar? Se um software porcamente feito for mais lucrativo, é isso que a empresa irá lhe demandar, certo? Nem sempre. Cada organização tem seus valores, e muitas já reconhecem que produto de baixa qualidade uma hora ou outra se reverterá em prejuízo. Mas se esse não for o caso da empresa em que você trabalha, não entre numa guerra por interesses que deveriam ser daqueles que lutam contra. Faça sua parte, coloque qualidade no que você faz, na medida em que for possível, e não seja perfeccionista demais, seja mais pragmático. Aprenda também a aceitar que muitas vezes o nível de qualidade necessário será muito inferior ao melhor que você tem capacidade de entregar. Entenda os objetivos do projeto, compartilhe deles, e dentro desse limite, faça o seu melhor.

5 segredos para um propósito compartilhado

Um dos pré-requisitos para um trabalho em equipe saudável e eficiente é sem dúvida ter um propósito compartilhado pela equipe. Abaixo listo 5 segredos elencados por Christopher Avery para facilitar esse objetivo.

1. Estabelecer um entendimento compartilhado:

Discuta cada tópico, a missão, os entregáveis, e o produto do trabalho de sua equipe, até que possam articular juntos uma descrição clara e comum de seu propósito.

2. Selecione sua equipe por sua motivação, não por suas qualificações.

Se trabalho em equipe é importante para você, olhe para as qualificações apenas após considerar diretrizes, energia, interesse, motivação e entusiasmo, por que é um desejo compartilhado, não taleto, que gera trabalho em equipe.

3. Aceite, de uma vez por todas, que colegas de equipe não precisam gostar uns dos outros.

Encorajar afinidade para uma tarefa compartilhada, não para um com o outro, é a maneira mais rápida e certa de criar forte coesão no grupo. Ao invés de usar exercícios e técnicas que promovam a amizade, faça todos adotarem um foco comum de modo que cada membro da equipe veja boas razões para trabalhar um com o outro.

4. Pare de tentar motivar.

Por que tentar motivar outras pessoas quanto isso é quase impossível? Ao invés disso, use a motivação que já existe nos membros da equipe perguntando a eles sobre suas necessidades e desejos.

5. Determine se seu time está "construído".

Um time "construído" compartilha direcionamento e energia. Para atingir esse status para seu time, coloque sua fundação bem cedo perguntando a você mesmo uma variedade de importantes questões. Qual é a tarefa da equipe? Qual o benefício para cada membro da equipe ao se comprometer com esse trabalho? Há acordos que permitam à equipe operar mais rapidamente e eficientemente? Os membros da equipe compartilham um objetivo comum que os inspire? Você sabe o que cada membro da equipe agrega ao time?

Você não pode ganhar todas

Muitas foram as vezes em que me frustrei ao tentar convencer a outros, em especial quando eram superiores hierárquicos, a adotarem uma solução proposta por mim. Na maioria das vezes, diante de um problema, o que eu fazia era elaborar a melhor solução que eu fosse capaz, analisava cada detalhe, não deixava nada de fora, e por fim apresentava aos interessados, muitas vezes nem tão interessados assim, um solução única. Obviamente não era uma solução perfeita, mas já era uma solução bastante questionada e analisada.

O resultado disso, na maioria das vezes, era uma rejeição com base em argumentos mal fundamentados, mal pensados, que não consideravam todo o contexto, que dava importância a fatos irrelevantes e desconsiderava os fatos realmente importantes. Obviamente esse tipo de rejeição é bastante revoltante. No entanto, isso é bastante comum de se ver em situações como essa. Mas há justificativa.

Muitas vezes nós de fato não demos os pesos certos aos fatores considerados, ao menos não segundo a ótica dos demais interessados. Outras vezes não temos todo o domínio do contexto, não conhecemos todos os fatos que serão considerados pelos tomadores de decisão. E outras vezes o tomador de decisão simplesmente erra feio mesmo. O fato é que não podemos ganhar todas. Perderemos muitas. Por motivos legítimos ou por motivos idiotas. Mas essa é a realidade.

Diante disso, já há algum tempo mudei minha tática e ao invés de me focar em obter uma única melhor solução para os problemas que me dedico a resolver, passei a elaborar e propor várias. Na maioria das vezes nenhuma delas trará o melhor resultado de imediato, muitas vezes deixaram a desejar, mas todas elas resultarão em uma realidade melhor que simplesmente continuar convivendo com o problema.

E o que observei com essa mudança de comportamento foi que agora vejo boa parte das minhas propostas sendo colocadas em prática, ainda que muitas delas continuem sendo rejeitadas por uma razão ou outra. Diante de problemas que sei ser capaz de ajudar a resolver, vejo pequenos avanços sendo dados, pequenas ideias sendo implementadas e fazendo a diferença.

Se você é uma pessoa pró-ativa como eu e que não consegue ficar inerte diante de um problema passível de solução, não tente elaborar uma solução fantástica que mudará a realidade para sempre. Pense em pequenos avanços, proponha pequenas mudanças, e proponha muitas delas. Se você for mesmo bom no que faz, aquelas que forem aceitas já poderão tornar a realidade um pouco melhor e lhe darão credibilidade para que seja ouvido novamente no futuro.