As equipes de desenvolvimento de software preferem ter uma arquitetura de longa vida nos softwares, mas a rápida evolução das tendências em hardware, software e velocidade de redes, demanda uma grande mudança na arquitetura ou jogar fora toda a base de código. No mesmo contexto, Martin Fowler, autor e consultor na Thoughtworks, adicionou recentemente um post no seu blog sobre a Arquitetura do Sacrifício.
Arquitetura do Sacrifício significa aceitar agora que daqui a poucos anos a equipe terá que jogar fora o que está sendo desenvolvido atualmente. Fowler mencionou que isso significa pensar agora sobre as coisas que podem tornar mais fácil a substituição quando chegar a hora, mas os criadores de software raramente pensam sobre como projetar sua criação para apoiar a sua substituição.
Para muitas pessoas, jogar fora a base de código é um sinal de falha, possivelmente compreensível, dada a natureza exploratória inerente de desenvolvimento de software, mas mesmo assim uma falha. Mas frequentemente o melhor código que se pode escrever é o código que será descartado em alguns anos.
Fowler deu um exemplo correspondente a Arquitetura do Sacrifício do eBay que ao longo de um período de tempo mudaram dos scripts Perl, para código C++, para código Java. A arquitetura correta para suportar em 1996 não vai ser a arquitetura correta em 2006. Aquele de 1996 não vai lidar com a carga de 2006, mas a versão 2006 é muito complexa para construir, manter e evoluir para as necessidades de 1996.
Dmitry Cheryasov, desenvolvedor na EPAM Systems também endossa a Arquitetura do Sacrifício devido às mudanças que o negócio necessita. E compartilhou sua visão em uma discussão na Y Combinator como:
Construa com a intenção de reconstruir, quando a hora chegar. É como jogar fora protótipos, só que em produção. Quando seu negócio cresce, pode ser necessário jogar fora parte ou toda a base de código (como o eBay fez, duas vezes). Isso não significa que a solução anterior era ruim: não ao todo, eles foram adequados em uma etapa anterior.
Jeff Dean, pesquisador sênior na Google, mencionou em sua apresentação sobre redesenhar ou jogar fora o código antes que fique muito velho.
O design certo em X pode não ser muito errado a 10X ou 100X ou para ~10X maior, mas se planeje para reescrever antes dos ~100X.
Fowler diz que no período inicial do sistema de software há menos certeza de que o software realmente precisa fazer, então é importante colocar mais foco na flexibilidade para mudar funcionalidades ao invés de desempenho ou disponibilidade. Jeff Atwood, cofundador do Stack Overflow e Stack Exchange Network, cunhou a frase "desempenho é uma funcionalidade". Portanto a equipe pode priorizar o desempenho com respeito às outras funcionalidades. Inicialmente, essa não tem alta prioridade, mas no estágio futuro do desenvolvimento essa prioridade pode aumentar.
Fowler afirma que a Arquitetura do Sacrifício não conduz a falta de qualidade. Para uma base de código saudável, a modularidade é a chave.
Boa modularidade é uma parte vital para uma base de código saudável, e modularidade é geralmente de grande ajuda quando se substitui um sistema. De fato uma das melhores coisas a fazer com uma versão inicial de um sistema é explorar o que a melhor estrutura modular deve ser para que se possa aproveitar esse conhecimento para a substituição. Embora possa ser razoável sacrificar todo um sistema em seus primeiros dias, assim como um sistema cresce é mais efetivo sacrificar módulos individuais - o que só é possível fazer se o módulo tiver bons limites.
Justin Meyer, consultor jQuery e coautor de JavaScriptMVC, CanJS e jQueryPP, compartilhou a importância da modularidade recentemente no seu blog como:
Modularidade é a característica mais importante de um aplicativo sustentável. Um aplicativo modular não é um desperdício, pois partes podem ser mudadas, substituídas ou descartadas sem afetar o resto da aplicação.
Fowler acredita também que a equipe que escreve a Arquitetura do Sacrifício é a equipe que decide o tempo do sacrifício, e isso é bom para saber sobre o código que será sacrificado no futuro.
Para você até quando vale a pena sustentar o legado? Até não ter mais membros da equipe que trabalhem no projeto ou é considerado que depois de 3, 5 ou 10 anos o sistema já não atende mais as espectativas e está na hora de ir além.