10 Kesalahan Teratas yang Dilakukan Pengembang Django

Dalam tutorial ini, kita akan melihat beberapa kesalahan umum yang sering dilakukan oleh pengembang Django dan cara untuk menghindarinya. Tutorial ini berguna bahkan jika Anda seorang pengembang Django yang ahli karena kesalahan, seperti mempertahankan pengaturan besar yang tidak dapat diatur atau konflik penamaan dalam aset statis, tidak hanya terbatas pada pengembang baru yang mengambil kesempatan pertama mereka di Django.

Django adalah kerangka kerja web Python sumber terbuka dan gratis yang membantu memecahkan tantangan pengembangan umum dan memungkinkan Anda membangun aplikasi yang fleksibel dan terstruktur dengan baik. Django memiliki banyak fitur modern di luar kotak. Bagi saya pribadi, fitur Admin, Object Relational Mapping tool (ORM), Routing, dan Templateing menjadikan Django pilihan pertama saya karena aplikasi membutuhkan banyak pekerjaan dan, sementara saya menikmati pekerjaan saya sebanyak yang bisa dilakukan oleh pengembang mana pun, saya ingin menghabiskan waktu sesedikit mungkin untuk tugas-tugas dasar yang berulang ini. Django memungkinkan Anda untuk melakukan semua ini tanpa mengorbankan fleksibilitas.

Fitur pembunuh Django adalah antarmuka admin yang dapat dikonfigurasi dan kuat yang dibangun secara otomatis (secara otomatis?) dari skema model Anda dan model panel admin, membuat Anda merasa seperti seorang penyihir. Melalui antarmuka Admin, pengguna dapat mengonfigurasi banyak hal termasuk daftar kontrol akses (ACL), izin dan tindakan tingkat baris, filter, pesanan, widget, formulir, pembantu URL tambahan, dan apa pun yang dapat Anda bayangkan. Saya yakin setiap aplikasi memerlukan panel admin—jika belum, hanya masalah waktu sampai aplikasi dasar Anda membutuhkannya. Dengan admin Django, Anda dapat membuatnya dengan cepat dan fleksibel.

Django memiliki ORM yang kuat yang bekerja dengan semua basis data utama di luar kotak. Karena malas, ia menyentuh database Anda hanya saat Anda membutuhkannya, tidak seperti ORM lainnya. Ini mendukung semua instruksi SQL utama (dan fungsi) yang dapat Anda gunakan dari kode sumber Python Anda dan terasa sangat nyaman karena fitur Python.

Mesin templating Django sangat fleksibel dan bertenaga pada saat yang bersamaan. Anda dapat menggunakan banyak filter dan tag standar serta membuat filter dan tag kustom baru untuk proyek Anda. Django mendukung mesin templat lain serta templat Django, dan itu menyediakan API untuk integrasi yang mudah dari mesin templat lain melalui fungsi pintasan standar untuk pemrosesan templat.

Django memiliki banyak fitur besar lainnya seperti perute URL yang dapat mengurai permintaan masuk dan membangun URL baru dari skema perute. Secara keseluruhan, kerangka kerja Django adalah pengalaman yang menyenangkan dan kapanpun Anda membutuhkan bantuan, baca saja dokumentasinya.

Kesalahan No. 1: Menggunakan Lingkungan Python Sistem Global untuk Ketergantungan Proyek

Jangan gunakan lingkungan global Python untuk dependensi proyek, karena dapat menghasilkan konflik dependensi. Python tidak dapat menggunakan beberapa versi paket secara bersamaan. Ini bisa menjadi masalah jika proyek yang berbeda memerlukan versi berbeda yang tidak kompatibel dari paket yang sama.

Kesalahan ini biasanya dibuat oleh pengembang Python dan Django baru yang tidak tahu tentang fitur isolasi lingkungan Python.

Ada banyak cara untuk mengisolasi lingkungan Anda, tetapi cara yang paling umum adalah:

• virtualenv: Paket Python yang menghasilkan folder lingkungan Python dan memiliki skrip untuk [menonaktifkan] lingkungan dan mengelola paket Python yang diinstal di lingkungan. Ini adalah metode favorit saya karena ini adalah cara paling sederhana untuk melakukan pekerjaan itu. Biasanya, saya membuat lingkungan yang dekat dengan folder proyek.
• virtualenvwrapper: Paket Python yang diinstal secara global dan menyediakan perangkat untuk membuat/menghapus/mengaktifkan/dll. lingkungan maya. Semua lingkungan virtual disimpan dalam satu folder (yang dapat diganti melalui variabel lingkungan WORKON_HOME). Saya tidak melihat keuntungan menggunakan virtualenvwrapper daripada virtualenv .
• Mesin Virtual (VM): Tidak ada isolasi yang lebih besar daripada seluruh mesin virtual yang didedikasikan untuk aplikasi Anda. Ada banyak alat untuk dipilih, termasuk VirtualBox (gratis), VMware, Parallels, dan Proxmox (favorit pribadi saya, dan memiliki versi gratis). Dikombinasikan dengan alat otomatisasi VM seperti Vagrant, ini bisa menjadi solusi yang sangat kuat.
• Kontainer: Dalam beberapa tahun terakhir, saya telah menggunakan Docker di hampir setiap proyek, terutama di setiap proyek baru yang saya mulai dari awal. Docker adalah alat luar biasa yang menyediakan banyak fitur dan memiliki banyak alat pihak ketiga untuk otomatisasi kontainer. Ini memiliki fitur caching lapisan yang membuat membangun kembali wadah Anda sangat cepat. Dalam wadah, saya menggunakan lingkungan Python sistem global, karena setiap wadah memiliki sistem file sendiri dan proyek diisolasi pada tingkat tinggi. Docker memungkinkan anggota tim baru untuk mulai mengerjakan proyek lebih cepat, terutama jika mereka memiliki pengalaman Docker.

Jika Anda bertanya kepada saya, saya lebih suka paket virtualenv Python dan wadah Docker untuk isolasi dan manajemen ketergantungan proyek.

Kesalahan No. 2: Tidak Menyematkan Dependensi Proyek di File requirements.txt

Setiap proyek Python baru harus dimulai dengan file requirements.txt dan lingkungan baru yang terisolasi. Biasanya Anda menginstal semua paket melalui pip/easy_install tetapi jangan pernah lupa untuk menambahkannya ke file requirements.txt Anda juga. Ini membuatnya lebih mudah ( mungkin lebih tepat) untuk menyebarkan proyek Anda di server, atau bagi anggota tim untuk mem-bootstrap proyek di mesin mereka sendiri.

Selain itu, sama pentingnya untuk menyematkan versi spesifik dependensi Anda di file requirements.txt Anda. Biasanya, versi paket yang berbeda menyediakan modul, fungsi, dan parameter fungsi yang berbeda; bahkan perubahan versi kecil dalam ketergantungan dapat merusak paket Anda. Ini adalah masalah yang sangat serius jika proyek Anda aktif dan Anda memiliki penerapan yang dijadwalkan secara teratur karena, tanpa pembuatan versi, sistem pembangunan Anda akan selalu menginstal versi terbaru dari paket yang tersedia.

Selalu sematkan paket Anda untuk produksi! Secara pribadi, saya menggunakan alat yang sangat bagus yang disebut pip-tools yang membantu saya melakukan ini. Ini menyediakan seperangkat alat baris perintah yang membantu mengelola dependensi Anda. Secara otomatis menghasilkan requirements.txt yang menyematkan bukan hanya dependensi Anda tetapi seluruh pohon dependensi Anda, yang mencakup dependensi dependensi Anda.

Kadang-kadang, Anda ingin memperbarui hanya beberapa paket dari daftar dependensi Anda (misalnya, hanya Django/Flask/kerangka kerja atau utilitas apa pun), jika Anda menggunakan "pip freeze" Anda tidak tahu dependensi mana untuk paket mana, jadi Anda tidak dapat meningkatkan ketergantungan. Namun, dengan pip-tools, ia secara otomatis menyematkan paket tergantung pada ketergantungan mana yang Anda sematkan, sehingga secara otomatis menyelesaikan paket mana yang perlu diperbarui. Sebagai bonus, Anda juga tahu persis paket mana yang berasal dari ketergantungan mana karena cara menandainya dengan komentar di file requirements.txt .

Untuk ekstra hati-hati, sebaiknya buat cadangan file sumber ketergantungan Anda juga! Simpan salinan di sistem file Anda, folder yang dikelola Git, folder S3, FTP, SFTP—di mana pun, tetapi siapkan. Ada contoh di mana paket yang relatif kecil yang tidak terdaftar memecahkan sejumlah besar paket di npm. Pip membantu menyediakan alat untuk mengunduh semua dependensi yang diperlukan sebagai file sumber, baca lebih lanjut dengan menjalankan pip help download .

Kesalahan No. 3: Menggunakan Fungsi Python Gaya Lama Alih-alih Tampilan Berbasis Kelas

Terkadang ada baiknya menggunakan fungsi Python kecil dalam file views.py aplikasi terutama untuk pengujian atau tampilan utilitas, tetapi umumnya, Anda harus menggunakan tampilan berbasis kelas (CBV) dalam aplikasi Anda.

CBV adalah tampilan umum yang menyediakan kelas abstrak yang mengimplementasikan tugas pengembangan web umum yang dibuat oleh para profesional dan mencakup semua perilaku umum. Mereka memiliki API terstruktur yang luar biasa, dan Anda dapat menggunakan semua keuntungan dari pemrograman berorientasi objek saat Anda menggunakan CBV. Itu membuat kode sumber Anda lebih jelas dan mudah dibaca. Lupakan kesulitan menggunakan fungsi tampilan standar Django untuk daftar, operasi CRUD, pemrosesan formulir, dll. Anda hanya perlu memperluas CBV yang sesuai untuk tampilan Anda dan menimpa properti atau fungsi kelas (biasanya sebuah fungsi mengembalikan properti dan Anda dapat menambahkan logika apa pun di sana membuat spageti dari kode sumber Anda jika menggunakan fungsi tampilan alih-alih CBV) yang mengonfigurasi perilaku tampilan.

Misalnya, Anda dapat memiliki campuran yang berbeda dalam proyek Anda yang menimpa perilaku CBV dasar untuk membangun konteks tampilan, memeriksa otorisasi pada tingkat baris, jalur template pembuatan otomatis dari struktur aplikasi Anda, mengintegrasikan caching cerdas, dan banyak lagi.

Saya membangun paket bernama Django Template Names, yang menstandardisasi nama template untuk tampilan Anda berdasarkan nama aplikasi dan nama kelas tampilan. Saya menggunakannya setiap hari dan menghemat banyak waktu saya untuk menemukan nama. Cukup masukkan mixin di CBV Anda— class Detail(TemplateNames, DetailView): —dan itu akan mulai berfungsi! Tentu saja, Anda dapat mengganti fungsi saya dan menambahkan templat responsif seluler, templat berbeda untuk agen pengguna, atau apa pun yang Anda inginkan.

Kesalahan No. 4: Menulis Tampilan Gemuk dan Model Kurus

Menulis logika aplikasi Anda dalam tampilan alih-alih model berarti Anda telah menulis kode yang termasuk dalam model Anda ke dalam tampilan, menjadikannya "gemuk" dan model Anda "kurus".

Anda harus menulis model gemuk, pandangan kurus.

Pecah logika menjadi metode kecil pada model Anda. Ini memungkinkan Anda menggunakannya beberapa kali dari berbagai sumber (UI antarmuka admin, UI front-end, titik akhir API, beberapa tampilan) dalam beberapa baris kode alih-alih menyalin-menempelkan banyak kode. Jadi lain kali Anda mengirim email kepada pengguna, perluas model dengan fungsi email alih-alih menulis logika ini di pengontrol Anda.

Ini juga membuat kode Anda lebih mudah untuk diuji unit karena Anda dapat menguji logika email di satu tempat, daripada berulang kali di setiap pengontrol tempat ini dilakukan.

Anda dapat membaca lebih lanjut tentang masalah dalam proyek Praktik Terbaik Django. Solusinya sederhana: Tulis model gemuk dan tampilan kurus, jadi mari kita lakukan di proyek Anda berikutnya (atau perbaiki proyek Anda saat ini).

Kesalahan No. 5: File Pengaturan Besar yang Tidak Dapat Dikelola

Bahkan file pengaturan proyek Django baru memiliki banyak pengaturan. Dalam proyek nyata, file pengaturan bertambah hingga 700+ baris konfigurasi dan akan menjadi sulit untuk dipelihara, terutama ketika lingkungan pengembangan, produksi, dan pementasan Anda semuanya memerlukan konfigurasi khusus.

Anda dapat membagi file konfigurasi secara manual dan membuat pemuat khusus, tetapi saya ingin memperkenalkan Anda pada paket Python yang bagus dan teruji dengan baik, Pengaturan Split Django, yang telah saya tulis bersama.

Paket ini menyediakan dua fungsi— optional dan include —yang mendukung wildcard untuk jalur dan mengimpor file konfigurasi Anda dalam konteks yang sama, membuatnya mudah untuk membangun konfigurasi Anda menggunakan entri konfigurasi yang dideklarasikan dalam file yang dimuat sebelumnya. Itu tidak mempengaruhi kinerja Django dan Anda dapat menggunakannya dalam proyek apapun.

Lihat contoh konfigurasi minimal:

 from split_settings.tools import optional, include include( 'components/base.py', 'components/database.py', 'components/*.py', # the project different envs settings optional('envs/devel/*.py'), optional('envs/production/*.py'), optional('envs/staging/*.py'), # for any local settings optional('local_settings.py'), )

Kesalahan No. 6: Aplikasi All-in-one, Struktur Aplikasi Buruk, dan Penempatan Sumber Daya Salah

Setiap proyek Django terdiri dari beberapa aplikasi. Dalam notasi Django, aplikasi adalah paket Python yang berisi setidaknya file __init__.py dan models.py ; dalam versi Django terbaru, models.py tidak lagi diperlukan. __init__.py sudah cukup.

Aplikasi Django dapat berisi modul Python, modul khusus Django (tampilan, URL, model, admin, formulir, tag templat, dll), file statis, templat, migrasi basis data, perintah manajemen, pengujian unit, dan banyak lagi. Anda harus membagi aplikasi monolit menjadi aplikasi kecil yang dapat digunakan kembali menggunakan logika sederhana. Anda harus dapat menjelaskan seluruh tujuan aplikasi dalam satu atau dua kalimat pendek. Misalnya: “Memungkinkan pengguna untuk mendaftar dan mengaktifkan akun mereka melalui email.”

Sebaiknya panggil project folder project dan tempatkan aplikasi di project/apps/ . Kemudian, tempatkan semua dependensi aplikasi ke dalam subfoldernya sendiri.

Contoh:

• File statis: project/apps/appname/static/appname/
• Tag template: project/apps/appname/templatetags/appname.py
• File template: project/apps/appname/templates/appname/

Selalu awali nama aplikasi di subfolder karena semua folder statis digabungkan menjadi satu folder dan, jika dua atau lebih aplikasi memiliki file js/core.js , aplikasi terakhir di settings.INSTALLED_APPLICATIONS akan menimpa yang sebelumnya. Saya pernah memiliki bug ini di proyek saya saat ini dan kehilangan sekitar enam jam debugging sampai saya menyadari pengembang lain telah mengganti static/admin/js/core.js karena tim menerapkan panel admin SPA khusus dan menamai file mereka dengan cara yang sama.

Berikut adalah contoh struktur untuk aplikasi portal yang memiliki banyak sumber daya dan modul Python.

 root@c5b96c395cfb:/test# tree project/apps/portal/ project/apps/portal/ ├── __init__.py ├── admin.py ├── apps.py ├── management │ ├── __init__.py │ └── commands │ ├── __init__.py │ └── update_portal_feeds.py ├── migrations │ └── __init__.py ├── models.py ├── static │ └── portal │ ├── css │ ├── img │ └── js ├── templates │ └── portal │ └── index.html ├── templatetags │ ├── __init__.py │ └── portal.py ├── tests.py ├── urls.py └── views.py 11 directories, 14 files

Dengan menggunakan struktur seperti itu, Anda dapat setiap saat mengekspor aplikasi ke paket Python lain dan menggunakannya lagi. Anda bahkan dapat mempublikasikannya di PyPi sebagai paket open source, atau memindahkannya ke folder lain.

Anda akan mendapatkan struktur proyek seperti ini:

 root@c5b96c395cfb:/test# tree -L 3 . ├── deploy │ ├── chef │ └── docker │ ├── devel │ └── production ├── docs ├── logs ├── manage.py ├── media ├── project │ ├── __init__.py │ ├── apps │ │ ├── auth │ │ ├── blog │ │ ├── faq │ │ ├── pages │ │ ├── portal │ │ └── users │ ├── conf │ ├── settings.py │ ├── static │ ├── templates │ ├── urls.py │ └── wsgi.py └── static └── admin ├── css ├── fonts ├── img └── js 25 directories, 5 files

Dalam proyek nyata, tentu saja, itu akan lebih kompleks, tetapi struktur ini membuat segalanya lebih sederhana dan lebih bersih.

Kesalahan No. 7: STATICFILES_DIRS dan STATIC_ROOT Membingungkan Pengembang Django Pemula

File statis adalah aset yang tidak berubah melalui penggunaan aplikasi, misalnya JavaScript, CSS, gambar, font, dll. Di Django, mereka hanya "dikumpulkan" ke dalam direktori publik selama proses penerapan.

Dalam mode pengembangan— python manage.py runserver —Django mencari file statis menggunakan pengaturan STATICFILES_FINDERS . Secara default, ia mencoba menemukan file statis yang diminta di folder yang terdaftar di pengaturan STATICFILES_DIRS . Dalam kasus kegagalan, Django mencoba menemukan file menggunakan django.contrib.staticfiles.finders.AppDirectoriesFinder , yang terlihat dalam folder static dari setiap aplikasi yang diinstal dalam proyek. Ini memungkinkan Anda menulis aplikasi yang dapat digunakan kembali yang dikirimkan dengan file statisnya sendiri.

Dalam produksi, Anda melayani statis Anda menggunakan server web mandiri seperti Nginx. Server web tidak tahu apa-apa tentang struktur aplikasi proyek Django atau folder mana file statis Anda didistribusikan. Untungnya, Django menyediakan Anda dengan perintah pengelolaan statis python manage.py collectstatic , yang berjalan melalui STATICFILES_FINDERS dan menyalin semua file statis dari aplikasi static folder dan folder yang terdaftar di STATICFILES_DIRS ke dalam direktori yang Anda tentukan dalam pengaturan STATIC_ROOT . Ini memungkinkan resolusi sumber daya file statis menggunakan logika yang sama seperti server mode pengembangan Django dan memiliki semua file statis di satu tempat untuk server web Anda.

Jangan lupa untuk menjalankan collectstatic di lingkungan produksi Anda!

Kesalahan No. 8: STATICFILES_STORAGE Default, Pemuat Template Django dalam Produksi

STATICFILES_STORAGE

Mari kita bicara tentang manajemen aset lingkungan produksi. Kami dapat memberikan pengalaman pengguna terbaik jika kami menggunakan kebijakan "aset tidak pernah kedaluwarsa" (yang dapat Anda baca selengkapnya di sini). Ini berarti bahwa semua file statis kami harus di-cache oleh browser web selama berminggu-minggu, berbulan-bulan, atau bahkan bertahun-tahun. Dengan kata lain, pengguna Anda harus mengunduh aset Anda hanya sekali!

Itu keren, dan kita bisa melakukannya dengan beberapa baris dalam konfigurasi Nginx untuk folder file statis kita, tapi bagaimana dengan pembatalan cache? Jika pengguna hanya akan mengunduh aset kami sekali, apa yang terjadi jika Anda memperbarui logo, font, JavaScript, atau warna teks untuk item dalam menu? Untuk melewati ini, Anda harus membuat URL dan nama file unik untuk file statis kami di setiap penerapan!

Kita dapat melakukannya hanya dengan menggunakan ManifestStaticFilesStorage sebagai STATICFILES_STORAGE (hati-hati, hashing hanya diaktifkan dalam mode DEBUG=false ) dan menjalankan perintah manajemen collectstatic yang dibahas di atas. Ini akan mengurangi jumlah permintaan aset ke situs web produksi Anda dan akan membuat situs web Anda dirender lebih cepat.

Pemuat Template Django yang Di-cache

Fitur Django keren lainnya adalah pemuat template yang di-cache, yang tidak memuat ulang dan mem-parsing file template pada setiap render template. Penguraian template adalah operasi yang sangat mahal dan menggunakan banyak sumber daya. Secara default, templat Django diurai pada setiap permintaan, tetapi ini buruk, terutama selama produksi, di mana Anda dapat memproses ribuan permintaan dalam rentang waktu yang singkat.

Lihat bagian konfigurasi cached.Loader untuk contoh yang baik dan detail tentang cara melakukan ini. Jangan gunakan pemuat dalam mode pengembangan karena tidak memuat ulang templat yang telah diurai dari sistem file; Anda harus memulai ulang proyek Anda menggunakan python manage.py startapp pada setiap perubahan template. Ini dapat mengganggu selama pengembangan, tetapi ini sempurna untuk lingkungan produksi.

Kesalahan No. 9: Skrip Python Murni untuk Utilitas atau Skrip

Django menyediakan fitur yang sangat bagus yang disebut Perintah Manajemen. Gunakan saja alih-alih menciptakan kembali roda dan menulis skrip Python mentah untuk utilitas proyek Anda.

Juga, periksa paket Ekstensi Django, yang merupakan kumpulan ekstensi khusus untuk Django. Mungkin seseorang telah menerapkan perintah Anda! Sudah ada banyak sekali perintah tugas umum.

Kesalahan No. 10: Menemukan Kembali Roda

Django dan Python memiliki ribuan solusi siap pakai. Coba Googling sebelum Anda menulis sesuatu yang tidak unik; mungkin ada solusi kaya fitur yang sudah ada.

Hanya mencoba untuk membuat hal-hal sederhana. Google dulu! Instal, konfigurasikan, perluas, dan integrasikan ke dalam proyek Anda jika Anda menemukan paket berkualitas baik, dan tentu saja, berkontribusi pada open source ketika Anda memiliki kesempatan.

Untuk memulainya, inilah daftar paket publik saya sendiri untuk Django:

• URL Makro Django memudahkan untuk menulis (dan membaca) pola URL dalam aplikasi Django Anda dengan menggunakan makro.
• Django Templates Names adalah campuran kecil yang memungkinkan Anda untuk dengan mudah menstandardisasi nama template CBV Anda.
• Django-split-settings memungkinkan Anda mengatur pengaturan Django ke dalam beberapa file dan direktori. Ganti dan ubah pengaturan dengan mudah. Gunakan wildcard di jalur file pengaturan dan tandai file pengaturan sebagai opsional.

Jangan Ulangi Diri Sendiri (KERING)!

Saya sangat menyukai metodologi DRY; itulah mengapa saya membuat kerangka Django sebagai alat praktis yang memiliki beberapa fitur yang sangat rapi di luar kotak:

• Gambar Docker untuk pengembangan/produksi, dikelola oleh docker-compose, yang memungkinkan Anda mengatur daftar container dengan mudah.
• Skrip Fabric sederhana untuk penyebaran produksi.
• Konfigurasi untuk paket Django Split Settings dengan pengaturan untuk basis dan sumber lokal.
• Webpack terintegrasi ke dalam proyek - Hanya folder dist yang akan dikumpulkan oleh Django pada perintah collectstatic .
• Mengonfigurasi semua pengaturan dan fitur Django dasar seperti templat Django yang dapat di-cache dalam produksi, file statis hash, bilah alat debug terintegrasi, pencatatan log, dll.

Ini adalah Kerangka Django yang siap digunakan untuk proyek Anda berikutnya dari awal dan, semoga, menghemat banyak waktu Anda dengan mem-bootstrap proyek Anda. Webpack memiliki konfigurasi dasar minimal, tetapi juga memiliki SASS yang telah diinstal sebelumnya untuk menangani file .scss .