Boas práticas de django
Upcoming SlideShare
Loading in...5
×
 

Boas práticas de django

on

  • 1,771 views

Desenvolver um projeto não se trata apenas de escrever código funcional. Legibilidade, modularização, acoplamento, portabilidade, complexidade e documentação são todas métricas ...

Desenvolver um projeto não se trata apenas de escrever código funcional. Legibilidade, modularização, acoplamento, portabilidade, complexidade e documentação são todas métricas importantíssimas para se produzir código de qualidade. Respondendo perguntas como:

Como organizar os arquivos no projeto?
Quais bibliotecas podem ajudar a tormar sua aplicação mais robusta e melhorar seu código?
Como organizar seu ambiente de desenvolvimento, staging e produção?
O que são boas e más práticas de desenvolvimento?
vamos debater como e quais ferramentas e padrões podem nos ajudar a desenvolver código de qualidade, sem que seja preciso muito esforço.

Statistics

Views

Total Views
1,771
Views on SlideShare
1,771
Embed Views
0

Actions

Likes
9
Downloads
56
Comments
3

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • @collopy Valeu a correção! Vou apresentar essa palestra na Python Brasil e ai logo depois subo as correções!

    Sobre o settings, se colocar o import no init, as configurações locais vão ser sempre carregadas. A idéia aqui é realmente ter configurações isoladas que serão carregadas cada uma em seu devido ambiente. No slide 22 deixei como padrão o settings local pra facilitar durante o desenvolvimento. No ambiente de produção, o ideal é que você configure a variável de ambiente: DJANGO_SETTINGS_MODULE='my_project.settings.production'. Dessa forma, só as configurações de produção são carregadas então não tem perigo de carregar indevidamente alguma configuração local.
    Are you sure you want to
    Your message goes here
    Processing…
  • Oi Filipe, nesse slide 24, acho que o run server é junto.
    Are you sure you want to
    Your message goes here
    Processing…
  • Oi Filipe, nesse slide 18, não poderia ter um arquivo settings/__init__.py com um from local import *?
    To curtindo a apresentação =)
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Boas práticas de django Boas práticas de django Presentation Transcript

  • Filipe Ximenes Boas práticas de Django
  • Filipe Ximenes •Fundador da Vinta; •Desenvolvedor Web; •Apaixonado por aprender; •Fã de comunidades de Sofware Livre; •Curioso de empreendedorismo.
  • Boas práticas de Django
  • Boas práticas Boas práticas de programação são um conjunto de regras informais que a comunidade de desenvolvimento de software tem aprendido ao longo do tempo para melhorar a qualidade das aplicações e simplificar sua manutenção.
  • Boas práticas deDjango
  • Django Django é o framework web para perfeccionistas com prazos.
  • • Não é mágica; • Não é difícil; • Não requer mais do que conhecer Django.
  • • Requer vontade; • Requer prática; • Os resultados são sensíveis.
  • 1. Mantenha seu ambiente de trabalho limpo e isolado de outros projetos
  • Virtualenv pip install virtualenv virtualenv .venv source .venv/bin/activate http://www.virtualenv.org/
  • Virtualenvwrapper pip install virtualenvwrapper export WORKON_HOME=~/.virtualenvs mkdir -p $WORKON_HOME echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bash_profile mkvirtualenv my_project workon my_project deactivate http://virtualenvwrapper.readthedocs.org/
  • 2. Deixe claro o que é configuração de desenvolvimento e o que é configuração de produção
  • Settings my_project/ setting.py local_settings.py.example Como a muitos fazem: Assim fica mais claro: my_project/ settings/ base.py local.py production.py
  • settings/local.py & settings/production.py from .base import *
  • Guardar settings em variável de ambiente? • Não deixa explicito as configurações que estão sendo usadas; • Só o criador do projeto vai saber configurar os ambientes de desenvolvimento e produção; • Novos desenvolvedores devem ser capazes de rodar o projeto pela primeira vez sem dificuldades.
  • 3. Facilite a sua vida e a de quem está iniciando no projeto
  • manage.py & wsgi.py os.environ.setdefault( "DJANGO_SETTINGS_MODULE", "my_project.settings.local" )
  • Em produção export DJANGO_SETTINGS_MODULE= “my_project.settings.production”
  • Nem sempre tudo pode ficar explicito, pelo menos grite quando houver algo errado def get_env_variable(var_name): try: return os.environ.get(var_name) except: error_msg = "Defina a variável de ambiente %s" % var_name raise ImproperlyConfigured(error_msg) VARIAVEL = get_env_variable('VARIAVEL') settings/production.py
  • Makefile clean: find . -name "*.pyc" -delete deps: pip install -r requirements/local.txt setup: clean deps rm -rf my_db_name.db python manage.py syncdb --noinput python manage.py migrate python manage.py createsuperuser --email "test@myproject.com" run: python manage.py runserver
  • README.md #Meu Projeto Este é um projeto exemplo para falar sobre boas práticas de Django ##Instalação Para rodar o projeto localmente você precisa apenas executar o comando: ``` make setup ```
  • 4. Sempre que puder, crie novos apps
  • Apps • Não é fácil separar de separar depois que estão em produção juntos; • Quando grandes são complicados de manter; • Tente isolar o máximo possível, e reduzir dependências.
  • Onde colocar código que não pertence a nenhum app específico? • Crie um app 'core' na sua aplicação para comportar esta situação.
  • Correto
  • Errado
  • 5. Não ignore o User do Django
  • User do Django • Facilidade; • Compatibilidade: • Com o Django; • Com apps de terceiros.
  • AbstractUser AbstractBaseUser •Adicione novos campos: •Adicione e remova campos: https://docs.djangoproject.com/en/dev/topics/auth/customizing/ #extending-django-s-default-user http://catherinetenajeros.blogspot.com.br/2013/03/django-15- subclass-abstractbaseuser.html
  • 6. Use signals [com cautela]
  • models.py class MyUser(...): ... from .signals import *
  • signals.py from django.db.models.signals import pre_save from django.dispatch import receiver from django.core.mail import send_mail from .models import MyUser @receiver(pre_save, sender=MyUser) def send_email(sender, instance, **kwargs): if not instance.pk: send_mail(...)
  • Todo superuser é staff class MyUser(...): ... is_staff = models.BooleanField(…) is_supperuser = models.BooleanField(…) ... def save(self, *args, **kwargs): if self.is_supperuser: self.is_staff = True super(MyUser, self).save(*args, **kwargs)
  • Quando usar? • Enviar email é uma ação secundária, não impacta no comportamento do model; • Exigir que todo superuser seja staff impacta no comportamento do model.
  • 7. Sobrescreva o ModelManager
  • É onde devem ficar as suas queries from django.db import models class ManagerUtil(models.Manager): def get_or_none(self, **kwargs): try: return self.get(**kwargs) except ObjectDoesNotExist: return None managers.py
  • 8. Não repita-se (don't repeat yourself)
  • Templates <htlm> <head> <title>Home</title> ... <head> <header> ... </header> <div> ... </div> <footer> ... </footer> </html> home.html
  • Templates <htlm> <head> <title>Contato</title> ... <head> <header> ... </header> <div> ... </div> <footer> ... </footer> </html> contato.html
  • Templates Blocks <htlm> <head> <title> {% block title %}My Project{% endblock %} </title> ... <head> <header> ... </header> <div> {% block content %} {% endblock %} </div> <footer> ... </footer> </html> base.html
  • Templates Blocks {% extends 'base.html' %} {% block title %}Home{% endblock %} {% block content %} ... {% endblock %} home.html {% extends 'base.html' %} {% block title %}Contato{% endblock %} {% block content %} ... {% endblock %} contato.html
  • Mixins class MeuUser(...): ... is_deleted = models.BooleanField(default=False) ... def delete(self): self.is_deleted = True self.save() class OutroModel(...): ... is_deleted = models.BooleanField(default=False) ... def delete(self): self.is_deleted = True self.save()
  • Mixins class SoftDeleteMixin(models.Model): class Meta: abstract = True is_deleted = models.BooleanField( default=False) def delete(self): self.is_deleted = True self.save()
  • Mixins class MeuUser(SoftDeleteMixin): ... class OutroModel(SoftDeleteMixin): ...
  • 9. Teste TUDO
  • Um arquivo de teste para cada arquivo do app app/ tests/ test_models.py test_managers.py test_views.py https://github.com/jezdez/django-discover-runner
  • Model Mommy # para instalar pip install model_mommy # No seu arquivo de testes kid = mommy.make('family.Kid') https://github.com/vandersonmota/model_mommy
  • 1. Mantenha seu ambiente de trabalho limpo e isolado de outros projetos; 2. Deixe claro o que é configuração de desenvolvimento e o que é configuração de produção; 3. Facilite a sua vida e a de quem está iniciando no projeto; 4. Sempre que puder, crie novos apps; 5. Não ignore o User do Django.
  • 6. Use signals [com cautela]; 7. Sobrescreva o ModelManager; 8. Não repita-se (don't repeat yourself); 9. Teste TUDO.
  • ? github.com/filipeximenes bitbucket.org/filipeximenes filipeximenes@gmail.com twitter.com/xima