O poder do Python

Quem não está acostumado a trabalhar com Django pode estranhar o fato deste utilizar um script Python para fazer a configuração do projeto: o famoso settings.py. E essa estranheza é justificada, afinal muitos desenvolvedores — principalmente os que vêm de outras linguagens — estão acostumados a trabalhar com ferramentas onde tal tarefa é feita com arquivos XML ou coisa assim.

O fato é que utilizar um script Python para tal é uma excelente idéia, pois você deixa de depender de algum tipo de estrutura estática (e muitas vezes inconveniente) para algo mais flexível e poderoso, que, no caso, é a própria linguagem de programação. Isso faz uma grande diferença em situações onde tal flexibilidade é necessária.

Quer exemplos?

Ambientes de desenvolvimento/produção

Eis como fizemos aqui. Primeiramente, defina a variável de ambiente WORKSPACE. No Linux, isso pode ser feito através do arquivo ~/.bashrc:

export WORKSPACE=1

A idéia é possibilitar a criação de perfis de configuração, cada qual correspondente a um ambiente de execução. A existência ou não da variável de ambiente é o que define o ambiente no qual a aplicação roda.

Continuando com o exemplo, no diretório raíz do seu projeto Django, crie o módulo environment.py, com o seguinte conteúdo:

import os
 
def production_mode():
    return not development_mode()
 
def development_mode():
    return 'WORKSPACE' in os.environ

Finalmente, modifique o módulo settings.py para que este utilize tais métodos onde for necessário definir configurações diferentes para ambientes de execução diferentes:

from environment import production_mode
 
# Configurações padrão
PREPEND_WWW = False
DEBUG = True
 
# Configurações para ambiente de produção
if production_mode():
    PREPEND_WWW = True
    DEBUG = False
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'pages.middleware.PageFallbackMiddleware',
    'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
)
 
# Habilitando caching em modo de produção
if production_mode():
    MIDDLEWARE_CLASSES += (
        'django.middleware.cache.UpdateCacheMiddleware',
        'django.middleware.cache.FetchFromCacheMiddleware',
    )

Não tenha medo de utilizar os recursos do Python onde eles se fizerem necessários, apenas tomando cuidado para não exagerar e acabar criando acidentalmente um Algoritmo Genético para configurar seu projeto!

Informações secretas (IPs, usernames, passwords, etc)

Praticamente não há quem ignore a importância de um bom sistema de controle de revisões (Subversion, Git, etc). O problema é que, muitas vezes, não tomamos o devido cuidado com o que colocamos dentro dos nossos repositórios. Sempre que possível, informações secretas — como endereços de IP, usernames e passwords — devem ser mantidas fora dos repositórios.

Em um projeto Django, as informações de acesso a servidores de e-mail e bancos de dados devem estar disponíveis através do módulo  settings.py. Felizmente, existe um jeito simples de manter essas informações separadas das outras configurações.

Primeiramente, abra o arquivo settings.py do seu projeto e remova todas as senhas e outras informações que você considere secretas. Em seguida, cole o seguinte trecho de código no final do arquivo:

try:
    from private import *
except ImportError:
    pass

Feito isso, crie o módulo private.py no diretório raíz do seu projeto Django. Coloque nele as configurações que você removeu do settings.py no passo anterior. Exemplo:

from environment import production_mode
 
SECRET_KEY = 'secret_key_do_seu_projeto'
 
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = 'senha_email_local'
 
DATABASE_HOST = 'localhost'
DATABASE_USER = 'username_db_local'
DATABASE_PASSWORD = 'senha_db_local'
 
if production_mode():
    EMAIL_HOST = 'ip_email_producao'
    EMAIL_HOST_PASSWORD = 'senha_email_producao'
 
    DATABASE_HOST = 'ip_db_producao'
    DATABSE_USER = 'username_db_producao'
    DATABASE_PASSWORD = 'senha_db_producao'

Certifique-se de adicionar o arquivo private.py no ignore (.cvsignore para CVS, .gitignore para Git, etc) correspondente ao sistema de controle de revisões sendo utilizado. Faça o commit e pronto.

Para finalizar, se o seu repositório já contém uma versão “insegura” do módulo settings.py, mude as senhas dos seus servidores.

E você, o que recomenda?

Tem alguma dica útil para compartilhar conosco? Nós adoraríamos ouvir o que você tem a dizer!

Modelo-exemplo de banco de dados

Nem irei perder tempo explicando esse modelo, até porque não há nada nele que precise de explicações. Bem, na verdade, há uma coisa sim: por que raios existe uma tabela só para armazenar os tipos de contato?! Qual é o problema com os bons e velhos códigos fixos (1-email, 2-celular, N-…)?

Um argumento a favor dessa abordagem é que “o usuário pode querer cadastrar um contato cujo tipo não seja suportado pela aplicação”. Mas será mesmo que colocar essa informação no banco de dados resolve o problema? E, mais importante, existe algum efeito colateral?

Bem, na minha experiência, embora essa abordagem pareça boa o bastante para resolver a questão num sistema simples de “cadastro”, a bomba explode quando o sistema passa a depender dessas flags para a realização de lógicas de negócio que vão além do famigerado CRUD.

Anti-pattern?

E se eu te dissesse que usar tabelas no banco de dados para armazenar flags é um anti-pattern? Digo isso pois, como veremos a seguir, as vantagens são irrisórias frente às desvantagens:

Poluição do modelo de dados. Um sistema não muito grande provavelmente conta com mais de uma centena de tabelas. Isso todo mundo sabe. O que todo mundo também sabe, mas parece ignorar, é que não seria surpreendente constatar que 10-15% dessas tabelas serviriam apenas para armazenar flags (situação de pedido, estado civil, forma de pagamento, e por aí vai). E o pior: essas tabelas, quase sempre, possuem exatamente a mesma estrutura, que apelidei carinhosamente de tabelas código-descrição. A tabela TipoContato, mostrada no diagrama que encabeça este texto, é um exemplo desse tipo de tabela.

Ruim para o meio ambiente. Poluir o modelo de dados com dezenas de tabelas código-descrição torna o modelo desnecessariamente maior e mais difícil de compreender. Imprimir um modelo desses consome mais papel, o que é ruim numa época onde o desenvolvimento sustentável está em voga. Quantas árvores suas tabelas código-descrição já derrubaram?

Ultra-normalização. Quanto mais tabelas uma consulta envolver, mais joins, e mais dados indo e vindo para o banco de dados. E, considerando que o banco de dados é (quase) sempre o gargalo, isso não é muito bom para a performance do seu sistema.

Poluição do modelo de objetos. As linguagens com suporte à orientação a objetos figuram entre as mais usadas atualmente, por isso eu diria que muito provavelmente você utiliza esse paradigma no desenvolvimento dos seus sistemas. Se este for o caso, também é bem provável que você utilize algum framework ORM para facilitar a tarefa de integração do software com o banco de dados. Como muitos frameworks ORM exigem um modelo de objetos compatível com o modelo de dados, bem, você acaba sendo forçado a poluir seu modelo de objetos com classes burras que apelidei carinhosamente de (pasmem!) classes código-descrição.

Se tem tabela, tem cadastro. Bom, já que todas as flags possuem suas tabelinhas no banco de dados, isso significa que você, pobre desenvolvedor, terá que fazer “cadastros” para todas elas (e reze para não precisar fazer relatórios, também). Além da chatisse costumeira de se fazer um cadastro, devemos levar em consideração que fazê-los consome tempo e, tempo é dinheiro.

Código quebradiço. Essa é feia. Vamos supor que, nessa nossa aplicação de gerenciamento de clientes/contatos, você queira incluir uma funcionalidade que permita enviar um torpedo ao cliente caso ele possua um contato do tipo Celular. Como mostrado no trecho de código a seguir, você fatalmente terá que incluir no código-fonte referências a registros armazenados no banco de dados, tornando o código quebradiço. Consequentemente, um único UPDATE ou DELETE executado por engano no banco de dados pode fazer o sistema cair de joelhos.

Enviando torpedos a um cliente:

public void enviarTorpedo(Cliente cliente, String texto) {
    // Tenta localizar um contato do tipo celular
    for (Contato contato : cliente.getContatos()) {
         // WTF!! Estamos referenciando um registro do banco de dados!!
         if (contato.getCodigo() == 10L) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

A solução

Com certeza existem outros problemas que eu acabei deixando passar, mas espero que os problemas que listei já sejam o suficiente para te convencer que guardar flags em tabelas no banco de dados é uma má idéia.

Mas, como resolver isso então? Simples: use enums sempre que possível. A única desvantagem é que os usuários não poderão mais sair criando novas flags a torto e a direito, o que não é realmente um problema frente às vantagens que as enums oferecem.

Poluição do modelo de dados? As flags virariam campos numéricos ou alfanuméricos nas tabelas que as usam e o framework ORM se encarregaria de converter esses campos de/para objetos enum. Diga adeus às tabelas código-descrição.

Ruim para o meio-ambiente? Sem as tabelas código-descrição, seu modelo fica menor, mais enxuto, facilitando a visualização e gastando menos papel ao imprimí-lo. A natureza agradece.

Ultra-normalização? Usando enums você diminui a quantidade de ligações entre as tabelas, tornando as entidades um pouco mais auto-contidas. Menos tabelas, menos joins, mais performance.

Poluição do modelo de objetos? As enums tomariam o lugar das classes código-descrição, o que por si só tornaria o código mais claro, pois, ao contrário das classes “normais”, as enums possuem um propósito bem definido.

Se tem tabela, tem cadastro? Ué, por que você está com esse sorriso estampado no rosto?

Código quebradiço? Quem mais se beneficia das enums são os trechos de código onde as lógicas de negócio são definidas. Mais especificamente, seu código deixa de referenciar registros do banco de dados, eliminando a fragilidade e melhorando a legibilidade. As enums também impedem que valores arbitrários sejam usados em atribuições e comparações, tornando o código ainda mais confiável. Um exemplo disso pode ser visto no código a seguir, que é uma adaptação da atrocidade do código mostrado anteriormente:

public void enviarTorpedo(Cliente cliente, String texto) {
    for (Contato contato : cliente.getContatos()) {
         // Bem melhor agora!
         if (contato.getTipo() == TipoContato.CELULAR) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

O fato de a sua linguagem do coração não ter suporte nativo a enums não deve ser um impedimento para que você deixe de usufruir de suas vantagens. Existem formas de se conseguir uma funcionalidade semelhante sem muito esforço.

Conclusão

Desenvolver software é, antes de tudo, fazer escolhas. É o custo/benefício, os prós e contras antes de se tomar uma decisão. A boa notícia é que o nosso produto, o software, é maleável o suficiente para permitir que decisões ruins sejam re-feitas sempre que elas resultam em problemas como o descrito neste texto.

Bom carnaval!