Provavelmente você já deve ter ouvido muitas vezes que a solução para algum sistema, cuja manutenção tenha se tornado um grande problema, é jogar toda a base de código no lixo e reescrever tudo de novo, repensando e reformulando sua arquitetura.
Martin Fowler escreveu recentemente sobre isso em seu blog, num post intitulado “Sacrificial Architecture” (Arquitetura do Sacrifício). Ele diz que, apesar das pessoas pensarem que jogar todo o código no lixo para reescrever tudo de novo seja uma falha, isso pode ser um movimento natural do ciclo do software.
“…the best code you can write now is code you’ll discard in a couple of years time.”
Dessa forma, ele sugere pensar em uma data de expiração para a arquitetura e a base de código e cita como exemplo o caso do eBay. De 1995 a 1997 o eBay começou com um punhado de scripts Perl, a partir de 1997 essa base de código foi substituída por C++ e, finalmente, em 2002, tudo foi reescrito em Java. O importante a entender nessa abordagem é que a arquitetura correta para suportar o negócio em 1996 é diferente da arquitetura para suportar o negócio em 2006.
“Ebay is one of the great successes of the web so far, but much of that success was built on the discarded software of the 90’s. Like many successful websites, ebay has seen exponential growth – and exponential growth isn’t kind to architectural decisions. The right architecture to support 1996-ebay isn’t going to be the right architecture for 2006-ebay. The 1996 one won’t handle 2006’s load but the 2006 version is too complex to build, maintain, and evolve for the needs of 1996.”
No Google, por exemplo, há uma regra explícita para projetar sistemas de acordo com as necessidades correntes, tornando comum o redesenho de subsistemas em poucos anos.
Então, a sugestão é aceitar agora que, em poucos anos, o código atual irá mudar. Uma forma de tornar isso mais fácil é dar grande importância à modularidade, de forma que as mudanças aconteçam em termos de módulos e não do sistema por completo de uma vez só.
“Good modularity is a vital part of a healthy code base, and modularity is usually a big help when replacing a system. Indeed one of the best things to do with an early version of a system is to explore what the best modular structure should be so that you can build on that knowledge for the replacement. While it can be reasonable to sacrifice an entire system in its early days, as a system grows it’s more effective to sacrifice individual modules – which you can only do if you have good module boundaries.”
Mas toda vez que pegarmos código alheio devemos reconstruir tudo? Definitivamente não. Quem constrói o sistema é quem deve pensar em uma data de expiração para as mudanças, é preciso definir um processo de reconstrução também, pois é muito fácil odiar código alheio e querer reconstruir tudo da noite para o dia. Uma das principais dicas é entender o contexto em que o sistema foi desenvolvido, o contexto atual e chegar a conclusão se a solução atual está adequada ao contexto para o qual foi projetada e para o qual está sendo usada atualmente.