Ao longo de mais de três anos, o código de programação da boo-box já passou por muitas reformas, refactorings, reconstruções. Nossa experiência e lições aprendidas podem ajudar outras pessoas. Se você não é um programador, não se assuste 🙂 não serei demasiadamente técnico.
Protótipo funcional
O primeiro protótipo ficou no ar 1 mês e meio, foi feito por mim puramente em JavaScript. Era só uma demonstração funcional, usado em apenas um site (o site de demonstração) e era muito, muito lento. O protótipo foi testado pelo TechCrunch e aprovado com dois jóinhas.
- Programadores ninja: 1
- Tecnologias principais: JavaScript, API de e-commerce
- Sites usando: 1
- Pageviews mensais: até 50 mil
- Funções principais: Exibia numa lightbox (janela sobre o conteúdo) com produtos relacionados a uma imagem. Fazia uma busca em um e-commerce usando a tag (palavra-chave) da imagem.
Protótipo instalável
O segundo protótipo ficou no ar 3 meses, podia ser instalado em qualquer site que usasse páginas em HTML escrito por mim e por alguns amigos.
- Programadores ninja: 2
- Tecnologias principis: JavaScript, PHP, API de e-commerce
- Sites usando: até 50
- Pageviews mensais: até 100 mil
- Funções principais: Todas anteriores. Podia ser instalado em sites que usam HTML, como blogs e fórums.
Sistema PHP MVC
A partir daí fomos fazendo melhorias em partes críticas do código, principalmente visando performance. O sistema foi “surgindo”, deixando de ser “1 JS com 10.000 linhas + 1 PHP com 100 linhas” e criando corpo MVC (maneira robusta para estruturar uma aplicação).
- Programadores ninja: 3
- Tecnologias principis: JavaScript, PHP, MVC, API de e-commerce, MySQL
- Sites usando: até 600
- Pageviews mensais: até 400 mil
- Funções principais: Todas anteriores. Diferentes ferramentas para criação de links para exibição de anúncios. Contabilização de estatísticas básicas diárias.
Sledge
Um ano após esses primeiros refactorings, o sistema tinha robustez pro que estávamos fazendo até então, mas mudanças nas regras de negócio exigiam alterações profundas no que estava em produção. Havíamos descoberto boas linhas de receita em produtos diferentes do que nosso sistema estava preparado pra entregar, portanto, seria necessário modificá-lo profundamente.
Era perfeitamente possível continuar evoluindo e alterando o sistema PHP MVC que estava no ar, mas resolvemos começar do zero, em Ruby, por uma série de questões racionais e emocionais. Escolhemos o MERB pois o Rails na época estava no seu ápice da fama “Rails não escala”. Fizemos nosso novo sistema “from zero to production” em 4 meses. Deu certo. O núcleo do sistema ficou pronto no natal, por isso leva o nome de Sledge (trenó em inglês).
Seis meses após o Sledge entrar em produção, nossas novas regras de negócio se mostraram acertadas, o negócio começou a ganhar volume rapidamente (em pageviews, clientes e receita) e enfrentamos o desafio da escalabilidade. Trouxemos pra equipe Thyago Liberalli, um experiente diretor de tecnologia, e sob sua gestão um refactoring de 1 mês (2 sprints scrum) preparou o sistema pra escalabilidade exigida.
Atualmente o Sledge está preparado para suportar o grande volume de pageviews da nossa rede, que cresce 23% ao mês, e tem estrutura para as novas funcionalidades que crio na Área de Inovação, como a veiculação de anúncios em Twitter.
- Programadores ninja: 8
- Tecnologias principis: JavaScript, Ruby, MERB, API de e-commerce, MySQL, Redis, integração com ad servers
- Sites usando: mais de 9000
- Pageviews mensais: mais de 500 milhões
- Funções principais: Todas anteriores. Exibição de anúncios interativos em Flash. Pagamento de Publishers. Contabilização de estatísticas detalhadas em tempo real. Monetização de perfis de Twitter.
Percepção e agilidade
Antes da boo-box fiz o Wallpapr, um produto também puramente em JavaScript, praticamente não toquei nele após o lançamento (nunca foi meu foco de trabalho). Sem minha atenção, ele nunca evoluiu, está estagnado em 500 acessos diários faz 3 anos.
Uma das maiores lições que tiro dessa (resumida) história é que o negócio muda, muda muito, muda rápido. Você precisa ser muito ágil pra detectar o que o mercado quer comprar, ter culhões de jogar fora, completamente, “o código que funcionou até agora” e criar um novo.
Jogar código fora não é “perda”, as lições ficam, e o código funcionou bem até ser jogado fora, ele gerou valor – receita, pageviews, usuários, o que for -, mas você precisa ter humildade e sagacidade pra perceber que, dali pra frente, ele não vai mais funcionar. Precisa ser veloz e implementar novas soluções – confiáveis, robustas e escaláveis -, adaptadas ao momento do mercado em que está inserido.