egoCheese, brian barbutti

O Gustavo Cardoso (@gustavocardoso) ficou impressionado quando mencionei no Twitter as 20 horas que levei no desenvolvimento do site Knork.net.

Fiquei de escrever para ele um pequeno case sobre como tentamos ser rápidos e eficazes na Entermotion e ao invés de um e-mail, acabei ficando com um post nas mãos.

---

Além das áreas comuns sobre a empresa e sua missão, o site possui uma loja virtual completa e um localizador de lojas de varejo. Mas antes de começar, um esclarecimento sobre o que chamamos de deployment na Entermotion.

Deployment: todo o processo que vem a partir do momento que o desenvolvedor recebe os mocks gráficos do designer/artista; ou seja: slicing de imagens, XHTML+CSS+JavaScript, planejamento e desenvolvimento server-side, instalação no servidor, etc.

Não usamos Rails

Usamos PHP ao invés de Rails. No passado, chegamos a discutir a possibilidade de mudar para Rails devido a todo o hype da linguagem, mas acabamos ficando com PHP; eu já tinha 4 anos de experiência com PHP e até obter esse tipo de fluidez com Rails, perderíamos bastante tempo.

Enquanto PHP é fácil de qualquer programador entender – já que é muito parecido com C – Rails é consideravelmente diferente. Toda a equipe teria que mudar de foco para que as coisas corressem suaves. Não nos pareceu viável na época e hoje eu vejo que fizemos a escolha certa.

Apesar de não ser programador de Rails, eu pesquisei bastante a linguagem e programei alguns testes para entende-la melhor. Percebi suas vantagens, mas achei que para as necessidades dos clientes da nossa empresa, poderíamos fazer algo mais simples, mais direto e mais versátil.

Decidimos então pegar os aspectos legais de Rails e transpor para uma framework própria (e simples) em PHP. O framework chama-se Haydn. Ele roda em algo inspirado em MVC – porém menos restrito e bem mais flexível –, scaffolding e algo próximo de routes. Claro que também vem built in com suporte simples a ajax. Com ele podemos fazer coisas muito legais em muito pouco tempo.

Pense módulos

O Haydn foi pensado desde o começo para ser bastante modularizável. Depois de uns 15 meses de vida, apareceu a primeira real necessidade de criar um módulo de e-commerce. Nós o desenvolvemos pensando exatamente em abstrair ao máximo todos os aspectos do sistema de e-commerce para que pudéssemos reutiliza-lo em projetos futuros.

Caso não tivéssemos esse módulo, a loja do Knork.net levaria sozinha bem mais de 20 horas para ser desenvolvida. Porém o tempo de desenvolvimento da seção levou infinitamente menos que isso, uma vez que todo o trabalho pesado já havia sido feito anteriormente.

Sempre que surge algum cliente com uma necessidade que percebemos que pode ser transformada em módulo e utilizada no futuro por outros projetos, nós modularizamos. Temos módulos para criar calendários gráficos, álbuns de fotos e muitos outros, sempre prezando pela simplicidade de desenvolvimento. Como os módulos são desenvolvidos por nós mesmos, nós próprios somos os especialistas – e os hacks para Haydn aparecem sempre que necessários. Não precisamos ir atrás de suporte, fórum ou qualquer outra coisa; é só conversarmos entre nós (muitas vezes nem isso é necessário).

Menos gente, menos overhead. E mais harmonia.

Para o deployment de um site, nós sempre tentamos manter apenas um desenvolvedor por projeto. O Jumpchart, por exemplo, foi inteiramente desenvolvido por mim. Isso acaba com vários overheads:

• Controle de versão;
• Alinhamento de idéias e approaches entre vários desenvolvedores e com o gerente de projetos;
• Gerenciamento mais rígido sobre a delegação e acompanhamento de tarefas;
• Etc.

Alterações com limites

Manter limites em alterações dos clientes é primordial. Quem trabalha em agência sabe como clientes podem complicar o mais simples dos trabalhos com pedidos infinitos de alterações. Não escrevemos documentos extremamente formais de specs, mas sempre mantemos os projetos organizados e transparentes o bastante desde a fase do planejamento para evitar mal entendidos no futuro e, principalmente, poder cobrar por alterações que julgamos sem muito sentido ou aquelas que aparecem por falta de atenção do cliente durante o planejamento. Claro que sempre ponderamos se o trabalho despendido pela alteração vale o incômodo junto ao cliente.