A keynote do DHH na RailsConf deste ano me causou uma boa impressão. Segundo ele, mesmo havendo muitas mudanças incorporadas ao código do Rails desde que o projeto foi iniciado há 6 anos, no geral não mudou muito.
Das vezes que pude assiti-lo falar, ele sempre deixou bem claro que o Rails “básico” é tudo o que ele realmente usa ou sabe a respeito. Nada supreendente, uma vez que ele escreveu o framework para seu próprio uso e exatamente da maneira como ele precisava que fosse.
Então veio um “core team” e estendeu a ferramenta. Legal. Agora temos pessoas cavando nas profundezas para melhorar sua performance, que será visto na versão 3 do Rails. Excelente!
Sua convenção sobre configuração nunca pretendeu agradar a todos ou servir a todas as situações. O Rails nunca será a bala de prata e eu realmente espero que permaneça desta maneira. Caso você precise mudar alguma coisa no comportamento do Rails, na maioria das vezes esta mudança é tão simples quanto escrever um plugin ou gem.
Toda a hype em torno de frameworks (do próprio Rails e outros ‘auxiliares’) que vemos hoje é muito mais do que vamos realmente precisar algum dia. O segredo que DHH fala sobre a alta produtividade não é nada relacionado a tecnologia. Mesmo tendo desenvolvido o Rails para aumentar sua produtividade, o seu real segredo é saber renegociar requisitos.
Se você está desenvolvendo software profissionalmente para a indústria e ainda utiliza a maneira hacker, nenhuma plataforma será produtiva o suficiente para você. Caso não haja comunicação envolvida no seu processo de desenvolvimento, você irá certamente falhar ou então gastar muito mais tempo para desenvolver algo que - a princípio - resolva o problema do seu cliente.
Cinco anos se passaram desde que o Rails foi lançado. Tudo o que ele oferece e mais todos os outros zilhões de frameworks de teste e gems são totalmente inúteis, a não ser que você preocupe-se com o que essencialmente precisa ser feito.
Seu cliente pode não saber o que ele quer, mas certamente sabe o que não quer.
Ele pode chegar para você e pedir algo que levará duas semanas para ser desenvolvido. Como um desenvolvedor profissional, cabe a você começar da onde ele quer e chegar aonde ele precisa. Talvez o resultado seja resolver problema do seu cliente com uma solução completamente diferente da que foi sugerida por ele, mas uma muito mais simples e que levará você muito menos tempo para desenvolver.
Como DHH falou, quando você quiser um chocolate, talvez um Twix que esteja no seu bolso seja tudo o que precise, ao invés de dirigir até o centro da cidade e gastar muito mais dinheiro com uma caixa de chocolates belgas.
