Boris Litvinsky, líder técnico do Wix, apresentou recentemente, em uma palestra no ReactiveConf em Praga, as razões para adiar as decisões tomadas no processo de desenvolvimento de software pode resultar em uma melhor base de código. Também comentou sobre algumas práticas de design e codificação que suportam o atraso ou a reversão de decisões.
Litvinsky começou descrevendo como a equipe discutiu durante mais de três semanas sobre qual solução de gerenciamento de estado (Redux ou Mobx) usar no projeto greenfield, baseado em React, no Wix. As três semanas foram gastas com discussões internas, seguidas de uma pesquisa individual, justamente com entrevistas com especialistas em React no Wix, terminando em uma matriz de decisão. O entendimento era de que essa decisão era tão crítica que precisava ser tomada imediatamente, e se escolhessem a biblioteca errada, seria impossível reverter a decisão. Eles verificaram que nenhum outro projeto baseado em React em produção na empresa, estava realmente usando qualquer biblioteca de gerenciamento de estado, ao menos não naquela época.
Litvinsky relembrou que pensavam que tinham que escolher entre uma decisão certa ou errada, enquanto na verdade havia uma terceira opção, não tomar nenhuma decisão. Isso decorre do fato de que talvez não haja conhecimento suficiente no momento em que um problema é analisado para realmente tomar qualquer tipo de decisão racional e informada, especialmente nos casos de decisões com alto impacto no projeto. Litvinsky sugeriu que a melhor opção seria adiar a decisão até que informações suficientes fossem coletadas sobre o problema em questão para gerar possíveis soluções.
Após essa introdução, na primeira das quatro seções das palestras, Litvinsky explicou em detalhes a lógica por trás do adiamento da decisão, citando a definição de arquitetura de Martin Fowler:
Arquitetura é a decisão que desejamos acertar no início de um projeto.
As decisões iniciais têm um impacto proeminente, pois são muito mais difíceis de reverterem e são as bases para toda a aplicação. No entanto, os desenvolvedores tendem a iniciar um projeto ou produto com uma grande série de perguntas, como monólitos ou microservices, qual estrutura de interface de usuário frontend adotar, quais bancos de dados utilizar para quais serviços, Sass ou LESS e mais algumas dezenas de perguntas. Nem todas essas decisões são arquitetônicas, portanto não devem ser tomadas desde o início.
Litvinsky lamentou que, na ausência de informações apropriadas e de uma compreensão holística do contexto, as decisões iniciais muitas vezes sejam influenciadas por experiências anteriores com tecnologias, excesso de confiança ou ego específicos. Em vez disso, a sabedoria expressa no princípio YAGNI deve levar os desenvolvedores a tomar decisões somente quando for necessário, as informações devem ser suficientes e estar disponíveis em relação ao problema que estamos tentando resolver e as soluções previstas devem efetivamente estar resolvendo os problemas.
Litvinsky justificou os benefícios de adiar as decisões sobre tecnologias, revisando com o público o Hype Cycle, um conceito popularizado pelo Gartner. De acordo com o conceito, uma tecnologia evolui ao longo do tempo através de uma série de fases distintas: gatilho da tecnologia, pico de expectativas infladas, vale da desilusão, ponto de esclarecimento, chegando finalmente ao platô da produtividade.[a] À medida que as tecnologias passam pelo ciclo e amadurecem, os casos de uso em que são bem sucedidas, tornam-se claros. Isso significa que, quanto mais tempo uma decisão relacionada a uma tecnologia específica for adiada, mais certeza haverá de que a tecnologia será escolhida pelo motivo certo.
O CEO do Facebook, Mark Zuckerberg, declarou em 2012 que apostar no HTML5 foi um erro, em oposição ao desenvolvimento de aplicações nativas de dispositivos móveis, por uma série de razões que são fáceis de entender analisando o background. No ano passado, o AirBnB explicou que depois de entender melhor os casos de uso, como os requisitos e limitações do React Native, decidiram deixá-lo até 2019, para utilizar ferramentas nativas de desenvolvimento móvel.
Outro argumento para adiar algumas decisões é que a arquitetura existe para dar suporte aos requisitos. Atrasar o desenvolvimento permite a estabilização dos requisitos, proporcionando uma confiança maior de que a arquitetura está sendo otimizada.
Por todas essas razões, Litvinsky argumentou que não tomar decisão às vezes é a melhor coisa a se fazer. Na segunda seção da palestra, foi discutido quatro coisas que podem ser adiadas.
Primeiro são as estimativas iniciais, antes de um entendimento adequado do problema e do domínio técnico, geralmente são irreais e podem ser melhoradas quando adiadas. Os desenvolvedores também devem evitar a instalação de qualquer pacote antes que a necessidade surja e seja validada, e avaliações mostram que a necessidade do pacote realmente não surge de um problema de design.
Litvinsky mencionou a criação de abstrações como a terceira atividade que não deve ser apressada, e citou a Regra dos Três. A regra apareceu na edição de 2004 do Facts and Fallacies of Software Engineering, que afirmava:
Existem duas "regras dos três" na reutilização [do software]:
- É três vezes mais difícil construir componentes reutilizáveis que componentes de uso único e;
- Um componente reutilizável deve ser testado em três aplicações diferentes antes de ser suficientemente geral para ser aceito como uma biblioteca reutilizável.
A regra dos três, aplicada à decomposição de componentes em estruturas de interface do usuário, recomenda isolar um componente reutilizável quando houver pelo menos três diferentes usos possíveis desse componente.
Da mesma forma, a decisão de dividir uma aplicação monolítica em microservices pode ser adiada. Os microservices têm vantagens claras, especificamente quando uma aplicação está enfrentando problemas de escalabilidade, mas o uso desse padrão também vem com uma maior complexidade, sobrecarga organizacional e excesso de testes. Litvinsky aconselhou aguardar o surgimento dos limites de domínio e da organização antes de considerar essa opção. Isso está de acordo com os conselhos de Jan de Vries, MVP da Microsoft no Azure, que comentou em sua palestra no MicroXchg Berlin, que um monolito adequadamente construído, em muitos casos, é superior a um sistema baseado em microservices.
A terceira seção da palestra introduziu opções reais como parte de uma estrutura de pensamento, permitindo que os praticantes decidam quando adiar uma decisão. Opções reais no contexto da engenharia de software foram introduzidas por Chris Matts e Olav Maassen. Opções reais são o direito, mas não a obrigação, de tomar alguma ação antes do prazo final. As opções reais têm um preço, que é o custo da flexibilidade fornecida pela opção, mas também têm um valor, que é o benefício proporcionado pelo adiamento de uma decisão. Um exemplo típico é uma opção de cancelamento de reserva que concede ao comprador o direito de cancelar a reserva até um dia antes da chegada.
Uma apresentação no Real Options Agile Tour Brussels apresentou os benefícios esperados das opções:
Uma boa arquitetura cria opções para a equipe, a organização e o cliente. Criar e manter as opções é um trabalho diário e contínuo, realizado em pequenas etapas. Caso contrário, cria sistemas legados que contêm cada vez menos opções.
Em um contexto de desenvolvimento de software, os sistemas de experimentação que usam alternâncias de recursos permitem que os proprietários do produto adiem ou revertam a decisão de quando um determinado recurso ou código será exposto aos usuários.
Na última seção da palestra, Litvinsky se concentrou em técnicas de código para apoiar o adiamento de decisões. A primeira técnica mencionada é o Desenvolvimento Orientado a Testes, que é uma técnica de design e de teste. O TDD permite que os desenvolvedores adiem duas decisões, se a funcionalidade em teste terá ou não dependências e se é importante atrasar a implementação das dependências. Os spikes podem ser usados para solucionar um problema real, criar uma solução fácil e rápida para explorar o problema e decidir como continuar. Por fim, o padrão de monolito modular pode permitir adiar, até que seja necessário, a decisão de avançar em direção a uma arquitetura de microservices.
Como mencionado anteriormente, o adiamento de decisões tem um valor, mas também um custo. Adiar muito tempo pode eliminar alternativas que podem ter sido ótimas. Também pode afetar negativamente outras equipes, e facilitar a mudança significa necessariamente adicionar mais complexidade. Litvinsky concluiu assim que os desenvolvedores nunca deveriam se comprometer cedo, a menos que haja uma boa razão. Esforçar-se para criar opções que permitam adiar ou reverter decisões, enquanto avalia constantemente o custo do adiamento.