ข้อผิดพลาด 10 อันดับแรกที่นักพัฒนา Django สร้าง

ในบทช่วยสอนนี้ เราจะพิจารณาข้อผิดพลาดทั่วไปที่นักพัฒนา 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 ที่ติดตั้งในสภาพแวดล้อม นี่เป็นวิธีที่ฉันชอบเพราะเป็นวิธีที่ง่ายที่สุดในการทำงาน โดยปกติ ฉันสร้างสภาพแวดล้อมใกล้กับโฟลเดอร์โครงการ
• virtualenvwrapper: แพ็คเกจ Python ที่ติดตั้งทั่วโลกและจัดเตรียมชุดเครื่องมือสำหรับสร้าง/ลบ/เปิดใช้งาน/อื่นๆ สภาพแวดล้อมเสมือนจริง สภาพแวดล้อมเสมือนทั้งหมดถูกเก็บไว้ในโฟลเดอร์เดียว (ซึ่งสามารถแทนที่ได้ผ่านตัวแปรสภาพแวดล้อม WORKON_HOME) ฉันไม่เห็นข้อดีใด ๆ ในการใช้ virtualenvwrapper แทน virtualenv
• เครื่องเสมือน (VM): ไม่มีการแยกใดที่ดีไปกว่าเครื่องเสมือนทั้งหมดที่ทุ่มเทให้กับแอปพลิเคชันของคุณ มีเครื่องมือมากมายให้เลือก รวมถึง VirtualBox (ฟรี), VMware, Parallels และ Proxmox (รายการโปรดส่วนตัวของฉันและมีเวอร์ชันฟรี) เมื่อรวมกับเครื่องมืออัตโนมัติของ VM เช่น Vagrant นี่อาจเป็นโซลูชันที่ทรงพลังอย่างยิ่ง
• คอนเทนเนอร์: ในช่วงไม่กี่ปีที่ผ่านมา ฉันได้ใช้ Docker ในเกือบทุกโครงการ โดยเฉพาะอย่างยิ่งในทุกโครงการใหม่ที่ฉันเริ่มต้นจากศูนย์ Docker เป็นเครื่องมือที่น่าทึ่งซึ่งมีฟีเจอร์มากมายและมีเครื่องมือของบุคคลที่สามมากมายสำหรับคอนเทนเนอร์อัตโนมัติ มีคุณลักษณะการแคชชั้นซึ่งทำให้การสร้างคอนเทนเนอร์ของคุณใหม่รวดเร็วมาก ในคอนเทนเนอร์ ฉันใช้สภาพแวดล้อม Python ของระบบทั่วโลก เพราะทุกคอนเทนเนอร์มีระบบไฟล์ของตัวเอง และโปรเจ็กต์ต่างๆ จะถูกแยกออกจากกันในระดับสูง Docker ช่วยให้สมาชิกทีมใหม่เริ่มทำงานในโครงการได้เร็วขึ้น โดยเฉพาะหากพวกเขามีประสบการณ์ Docker

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

ข้อผิดพลาดหมายเลข 2: ไม่ตรึงการขึ้นต่อกันของโปรเจ็กต์ในไฟล์ requirements.txt .txt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

แพ็คเกจมีฟังก์ชันสองแบบ— 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 แอปพลิเคชันคือแพ็คเกจ 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 INSTALLED_APPLICATIONS จะแทนที่รายการก่อนหน้า ฉันเคยมีข้อผิดพลาดนี้ในโปรเจ็กต์ปัจจุบันของฉัน และเสียเวลาในการดีบั๊กประมาณหกชั่วโมง จนกระทั่งฉันรู้ว่านักพัฒนารายอื่นได้แทนที่ static/admin/js/core.js เพราะทีมกำลังใช้แผงผู้ดูแลระบบ SPA แบบกำหนดเองและตั้งชื่อไฟล์ด้วยวิธีเดียวกัน

นี่คือตัวอย่างโครงสร้างสำหรับพอร์ทัลแอ็พพลิเคชันที่มีทรัพยากรและโมดูล 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

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

คุณจะจบลงด้วยโครงสร้างโครงการเช่นนี้:

 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

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

ข้อผิดพลาดที่ 7: STATICFILES_DIRS และ STATIC_ROOT สับสนให้กับนักพัฒนามือใหม่ 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 ในการผลิต

STATICFILES_STORAGE

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

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

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

แคช Django ตัวโหลดเทมเพลต

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

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

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

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

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

ข้อผิดพลาดหมายเลข 10: การคิดค้นล้อใหม่

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

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

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

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

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

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

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

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