[Campus code] Boas práticas em Rails
1 gostou1,008 visualizações
O documento apresenta boas práticas de desenvolvimento em Rails, incluindo design patterns, nomes de variáveis e organização de código. Ele enfatiza a importância de evitar comentários desnecessários, manter o código autoexplicativo, e adotar práticas de controle de falhas e consistência no banco de dados. Além disso, sugere o uso de ferramentas e recursos como helpers, i18n, e a importância de documentação para facilitar colaboração e implantação.
![Boas práticas de código
● Não deixe comentários do código explicando o que o método faz, prefira o
código auto explicativo
● Não largue códigos comentados, podemos usar o git para recuperar o que foi
apagado (GIT amigo =])
● Tenha sua aplicação sob controle de falhas, não se esqueça do begin rescue
(mas não “esconda” as exceptions”)
● Não usar GEMs para coisas simples pois pode dificultar um upgrade de
versão do Rails](https://image.slidesharecdn.com/campuscode-boasprticasrails-160121105821/85/Campus-code-Boas-praticas-em-Rails-3-320.jpg)
[Campus code] Boas práticas em Rails
- 1. Boas Práticas em Rails @fabioperrella - github.com/fabioperrella @cruzguilherm - github.com/guicruzzs
- 2. Boas práticas de código ● Design Patterns - O que são, e como podem nos ajudar? ● DRY, KISS (entre classes, inclusive) ● Arquivos, classes e métodos que representem exatamente aquilo que fazem ou são ● Não use abreviaturas, nem suprima as vogais de suas variáveis, métodos, classes… ● Dê preferência para nomes em inglês no seu código (talvez 100% de inglês)
- 3. Boas práticas de código ● Não deixe comentários do código explicando o que o método faz, prefira o código auto explicativo ● Não largue códigos comentados, podemos usar o git para recuperar o que foi apagado (GIT amigo =]) ● Tenha sua aplicação sob controle de falhas, não se esqueça do begin rescue (mas não “esconda” as exceptions”) ● Não usar GEMs para coisas simples pois pode dificultar um upgrade de versão do Rails
- 4. MVC ● Controllers sem lógica, só devem delegar, renderizar, redirect, etc ● Modelos com validações, relacionamentos, sem muita lógica ● Classes “puras” de serviço para tirar lógica dos modelos e controllers
- 5. Views ● Usar I18n para todos os textos utilizados nos modelos, controllers, views e JSs ● Helpers de HTML facilitam a vida ● Uso de presenters para tirar lógica das views ● Partials (DRY)
- 6. Banco de Dados ● Não editar migração que já foi enviada pro repositório, criar outra migração ● Utilizar Transactions em operações que podem gerar inconsistências. ● Evite apagar os registros do seu banco (pense na consistência dos dados e na investigação de um problema) ● Cuidado ao sobrescrever as querys do ActiveRecord (SQL injection) ● Não use SQLite nos testes e desenvolvimento, use o mesmo database que irá usar em produção se possível (já tive problemas com isso)
- 7. Rotas ● Usar resources, member e collection nas rotas ao invés de fazer a rota “na mão” ● Na dúvida, use o rake routes pra te mostrar as rotas do projeto (é mais uma dica do que boa prática)
- 8. Ambiente de Desenvolvimento ● Criar o arquivo .ruby-version na raiz do projeto para todos saberem qual a versão de ruby deve ser usada (usar RVM ou Rbenv) ● Crie uma rake do tipo devsetup para criar dados no banco que facilite subir o ambiente de dev rápido ● Escreva o README do seu projeto (instruções de instalação e uso), se alguém quiser colaborar com você, as dúvidas de setup precisam ter as respostas lá dentro.
- 9. Deploy ● Entenda como funciona o assets pipeline e use-o direito (com isso vai evitar problemas de cache nos deploys) ● Use o GOD (ou algo parecido) para monitorar os processos
- 10. E agora, José? ● Não se preocupem se não acertarem de primeira, consciência é o mais importante ● Você é responsável pelo que escreve ● Ler código de outras pessoas para aprender github.com (usem e abusem do que já foi feito) ● Acompanhar newsletter Ruby Weekly (rubyweekly.com) ● Escutar podcasts (ex: https://devchat.tv/ruby-rogues, grokpodcast.com) ● Ler livros técnicos (Practical Object-Oriented Design in Ruby, Clean Code, etc..)
- 11. E agora, José? Não parem, contínuo é o aprendizado!
- 12. Dúvidas?
- 13. Boas Práticas em Rails Fábio Perrella Guilherme Cruz Obrigado!!!