O documento apresenta boas práticas para o desenvolvimento em Django, incluindo a importância de manter um ambiente de trabalho organizado, definir claramente as configurações de desenvolvimento e produção, e criar novos aplicativos quando possível. Também discute a utilização de usuários do Django, o uso cauteloso de sinais, e a integração de testes para garantir a qualidade do código. Por fim, salienta a necessidade de não repetir código e de sobrescrever o model manager para melhorar a eficiência do desenvolvimento.

1. Filipe Ximenes
Boas práticas de
Django

2. Filipe Ximenes
•Fundador da Vinta;
•Desenvolvedor Web;
•Apaixonado por aprender;
•Fã de comunidades de Sofware Livre;
•Curioso de empreendedorismo.

3. Boas práticas
de Django

4. 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.

5. Boas práticas
deDjango

6. Django
Django é o framework web para
perfeccionistas com prazos.

7. • Não é mágica;
• Não é difícil;
• Não requer mais do que conhecer
Django.

8. • Requer vontade;
• Requer prática;
• Os resultados são sensíveis.

9. 1. Mantenha seu ambiente de trabalho
limpo e isolado de outros projetos

10. Virtualenv
pip install virtualenv
virtualenv .venv
source .venv/bin/activate
http://www.virtualenv.org/

11. 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/

12. 2. Deixe claro o que é configuração de
desenvolvimento e o que é
configuração de produção

13. 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

14. settings/local.py & settings/production.py
from .base import *

15. 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.

16. 3. Facilite a sua vida e a de quem está
iniciando no projeto

17. manage.py & wsgi.py
os.environ.setdefault(
"DJANGO_SETTINGS_MODULE",
"my_project.settings.local"
)

18. Em produção
export
DJANGO_SETTINGS_MODULE=
“my_project.settings.production”

19. 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

20. 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

21. 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
```

22. 4. Sempre que puder, crie novos apps

23. 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.

24. 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.

25. Correto

26. Errado

27. 5. Não ignore o User do Django

28. User do Django
• Facilidade;
• Compatibilidade:
• Com o Django;
• Com apps de terceiros.

29. 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

30. 6. Use signals [com cautela]

31. models.py
class MyUser(...):
...
from .signals import *

32. 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(...)

33. 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)

34. 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.

35. 7. Sobrescreva o ModelManager

36. É 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

37. 8. Não repita-se (don't repeat yourself)

38. Templates
<htlm>
<head>
<title>Home</title>
...
<head>
<header>
...
</header>
<div>
...
</div>
<footer>
...
</footer>
</html>
home.html

39. Templates
<htlm>
<head>
<title>Contato</title>
...
<head>
<header>
...
</header>
<div>
...
</div>
<footer>
...
</footer>
</html>
contato.html

40. Templates Blocks
<htlm>
<head>
<title>
{% block title %}My Project{% endblock %}
</title>
...
<head>
<header>
...
</header>
<div>
{% block content %}
{% endblock %}
</div>
<footer>
...
</footer>
</html>
base.html

41. 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

42. 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()

43. Mixins
class SoftDeleteMixin(models.Model):
class Meta:
abstract = True
is_deleted = models.BooleanField(
default=False)
def delete(self):
self.is_deleted = True
self.save()

44. Mixins
class MeuUser(SoftDeleteMixin):
...
class OutroModel(SoftDeleteMixin):
...

45. 9. Teste TUDO

46. 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

47. Model Mommy
# para instalar
pip install model_mommy
# No seu arquivo de testes
kid = mommy.make('family.Kid')
https://github.com/vandersonmota/model_mommy

48. 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.

49. 6. Use signals [com cautela];
7. Sobrescreva o ModelManager;
8. Não repita-se (don't repeat yourself);
9. Teste TUDO.

50. ?
github.com/filipeximenes
bitbucket.org/filipeximenes
filipeximenes@gmail.com
twitter.com/xima