
Django adalah rangka kerja Python berasaskan sumber terbuka dan kuat untuk membina aplikasi web. Popularitinya meningkat sejak beberapa tahun kebelakangan ini, dan ia sudah matang dan banyak digunakan dengan komuniti besar di belakangnya.
Di antara kerangka kerja berasaskan Python lain untuk membuat aplikasi web (seperti Flask dan Pyramid), Django sejauh ini paling popular. Ia menyokong kedua-dua versi Python 2.7 dan Python 3.6. Tetapi pada masa artikel ini, Python 2.7 masih merupakan versi yang lebih mudah diakses dari segi komuniti, pakej pihak ketiga, dan dokumentasi dalam talian. Django selamat apabila digunakan dengan betul, dan memberikan dimensi fleksibiliti yang tinggi. Ini adalah cara untuk pergi ketika mengembangkan aplikasi sisi pelayan menggunakan Python.

Sebagai pembangun Python dan Django yang berpengalaman, saya akan berkongsi dengan anda beberapa amalan terbaik untuk penyediaan Django yang telah saya pelajari dan kumpulkan selama ini. Sama ada anda mempunyai beberapa projek Django, atau anda akan memulakan yang pertama dari awal, amalan terbaik yang dijelaskan di sini dapat membantu anda membuat aplikasi yang lebih baik di jalan.
Saya menulis artikel ini dari mindset yang sangat praktikal sehingga anda dapat menambahkan beberapa alat ke kotak alat pengembangan anda dengan segera. Anda bahkan boleh membuat papan pemuka Django lanjutan khusus untuk projek anda seterusnya.
Untuk tujuan artikel ini, saya menganggap anda menggunakan mesin Linux Ubuntu. Sepanjang artikel, beberapa baris kod bermula dengan $
tanda. Ini digunakan untuk menekankan bahawa garis ini harus dimasukkan ke terminal. Pastikan untuk menyalin garis tanpa yang $
tanda.
Persekitaran Maya
Semasa mengembangkan aplikasi berasaskan Python, menggunakan pakej pihak ketiga adalah perkara yang berterusan. Pakej-pakej ini sering dikemas kini, jadi menjaga mereka tetap teratur adalah penting. Semasa mengembangkan lebih banyak projek pada mesin tempatan yang sama, sangat sukar untuk mengikuti versi terkini setiap pakej. Tidak mungkin menggunakan versi yang berbeza dari pakej yang sama untuk projek yang berbeza. Lebih-lebih lagi, mengemas kini pakej pada satu projek boleh mematahkan fungsi yang lain, dan sebaliknya.
Di situlah Python Virtual Environment sangat berguna. Untuk memasang persekitaran persekitaran maya:
$ apt-get update $ apt-get install python-pip python-dev build-essential $ export LC_ALL="en_US.UTF-8" # might be necessary in case you get an error from the next line $ pip install --upgrade pip $ pip install --upgrade virtualenv $ mkdir ~/.virtualenvs $ pip install virtualenvwrapper $ export WORKON_HOME=~/.virtualenvs $ nano ~/.bashrc
Tambahkan baris ini ke hujung fail:
. /usr/local/bin/virtualenvwrapper.sh
Kemudian laksanakan:
$ . .bashrc
Setelah memasang, buat persekitaran maya baru untuk projek anda dengan menaip:
$ mkvirtualenv project_name
Semasa anda berada dalam konteks persekitaran maya, anda akan melihat awalan ditambahkan ke terminal, seperti:
(project_name) ofir@playground:~$
Untuk menyahaktifkan (keluar) persekitaran maya dan kembali ke konteks Python utama mesin tempatan anda, gunakan:
$ deactivate
Untuk mengaktifkan (memulakan) konteks persekitaran maya, gunakan:
$ workon project_name
Untuk menyenaraikan persekitaran maya yang ada di mesin tempatan anda, gunakan:
$ lsvirtualenv
Menyimpan kebergantungan projek anda (pakej) dalam persekitaran maya pada mesin anda membolehkan anda menyimpannya dalam persekitaran terpencil. Anda hanya menggunakannya untuk satu (atau beberapa) projek. Semasa membuat persekitaran maya baru, anda memulakan persekitaran baru tanpa pakej yang dipasang di dalamnya. Kemudian anda boleh menggunakan, sebagai contoh:
(project_name) $ pip install Django
untuk memasang Django di persekitaran maya anda, atau:
(project_name) $ pip install Django==1.11
untuk memasang Django versi 1.11 yang hanya dapat diakses dari dalam persekitaran.
Baik jurubahasa Python utama anda dan persekitaran maya lain di mesin anda tidak akan dapat mengakses pakej Django baru yang baru anda pasang.
Untuk menggunakan perintah runerver menggunakan persekitaran maya anda, sementara dalam konteks persekitaran maya, gunakan:
(project_name) $ cd /path/to/django/project (project_name) $ ./manage.py runserver
Begitu juga ketika memasuki jurubahasa Python dari dalam persekitaran maya, taip:
(project_name) $ python
Ini akan mempunyai akses ke pakej yang telah anda pasang di dalam persekitaran.

Keperluan
Keperluan adalah senarai pakej Python (kebergantungan) yang digunakan oleh projek anda semasa ia dijalankan, termasuk versi untuk setiap pakej. Berikut adalah contoh requirements.txt
fail:
dicttoxml==1.7.4 Django==1.11.2 h5py==2.7.0 matplotlib==2.0.2 numpy==1.13.0 Pillow==4.1.1 psycopg2==2.7.1 pyparsing==2.2.0 python-dateutil==2.6.0 pytz==2017.2 six==1.10.0 xmltodict==0.11.0
Mengemas kini requirements.txt
fail anda sangat mustahak untuk berkolaborasi dengan betul dengan pembangun lain. Ini juga penting untuk memastikan persekitaran pengeluaran anda dikonfigurasi dengan betul. Fail ini, apabila disertakan dalam repositori kod anda, membolehkan anda mengemas kini semua pakej yang dipasang di persekitaran maya anda dengan menjalankan satu baris di terminal. Maka anda boleh membuat pembangun baru dan beroperasi dalam masa yang singkat.
Untuk menghasilkan yang baru requirements.txt
atau untuk mengemas kini yang sudah ada, gunakan dari dalam persekitaran maya anda:
(project_name) $ pip freeze > requirements.txt
Untuk kemudahan anda, pastikan untuk melaksanakan perintah ini dalam folder yang dilacak oleh repositori Git anda. Ini membolehkan contoh kod lain mempunyai akses ke requirements.txt
fail juga.
Sekiranya pembangun baru bergabung dengan pasukan, atau jika anda ingin mengkonfigurasi persekitaran baru menggunakan pakej yang sama yang disenaraikan dalam requirements.txt
fail, jalankan dalam konteks persekitaran maya:
(project_name) $ cd /path/to/requirements/file (project_name) $ pip install -r requirements.txt
Semua keperluan yang disenaraikan dalam fail akan segera dipasang di persekitaran maya anda. Versi lama akan dikemas kini dan versi yang lebih baru akan diturunkan tarafnya agar sesuai dengan senarai yang tepat requirements.txt
. Berhati-hatilah - mungkin ada perbezaan antara persekitaran yang masih ingin anda hormati.
I highly recommend integrating these commands to your work flow. Update the requirements.txt file before pushing code to the repository and install requirements.txt file after pulling code from the repository.

Better settings.py
configuration
Django comes out-of-the-box with a very basic yet useful settings.py
file. This defines the main and most useful configurations for your project. The settings.py
file is very straightforward. But sometimes, as a developer working on a team, or when setting up a production environment, you need more than one basic settings.py
file.
Multiple settings files allow you to easily define tailor-made configurations for each environment separately like:
ALLOWED_HOSTS # for production environment DEBUG DATABASES # for different developers on the same team
Let me introduce you to an extended approach for configuring your settings.py
file. It allows you to maintain different versions and use the one you want at any given time and in any environment.
First, navigate to your settings.py
file path:
(project_name) $ cd /path/to/settings/file
Then create a new module called settings (module is a folder containing an __init__.py
file):
(project_name) $ mkdir settings
Now, rename your settings.py
file to base.py and place it inside the new module you created:
(project_name) $ mv settings.py settings/base.py
For this example, I assume that you want to configure one settings file for your development environment and one for your production environment. Different developers on the same team can use the exact same approach for defining different settings files.
For your development environment create:
(project_name) $ nano settings/development.py
Then type:
from .base import * DEBUG = True
and save the file by hitting Ctrl + O
, Enter and then Ctrl + X
.
For your production environment create:
(project_name) $ nano settings/production.py
and type:
from .base import * DEBUG = False ALLOWED_HOSTS = [‘app.project_name.com’, ]
Now, whenever you want to add or update the settings of a specific environment, you can easily do it in its own settings file.
You might be wondering — how does Django know which settings file to load on each environment? That’s what the __init__.py
file is used for. When Django looks for the settings.py
it used to load when running the server, for example, it now finds a settings module rather than a settings.py
file. But as long as it’s a module containing an __init__.py
file, as far as Django is concerned, it’s the exact same thing. Django will load the __init__.py
file and execute whatever is written in it.
Therefore, we need to define which settings file we want to load inside the __init__.py
file by executing:
(project_name) $ settings/__init__.py
and then, for a production environment, for example, by typing:
from .production import *
This way, Django will load all the base.py and production.py settings every time it starts. Magic?
Now, the only configuration left is to keep the __init__.py
in your .gitignore
file so it will not be included in pushes and pulls. Once you set up a new environment, don’t forget to create a new __init__.py
file inside the settings module. Then import the settings file required exactly like we did before.
In this article we’ve covered three best practices for better setting up your Django project:
- Working inside a virtual environment
- Keeping the
requirements.txt
file up to date and using it continuously in your work flow - Setting up a better project settings array
Have you followed these best practices in your last project? Do you have any insights to share? Comments are highly appreciated.
Did you find this useful? If so, please give me some claps so more people see the article.
This is part 1 in the series about best practices for Django development. Follow me to get an immediate update once the next parts are available.
Find more great tips for technological entrepreneurs at CodingStartups.