ในบทช่วยสอนนี้เราจะดูข้อผิดพลาดทั่วไปที่มักเกิดขึ้นโดยนักพัฒนา Django และวิธีหลีกเลี่ยง บทช่วยสอนนี้มีประโยชน์แม้ว่าคุณจะเป็นนักพัฒนา Django ที่เชี่ยวชาญเนื่องจากข้อผิดพลาดเช่นการรักษาการตั้งค่าขนาดใหญ่ที่ไม่สามารถจัดการได้หรือความขัดแย้งในการตั้งชื่อในเนื้อหาแบบคงที่ไม่ได้ จำกัด เพียงแค่นักพัฒนาใหม่ที่เริ่มแทง Django เป็นครั้งแรก

Django เป็นเว็บเฟรมเวิร์ก Python แบบโอเพนซอร์สฟรีที่ช่วยแก้ปัญหาความท้าทายในการพัฒนาทั่วไปและช่วยให้คุณสร้างแอปพลิเคชันที่ยืดหยุ่นและมีโครงสร้างที่ดี Django มีคุณสมบัติที่ทันสมัยมากมายนอกกรอบ สำหรับฉันโดยส่วนตัวแล้วคุณสมบัติ Admin, Object Relational Mapping (ORM), Routing และ Templating ทำให้ Django เป็นตัวเลือกแรกของฉันเนื่องจากแอปพลิเคชันต้องการงานจำนวนมากและในขณะที่ฉันสนุกกับงานให้มากที่สุดเท่าที่นักพัฒนาจะทำได้ แต่ฉันก็ต้องการใช้จ่าย ใช้เวลาน้อยที่สุดในการทำงานซ้ำ ๆ ขั้นพื้นฐานเหล่านี้ Django ช่วยให้คุณทำทั้งหมดนี้ได้โดยไม่สูญเสียความยืดหยุ่น

คุณลักษณะนักฆ่าของ Django คืออินเทอร์เฟซผู้ดูแลระบบที่กำหนดค่าได้อย่างมีประสิทธิภาพซึ่งสร้างโดยอัตโนมัติ (โดยอัตโนมัติ?) จากสคีมาของโมเดลและโมเดลแผงผู้ดูแลระบบทำให้คุณรู้สึกเหมือนเป็นตัวช่วย ผ่านอินเทอร์เฟซผู้ดูแลระบบผู้ใช้สามารถกำหนดค่าสิ่งต่างๆมากมายรวมถึงรายการควบคุมการเข้าถึง (ACL) สิทธิ์ระดับแถวและการดำเนินการตัวกรองคำสั่งวิดเจ็ตแบบฟอร์มตัวช่วย URL เพิ่มเติมและสิ่งอื่น ๆ ที่คุณสามารถจินตนาการได้ ฉันเชื่อว่าทุกแอปพลิเคชันต้องมีแผงผู้ดูแลระบบหากยังไม่มีก็ต้องใช้เวลาจนกว่าแอปพลิเคชันพื้นฐานของคุณจะต้องใช้ ด้วยผู้ดูแลระบบ Django คุณสามารถสร้างได้อย่างรวดเร็วและยืดหยุ่น

Django มี ORM ที่ทรงพลังซึ่งทำงานร่วมกับฐานข้อมูลหลักทั้งหมดได้ทันที เนื่องจากมันขี้เกียจจึงเข้าถึงฐานข้อมูลของคุณเมื่อคุณต้องการเท่านั้นซึ่งแตกต่างจาก ORM อื่น ๆ รองรับคำสั่ง SQL ที่สำคัญทั้งหมด (และฟังก์ชัน) ซึ่งคุณสามารถใช้ได้จากซอร์สโค้ด Python ของคุณและรู้สึกสะดวกสบายมากเนื่องจากคุณสมบัติของ Python

เครื่องมือสร้างเทมเพลตของ Django มีความยืดหยุ่นและทรงพลังมากในเวลาเดียวกัน คุณสามารถใช้มาตรฐานได้มาก ตัวกรองและแท็ก รวมทั้งสร้างตัวกรองและแท็กที่กำหนดเองใหม่สำหรับโครงการของคุณ Django รองรับเอนจิ้นเทมเพลตอื่น ๆ รวมถึงเทมเพลต Django และมี API สำหรับการรวมเอ็นจินแม่แบบอื่น ๆ อย่างง่ายดายผ่านฟังก์ชันทางลัดมาตรฐานสำหรับการประมวลผลเทมเพลต

Django มีคุณสมบัติขนาดใหญ่อื่น ๆ อีกมากมายเช่นเราเตอร์ URL ที่สามารถแยกวิเคราะห์คำขอที่เข้ามาและสร้าง URL ใหม่จากสคีมาของเราเตอร์ โดยรวมแล้วเฟรมเวิร์ก Django เป็นประสบการณ์ที่น่าพึงพอใจและเมื่อใดก็ตามที่คุณต้องการความช่วยเหลือเพียงอ่านไฟล์ เอกสารประกอบ .

ข้อผิดพลาดที่ 1: การใช้ Global System Python Environment สำหรับการพึ่งพาโครงการ

อย่าใช้สภาพแวดล้อมทั่วโลกของ Python สำหรับการอ้างอิงโปรเจ็กต์เนื่องจากอาจทำให้เกิดความขัดแย้งในการพึ่งพา Python ใช้แพ็กเกจหลายเวอร์ชันพร้อมกันไม่ได้ ซึ่งอาจเป็นปัญหาได้หากโปรเจ็กต์ต่าง ๆ ต้องการแพ็กเกจเดียวกันเวอร์ชันที่เข้ากันไม่ได้

ข้อผิดพลาดนี้มักเกิดขึ้นโดยนักพัฒนา Python และ Django รายใหม่ที่ไม่ทราบเกี่ยวกับคุณลักษณะการแยกสภาพแวดล้อมของ Python

มีหลายวิธีในการแยกสภาพแวดล้อมของคุณ แต่วิธีที่พบบ่อยที่สุด ได้แก่ :

• Virtualenv : แพ็คเกจ Python ที่สร้างโฟลเดอร์สภาพแวดล้อม Python และมีสคริปต์สำหรับ [de] เปิดใช้งานสภาพแวดล้อมและจัดการแพ็คเกจ Python ที่ติดตั้งในสภาพแวดล้อม นี่เป็นวิธีที่ฉันชอบเพราะเป็นวิธีที่ง่ายที่สุดในการทำงาน โดยปกติฉันจะสร้างสภาพแวดล้อมใกล้กับโฟลเดอร์โครงการ
• คุณธรรม : แพ็คเกจ Python ที่ติดตั้งทั่วโลกและมีชุดเครื่องมือสำหรับสร้าง / ลบ / เปิดใช้งาน / etc สภาพแวดล้อมเสมือนจริง สภาพแวดล้อมเสมือนทั้งหมดถูกเก็บไว้ในโฟลเดอร์เดียว (ซึ่งสามารถแทนที่ผ่านตัวแปรสภาพแวดล้อม WORKON_HOME) ฉันไม่เห็นข้อดีของการใช้ virtualenvwrapper แทน virtualenv.
• เครื่องเสมือน (VM): ไม่มีการแยกออกจากกันมากไปกว่าเครื่องเสมือนทั้งหมดที่ทุ่มเทให้กับแอปพลิเคชันของคุณ มีเครื่องมือมากมายให้เลือกรวมถึง VirtualBox (ฟรี), VMware , แนวร่วม และ Proxmox (รายการโปรดส่วนตัวของฉันและมีเวอร์ชันฟรี) รวมกับเครื่องมือ VM อัตโนมัติเช่น คนจรจัด นี่อาจเป็นวิธีแก้ปัญหาที่ทรงพลังอย่างยิ่ง
• ภาชนะ: ในช่วงไม่กี่ปีที่ผ่านมาฉันใช้ นักเทียบท่า ในเกือบทุกโครงการโดยเฉพาะอย่างยิ่งในทุกโครงการใหม่ที่ฉันเริ่มต้นใหม่ Docker เป็นเครื่องมือที่น่าทึ่งที่ให้คุณสมบัติมากมายและมีเครื่องมือของบุคคลที่สามมากมายสำหรับการทำงานของคอนเทนเนอร์อัตโนมัติ มีคุณสมบัติการแคชเลเยอร์ซึ่งทำให้การสร้างคอนเทนเนอร์ของคุณใหม่เร็วมาก ในคอนเทนเนอร์ฉันใช้สภาพแวดล้อม Python ของระบบส่วนกลางเนื่องจากทุกคอนเทนเนอร์มีระบบไฟล์ของตัวเองและโปรเจ็กต์จะแยกกันอยู่ในระดับสูง Docker ช่วยให้สมาชิกในทีมใหม่เริ่มทำงานในโปรเจ็กต์ได้เร็วขึ้นโดยเฉพาะอย่างยิ่งหากพวกเขามีประสบการณ์ Docker

ถ้าคุณถามฉันฉันชอบ virtualenv แพ็คเกจ Python และคอนเทนเนอร์ Docker สำหรับการแยกและการจัดการการพึ่งพาโครงการ

ข้อผิดพลาดที่ 2: ไม่ตรึงการพึ่งพาโครงการใน a requirements.txt ไฟล์

โครงการ Python ใหม่ทุกโครงการควรเริ่มต้นด้วยไฟล์ Requirement.txt ไฟล์และสภาพแวดล้อมแยกใหม่ โดยปกติคุณติดตั้งแพ็คเกจทั้งหมดผ่าน pip/easy_install แต่อย่าลืมเพิ่มลงใน requirements.txt ของคุณ ไฟล์ด้วย ทำให้ง่ายขึ้น ( เป็นไปได้ เพื่อให้เหมาะสมยิ่งขึ้น) เพื่อปรับใช้โปรเจ็กต์ของคุณบนเซิร์ฟเวอร์หรือเพื่อให้สมาชิกในทีมบูตสแตรปโปรเจ็กต์บนเครื่องของตนเอง

โหนดแพลตฟอร์มคลาวด์ของ Google js

นอกจากนี้ยังมีความสำคัญพอ ๆ กับ พิน รุ่นเฉพาะของการอ้างอิงของคุณใน requirements.txt ของคุณ ไฟล์. โดยปกติแพ็กเกจเวอร์ชันต่างๆจะมีโมดูลฟังก์ชันและพารามิเตอร์ฟังก์ชันที่แตกต่างกัน แม้แต่การเปลี่ยนแปลงเวอร์ชันเล็กน้อยในการอ้างอิงก็สามารถทำลายแพ็คเกจของคุณได้ นี่เป็นปัญหาที่ร้ายแรงมากหากโปรเจ็กต์ของคุณใช้งานได้จริงและคุณได้กำหนดเวลาการปรับใช้เป็นประจำตั้งแต่นั้นเป็นต้นมาหากไม่มีการกำหนดเวอร์ชันระบบบิวด์ของคุณจะติดตั้งแพ็กเกจเวอร์ชันล่าสุดที่มีอยู่เสมอ

ตรึงแพ็คเกจของคุณสำหรับการผลิตเสมอ! โดยส่วนตัวแล้วฉันใช้เครื่องมือที่ดีมากชื่อว่า เครื่องมือ pip ซึ่งช่วยฉันทำสิ่งนี้ มีชุดเครื่องมือบรรทัดคำสั่งที่ช่วยจัดการการอ้างอิงของคุณ มันจะสร้าง requirements.txt โดยอัตโนมัติ หมุดนั้นไม่ใช่แค่การอ้างอิงของคุณ แต่เป็นโครงสร้างการพึ่งพาทั้งหมดของคุณซึ่งรวมถึงการอ้างอิงของการอ้างอิงของคุณ

บางครั้งคุณต้องการอัปเดตเฉพาะบางแพ็คเกจจากรายการการอ้างอิงของคุณ (ตัวอย่างเช่นเฉพาะ Django / Flask / เฟรมเวิร์กหรือยูทิลิตี้ใด ๆ ) หากคุณใช้ 'pip freeze' คุณจะไม่รู้ว่าการอ้างอิงใดเป็นของแพ็คเกจใดและคุณก็เช่นกัน ไม่สามารถอัพเกรดการอ้างอิง อย่างไรก็ตามด้วยเครื่องมือ pip มันจะตรึงแพ็กเกจโดยอัตโนมัติขึ้นอยู่กับการอ้างอิงที่คุณตรึงไว้ดังนั้นมันจะแก้ไขโดยอัตโนมัติว่าต้องอัปเดตแพ็คเกจใด เป็นโบนัสคุณยังรู้ด้วยว่าแพ็คเกจใดมาจากการพึ่งพาเนื่องจากวิธีการทำเครื่องหมายด้วยความคิดเห็นใน requirements.txt ไฟล์.

เพื่อเพิ่มความระมัดระวังเป็นความคิดที่ดีที่จะสำรองไฟล์แหล่งที่มาของการอ้างอิงด้วย! เก็บสำเนาไว้ในระบบไฟล์ของคุณโฟลเดอร์ที่จัดการด้วย Git โฟลเดอร์ S3, FTP, SFTP ทุกที่ แต่มีไว้ในมือ มีบางกรณีที่ แพคเกจที่ค่อนข้างเล็กที่ไม่อยู่ในรายการทำให้แพ็คเกจจำนวนมากใน npm เสียหาย . Pip มีเครื่องมือสำหรับการดาวน์โหลดการอ้างอิงที่จำเป็นทั้งหมดเป็นไฟล์ต้นฉบับอ่านเพิ่มเติมโดยเรียกใช้ pip help download

ข้อผิดพลาดที่ 3: การใช้ฟังก์ชัน Python แบบเก่าแทนมุมมองตามคลาส

บางครั้งก็เป็นความคิดที่ดีที่จะใช้ฟังก์ชัน Python ขนาดเล็กใน views.py ของแอปพลิเคชัน โดยเฉพาะอย่างยิ่งสำหรับการทดสอบหรือมุมมองยูทิลิตี้ แต่โดยทั่วไปคุณควรใช้มุมมองตามคลาส (CBV) ในแอปพลิเคชันของคุณ

CBV เป็นมุมมองทั่วไปที่ให้คลาสนามธรรมที่ใช้งานการพัฒนาเว็บทั่วไปที่สร้างขึ้นโดยผู้เชี่ยวชาญและครอบคลุมพฤติกรรมทั่วไปทั้งหมด พวกเขามี API ที่มีโครงสร้างที่น่าทึ่งและคุณสามารถใช้ข้อดีทั้งหมดของการเขียนโปรแกรมเชิงวัตถุเมื่อคุณใช้ CBV ทำให้ซอร์สโค้ดของคุณชัดเจนและอ่านง่ายขึ้น ลืมความเจ็บปวดจากการใช้ฟังก์ชั่นมุมมองมาตรฐาน Django สำหรับรายการการดำเนินการ CRUD การประมวลผลแบบฟอร์ม ฯลฯ คุณเพียงแค่ขยาย CBV ที่เหมาะสมสำหรับมุมมองของคุณและแทนที่คุณสมบัติหรือฟังก์ชันของคลาส (โดยปกติฟังก์ชันจะส่งคืนคุณสมบัติและคุณสามารถเพิ่มตรรกะใด ๆ ก็ได้ ทำสปาเก็ตตี้จากซอร์สโค้ดของคุณในกรณีที่ใช้ฟังก์ชั่นมุมมองแทน CBV) ซึ่งกำหนดค่าพฤติกรรมการดู

ตัวอย่างเช่นคุณสามารถมีการผสมผสานที่แตกต่างกันในโปรเจ็กต์ของคุณซึ่งจะแทนที่พฤติกรรม CBV พื้นฐานสำหรับการสร้างบริบทมุมมองการตรวจสอบการอนุญาตในระดับแถวเส้นทางเทมเพลตการสร้างอัตโนมัติจากโครงสร้างแอปพลิเคชันของคุณการผสานรวมการแคชอัจฉริยะและอื่น ๆ

ฉันสร้างแพ็คเกจชื่อ ชื่อเทมเพลต Django ซึ่งกำหนดชื่อเทมเพลตสำหรับมุมมองของคุณตามชื่อแอปพลิเคชันและชื่อคลาสมุมมอง ฉันใช้มันทุกวันและช่วยประหยัดเวลาในการประดิษฐ์ชื่อได้มาก เพียงใส่มิกซ์อินใน CBV— class Detail(TemplateNames, DetailView): - แล้วมันจะเริ่มทำงาน! แน่นอนคุณสามารถแทนที่ฟังก์ชันของฉันและเพิ่มเทมเพลตที่ตอบสนองต่ออุปกรณ์เคลื่อนที่เทมเพลตต่างๆสำหรับตัวแทนผู้ใช้หรือสิ่งอื่น ๆ ที่คุณต้องการ

ข้อผิดพลาดที่ 4: การเขียนมุมมองไขมันและแบบจำลองผอม

การเขียนตรรกะแอปพลิเคชันของคุณในมุมมองแทนที่จะเป็นโมเดลหมายความว่าคุณได้เขียนโค้ดที่อยู่ในโมเดลของคุณลงในมุมมองทำให้ 'อ้วน' และโมเดลของคุณ 'ผอม'

คุณควรเขียนโมเดลอ้วนมุมมองผอม

llc ประเภท s หรือ c

แบ่งตรรกะเป็นวิธีการเล็ก ๆ ในแบบจำลองของคุณ สิ่งนี้ช่วยให้คุณใช้งานได้หลายครั้งจากหลายแหล่ง (UI อินเทอร์เฟซผู้ดูแลระบบ, UI ส่วนหน้า, จุดสิ้นสุด API, หลายมุมมอง) ในโค้ดไม่กี่บรรทัดแทนการคัดลอกวางโค้ดจำนวนมาก ดังนั้นครั้งต่อไปที่คุณส่งอีเมลถึงผู้ใช้ให้ขยายโมเดลด้วยฟังก์ชันอีเมลแทนการเขียนตรรกะนี้ในตัวควบคุมของคุณ

นอกจากนี้ยังทำให้โค้ดของคุณทดสอบหน่วยได้ง่ายขึ้นเนื่องจากคุณสามารถทดสอบตรรกะของอีเมลได้ในที่เดียวแทนที่จะทำซ้ำ ๆ ในทุกคอนโทรลเลอร์ที่เกิดเหตุการณ์นี้

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับปัญหาได้ในไฟล์ แนวทางปฏิบัติที่ดีที่สุดของ Django โครงการ. วิธีแก้ปัญหานั้นง่ายมาก: เขียนโมเดลอ้วนและมุมมองที่ผอมดังนั้นเราจะทำในโปรเจ็กต์ถัดไปของคุณ (หรือปรับโครงสร้างปัจจุบันของคุณใหม่)

ข้อผิดพลาดที่ 5: ไฟล์การตั้งค่าขนาดใหญ่ที่ไม่สามารถจัดการได้

แม้แต่รุ่นใหม่ ไฟล์การตั้งค่าโครงการ Django มีการตั้งค่ามากมาย ในโปรเจ็กต์จริงไฟล์การตั้งค่าจะเพิ่มขึ้นเป็น 700+ บรรทัดของการกำหนดค่าและจะยากต่อการดูแลรักษาโดยเฉพาะอย่างยิ่งเมื่อสภาพแวดล้อมการพัฒนาการผลิตและการจัดเตรียมของคุณล้วนต้องการการกำหนดค่าแบบกำหนดเอง

คุณสามารถแบ่งไฟล์การกำหนดค่าด้วยตนเองและสร้างตัวโหลดแบบกำหนดเองได้ แต่ฉันอยากจะแนะนำให้คุณรู้จักกับแพ็คเกจ Python ที่ดีและผ่านการทดสอบมาเป็นอย่างดี การตั้งค่าแยก Django ที่ฉันได้ร่วมเขียน

แพคเกจมีสองฟังก์ชัน - optional และ include ซึ่งรองรับสัญลักษณ์แทนสำหรับพา ธ และอิมพอร์ตไฟล์คอนฟิกูเรชันของคุณในบริบทเดียวกันทำให้ง่ายต่อการสร้างคอนฟิกูเรชันของคุณโดยใช้รายการคอนฟิกูเรชันที่ประกาศไว้ในไฟล์ที่โหลดก่อนหน้านี้ ไม่มีผลต่อประสิทธิภาพของ Django และคุณสามารถใช้ในโครงการใดก็ได้

ดูตัวอย่างการกำหนดค่าขั้นต่ำ:

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'), )

ข้อผิดพลาดที่ 6: แอปพลิเคชันแบบออล - อิน - วันโครงสร้างแอปพลิเคชันไม่ถูกต้องและการจัดวางทรัพยากรไม่ถูกต้อง

โครงการ Django ใด ๆ ประกอบด้วยหลายแอปพลิเคชัน ในสัญกรณ์ Django a ใบสมัคร เป็นแพ็คเกจ Python ที่มี __init__.py เป็นอย่างน้อย และ models.py ไฟล์; ใน Django เวอร์ชันล่าสุด models.py ไม่จำเป็นอีกต่อไป __init__.py ก็เพียงพอแล้ว

แอปพลิเคชัน Django สามารถมีโมดูล Python โมดูลเฉพาะ Django (มุมมอง, URL, โมเดล, ผู้ดูแลระบบ, แบบฟอร์ม, แท็กเทมเพลต ฯลฯ ), ไฟล์คงที่, เทมเพลต, การย้ายฐานข้อมูล, คำสั่งการจัดการ, การทดสอบหน่วยและอื่น ๆ คุณควรแบ่งแอปพลิเคชั่นเสาหินของคุณเป็นขนาดเล็ก แอปพลิเคชันที่ใช้ซ้ำได้ โดยใช้ตรรกะง่ายๆ คุณควรจะสามารถอธิบายวัตถุประสงค์ทั้งหมดของแอปด้วยประโยคสั้น ๆ หนึ่งหรือสองประโยค ตัวอย่างเช่น:“ อนุญาตให้ผู้ใช้ลงทะเบียนและเปิดใช้งานบัญชีของตนทางอีเมล”

เป็นความคิดที่ดีที่จะเรียกโฟลเดอร์โครงการ project และวางแอปพลิเคชันใน project/apps/. จากนั้นวางการอ้างอิงแอปพลิเคชันทั้งหมดลงในโฟลเดอร์ย่อยของตนเอง

ตัวอย่าง:

• ไฟล์คงที่: project/apps/appname/static/appname/
• แท็กเทมเพลต: project/apps/appname/templatetags/appname.py
• ไฟล์เทมเพลต: project/apps/appname/templates/appname/

คำนำหน้าชื่อแอปพลิเคชันในโฟลเดอร์ย่อยเสมอเนื่องจากโฟลเดอร์แบบคงที่ทั้งหมดรวมอยู่ในโฟลเดอร์เดียวและหากสองแอปพลิเคชันขึ้นไปมี js/core.js ไฟล์แอปพลิเคชันสุดท้ายใน settings.INSTALLED_APPLICATIONS จะแทนที่รายการก่อนหน้า ฉันเคยมีข้อบกพร่องนี้ในโครงการปัจจุบันของฉันและเสียเวลาประมาณหกชั่วโมงในการดีบักจนกว่าฉันจะรู้ว่านักพัฒนารายอื่นได้แทนที่ static/admin/js/core.js เนื่องจากทีมกำลังใช้แผงผู้ดูแลระบบ SPA ที่กำหนดเองและตั้งชื่อไฟล์ในลักษณะเดียวกัน

นี่คือโครงสร้างตัวอย่างสำหรับแอปพลิเคชันพอร์ทัลที่มีทรัพยากรและโมดูล Python จำนวนมาก

[email protected] :/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

เมื่อใช้โครงสร้างดังกล่าวคุณสามารถส่งออกแอปพลิเคชันไปยังแพ็คเกจ Python อื่นและใช้อีกครั้งได้ทุกเมื่อ คุณสามารถเผยแพร่ใน PyPi เป็นแพ็กเกจโอเพนซอร์สหรือย้ายไปยังโฟลเดอร์อื่น

คุณจะได้โครงสร้างโครงการดังนี้

[email protected] :/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

แน่นอนว่าในโครงการจริงมันจะซับซ้อนกว่านี้ แต่โครงสร้างนี้ทำให้สิ่งต่างๆง่ายขึ้นและสะอาดขึ้น

ข้อผิดพลาดที่ 7: STATICFILES_DIRS และ STATIC_ROOT สร้างความสับสนให้กับนักพัฒนา Newbie Django

ไฟล์แบบคงที่คือเนื้อหาที่ไม่เปลี่ยนแปลงผ่านการใช้งานของแอปเช่น JavaScript, CSS, รูปภาพ, แบบอักษร ฯลฯ ใน Django ไฟล์เหล่านี้จะถูก 'รวบรวม' ไว้ในไดเรกทอรีสาธารณะในระหว่างขั้นตอนการทำให้ใช้งานได้เท่านั้น

ในโหมดการพัฒนา - python manage.py runserver —Django ค้นหาไฟล์แบบคงที่โดยใช้ STATICFILES_FINDERS การตั้งค่า. โดยค่าเริ่มต้นจะพยายามค้นหาไฟล์คงที่ที่ร้องขอในโฟลเดอร์ที่แสดงรายการในไฟล์ STATICFILES_DIRS การตั้งค่า. ในกรณีที่เกิดความล้มเหลว Django จะพยายามค้นหาไฟล์โดยใช้ django.contrib.staticfiles.finders.AppDirectoriesFinder ซึ่งดูใน static โฟลเดอร์ของทุกแอปพลิเคชันที่ติดตั้งในโครงการ สิ่งนี้ช่วยให้คุณสามารถเขียนแอปพลิเคชันที่ใช้ซ้ำได้ซึ่งมาพร้อมกับไฟล์คงที่ของตนเอง

ในการผลิตคุณให้บริการแบบคงที่โดยใช้เว็บเซิร์ฟเวอร์แบบสแตนด์อโลนเช่น Nginx เว็บเซิร์ฟเวอร์ไม่รู้อะไรเลยเกี่ยวกับโครงสร้างแอปพลิเคชันโครงการ Django หรือโฟลเดอร์ใดที่ไฟล์คงที่ของคุณถูกแจกจ่ายโชคดีที่ Django มีคำสั่งรวบรวมการจัดการแบบคงที่ python manage.py collectstatic ซึ่งดำเนินการตาม STATICFILES_FINDERS และคัดลอกไฟล์แบบคงที่ทั้งหมดจากแอปพลิเคชัน static โฟลเดอร์และโฟลเดอร์ที่แสดงใน STATICFILES_DIRS ลงในไดเร็กทอรีที่คุณระบุในไฟล์ STATIC_ROOT การตั้งค่า. สิ่งนี้ช่วยให้สามารถแก้ปัญหาทรัพยากรไฟล์แบบคงที่โดยใช้ตรรกะเดียวกันกับเซิร์ฟเวอร์โหมดการพัฒนา Django และมีไฟล์แบบคงที่ทั้งหมดในที่เดียวสำหรับเว็บเซิร์ฟเวอร์ของคุณ

อย่าลืมเรียกใช้ collectstatic ในสภาพแวดล้อมการผลิตของคุณ!

วิธีรับหมายเลขบัตรเครดิต

ข้อผิดพลาดที่ 8: ค่าเริ่มต้น STATICFILES_STORAGE, Django Templates Loaders ในการผลิต

STATICFILES_STORAGE

มาพูดถึงการจัดการสินทรัพย์สภาพแวดล้อมการผลิต เราสามารถมอบประสบการณ์การใช้งานที่ดีที่สุดให้กับผู้ใช้ได้หากเราใช้นโยบาย“ เนื้อหาไม่มีวันหมดอายุ” (ซึ่งคุณสามารถอ่านเพิ่มเติมได้ ที่นี่ ). หมายความว่าไฟล์คงที่ทั้งหมดของเราควรถูกแคชไว้โดยเว็บเบราว์เซอร์เป็นเวลาหลายสัปดาห์หลายเดือนหรือหลายปี กล่าวคือผู้ใช้ของคุณควรดาวน์โหลดเนื้อหาของคุณเพียงครั้งเดียว!

เจ๋งมากและเราสามารถทำได้โดยใช้ไม่กี่บรรทัดในการกำหนดค่า Nginx สำหรับโฟลเดอร์ไฟล์คงที่ของเรา แต่การทำให้แคชไม่ถูกต้องล่ะ หากผู้ใช้จะดาวน์โหลดเนื้อหาของเราเพียงครั้งเดียวจะเกิดอะไรขึ้นหากคุณอัปเดตโลโก้แบบอักษร JavaScript หรือสีข้อความสำหรับรายการในเมนู ในการหลีกเลี่ยงสิ่งนี้คุณควรสร้าง URL และชื่อไฟล์ที่ไม่ซ้ำกันสำหรับไฟล์คงที่ของเราในทุกการปรับใช้!

เราสามารถทำได้ง่ายๆโดยใช้ ManifestStaticFilesStorage เป็น STATICFILES_STORAGE (โปรดระวังการแฮชจะเปิดใช้งานในโหมด DEBUG=false เท่านั้น) และเรียกใช้ collectstatic คำสั่งการจัดการที่กล่าวถึงข้างต้น วิธีนี้จะลดจำนวนคำขอเนื้อหาในเว็บไซต์การผลิตของคุณและจะทำให้เว็บไซต์ของคุณแสดงผลเร็วขึ้นมาก

ตัวโหลดเทมเพลต Django ที่แคชไว้

ฟีเจอร์ Django ที่ยอดเยี่ยมอีกอย่างคือตัวโหลดเทมเพลตที่แคชซึ่งจะไม่โหลดซ้ำและแยกวิเคราะห์ไฟล์เทมเพลตในทุกการแสดงผลเทมเพลต การแยกวิเคราะห์เทมเพลตเป็นการดำเนินการที่มีค่าใช้จ่ายสูงและใช้ทรัพยากรจำนวนมาก ตามค่าเริ่มต้นเทมเพลต Django จะถูกแยกวิเคราะห์ในทุกคำขอ แต่สิ่งนี้ไม่ดีโดยเฉพาะอย่างยิ่งในระหว่างการผลิตซึ่งคุณสามารถประมวลผลคำขอหลายพันรายการในช่วงเวลาสั้น ๆ

ตรวจสอบไฟล์ cached.Loader ส่วนการกำหนดค่าสำหรับตัวอย่างที่ดีและรายละเอียดเกี่ยวกับวิธีการทำเช่นนี้ อย่าใช้ตัวโหลดในโหมดการพัฒนาเพราะจะไม่โหลดเทมเพลตที่แยกวิเคราะห์ซ้ำจากระบบไฟล์ คุณจะต้องรีสตาร์ทโครงการโดยใช้ python manage.py startapp ทุกครั้งที่เปลี่ยนเทมเพลต อาจเป็นเรื่องที่น่ารำคาญในระหว่างการพัฒนา แต่เหมาะสำหรับสภาพแวดล้อมการผลิต

ข้อผิดพลาดที่ 9: สคริปต์ Python บริสุทธิ์สำหรับยูทิลิตี้หรือสคริปต์

Django มีคุณสมบัติที่ดีมากที่เรียกว่า คำสั่งการจัดการ . เพียงใช้มันแทนการสร้างล้อใหม่และเขียนสคริปต์ Python แบบดิบสำหรับยูทิลิตี้โครงการของคุณ

ตรวจสอบไฟล์ Django Extensions แพคเกจซึ่งเป็นชุดของส่วนขยายที่กำหนดเองสำหรับ Django อาจมีคนใช้คำสั่งของคุณไปแล้ว! มีคำสั่งงานทั่วไปจำนวนมากอยู่แล้ว

ข้อผิดพลาดที่ 10: การสร้างวงล้อใหม่

Django และ Python มีโซลูชันที่พร้อมใช้งานหลายพันรายการ ลองใช้ Google ก่อนที่จะเขียนสิ่งที่ไม่ซ้ำใคร อาจมีโซลูชันที่มีคุณลักษณะมากมายที่มีอยู่แล้ว

เพียงแค่พยายามทำให้สิ่งต่างๆเรียบง่าย Google ครั้งแรก! ติดตั้งกำหนดค่าขยายและรวมเข้ากับโปรเจ็กต์ของคุณหากคุณพบแพ็คเกจคุณภาพดีและแน่นอนว่าจะมีส่วนร่วมในโอเพ่นซอร์สเมื่อคุณมีโอกาส

ในการเริ่มต้นนี่คือรายการแพ็คเกจสาธารณะของฉันสำหรับ Django:

โปรแกรมเมอร์จะใช้เครื่องมือใดในการแสดงภาพความสัมพันธ์ระหว่างโมดูลต่างๆ

• Django Macros URL ทำให้ง่ายต่อการเขียน (และอ่าน) รูปแบบ URL ในแอปพลิเคชัน Django ของคุณโดยใช้มาโคร
• ชื่อเทมเพลต Django เป็นการผสมผสานขนาดเล็กที่ช่วยให้คุณกำหนดชื่อเทมเพลต CBV ของคุณได้อย่างง่ายดาย
• django- แยกการตั้งค่า ช่วยให้คุณจัดระเบียบการตั้งค่า Django เป็นไฟล์และไดเรกทอรีต่างๆ ลบล้างและแก้ไขการตั้งค่าได้อย่างง่ายดาย ใช้สัญลักษณ์แทนในเส้นทางไฟล์การตั้งค่าและทำเครื่องหมายไฟล์การตั้งค่าเป็นทางเลือก

อย่าทำซ้ำตัวเอง (แห้ง)!

ฉันชอบวิธีการแห้งมาก นั่นคือเหตุผลที่ฉันสร้างขึ้น โครงกระดูก Django เป็นเครื่องมืออำนวยความสะดวกที่มีคุณสมบัติที่เป็นระเบียบมากมายนอกกรอบ:

• อิมเมจ Docker สำหรับการพัฒนา / การผลิตจัดการโดยนักเทียบท่าซึ่งช่วยให้คุณจัดระเบียบรายการคอนเทนเนอร์ได้อย่างง่ายดาย
• สคริปต์ผ้าอย่างง่ายสำหรับการปรับใช้การผลิต
• การกำหนดค่าสำหรับ การตั้งค่าแยก Django แพคเกจที่มีการตั้งค่าสำหรับแหล่งที่มาพื้นฐานและท้องถิ่น
• Webpack รวมอยู่ในโปรเจ็กต์ - เฉพาะ dist Django จะรวบรวมโฟลเดอร์บน collectstatic คำสั่ง
• กำหนดค่าการตั้งค่าและคุณสมบัติพื้นฐานของ Django ทั้งหมดเช่นเทมเพลต Django ที่สามารถแคชได้ในการผลิตไฟล์คงที่ที่แฮชแถบเครื่องมือแก้จุดบกพร่องในตัวการบันทึก ฯลฯ

เป็น Django Skeleton ที่พร้อมใช้งานสำหรับโปรเจ็กต์ถัดไปของคุณตั้งแต่เริ่มต้นและหวังว่าจะช่วยให้คุณประหยัดเวลาได้มากโดยการบูตโปรเจ็กต์ของคุณ Webpack มีการกำหนดค่าพื้นฐานน้อยที่สุด แต่ยังมีการติดตั้ง SASS ที่กำหนดค่าไว้ล่วงหน้าเพื่อจัดการ .scss ไฟล์.