ข้ามไปที่เนื้อหา

คู่มือนักพัฒนา

ส่วนนี้สำหรับวิศวกร — ไม่ว่าคุณจะร่วมพัฒนา upstream ให้กับ roots_hemms_* สร้างส่วนขยายเฉพาะลูกค้าบน HEMMS หรือดูแลการติดตั้ง HEMMS และจำเป็นต้องเข้าใจว่าชิ้นส่วนต่าง ๆ ประกอบเข้าด้วยกันอย่างไร

เริ่มต้นที่นี่

  • สถาปัตยกรรม

    การประกอบสามชั้น (Odoo base → OCA → roots_hemms_*) หลักการตั้งชื่อฟิลด์ และเมทริกซ์การตัดสินใจระหว่าง OCA กับ roots_hemms_*

    อ่านสถาปัตยกรรม

  • การพัฒนาโมดูล

    สร้างโครงโมดูล roots_hemms_* ใหม่ พึ่งพาชั้น HEMMS ที่ถูกต้อง เขียนการทดสอบตามรูปแบบของโปรเจกต์ และเชื่อมต่อเข้ากับ CI

    อ่านการพัฒนาโมดูล

  • API Reference

    เอกสารอ้างอิงโมเดล + ฟิลด์ แยกตามโมดูล มีประโยชน์เมื่อคุณต้องการ _inherit โมเดลของ HEMMS เชื่อม compute หรือขยายรายงาน

    เรียกดู API

  • CI / CD

    GitHub Actions workflow ที่กั้นทุก PR — lint, การทดสอบ 177 รายการ, การ build เอกสาร และวิธีจำลอง CI บนเครื่องด้วย make ci

    อ่าน CI/CD

  • การร่วมพัฒนา

    ขั้นตอนการทำงานของเอกสาร / commit / PR หลักการรูปแบบสำหรับ Markdown, admonition, code fence และภาพหน้าจอ

    อ่านการร่วมพัฒนา

  • บันทึกการสร้างเซสชัน 1

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

    อ่านบันทึกการสร้าง

แผนการออกแบบรายไตรมาส

แต่ละไตรมาสที่ส่งมอบแล้วมีแผนการออกแบบที่ถูกตรึงไว้ committed อยู่ข้าง ๆ โค้ด อ่านเอกสารเหล่านี้ ก่อน เปิด PR ที่แตะต้องไตรมาสนั้น — แผนเหล่านี้บันทึกการตัดสินใจ (และทางเลือกที่ถูกปฏิเสธ) ที่ หล่อหลอมการพัฒนาขึ้นมา

Q1 (รากฐาน) และ Q7 (CI/CD) ไม่ได้ส่งมอบพร้อมไฟล์ qN-*-plan.md อย่างชัดเจน — บริบทของทั้งสองถูกบันทึกไว้ใน บันทึกการสร้างเซสชัน 1 และ CI/CD ตามลำดับ

คู่มือตามกลุ่มผู้อ่าน

คุณคือ... เริ่มที่นี่
ผู้ร่วมพัฒนาใหม่ที่ต้องการส่งการแก้ไขเล็ก ๆ การร่วมพัฒนา → CI/CD → เปิด PR
ผู้ร่วมพัฒนาใหม่ที่ต้องการส่งโมดูลใหม่ สถาปัตยกรรม → การพัฒนาโมดูล → แผน Q ที่เกี่ยวข้องในฐานะตัวอย่างที่ทำเสร็จแล้ว
ผู้รวมระบบของโรงพยาบาลที่เชื่อม HEMMS เข้ากับระบบภายนอก API Reference → เอกสารผู้ใช้ของโมดูลที่เกี่ยวข้องใต้ modules/
ผู้ตรวจสอบที่ตรวจทานตรรกะการกำกับดูแล สถาปัตยกรรม และ ส่วนการกำกับดูแล — ทุกโมดูล Layer 3 ถูกออกแบบให้สอดคล้องกับประเด็นการกำกับดูแลเพียงเรื่องเดียว

กฎประจำบ้าน

  • ทำตามกฎ 3 ชั้น โค้ดที่คุณปรับแต่งเองอยู่ใน Layer 3 (addons/roots/) ไม่ใช่ Layer 2 (addons/oca/) หรือ Layer 1 (Odoo base) สถาปัตยกรรม อธิบายเหตุผล
  • ทำตามหลักการตั้งชื่อฟิลด์ ฟิลด์เฉพาะของโรงพยาบาล บนโมเดลที่สืบทอดมาใช้คำนำหน้า roots_ ส่วนโมเดลใหม่ ที่นิยามใน HEMMS ใช้คำนำหน้า _name ว่า hemms. ฟิลด์ของตัวเอง ไม่จำเป็นต้องมีคำนำหน้าซ้ำซ้อน
  • CI ต้องคงสถานะเขียว Lint + การทดสอบ 177 รายการ จำลองบนเครื่องด้วย make ci ก่อน push หาก CI จับบั๊กจริงได้ในการรันครั้งแรก (เคยเกิดขึ้น สามครั้งแล้ว — ดู Release Notes) ให้แก้บั๊ก อย่าปิดการทดสอบ
  • Pre-commit เป็นข้อบังคับ ruff, pylint_odoo และ oca-checks-odoo-module รันบนทุก commit ติดตั้งด้วย pre-commit install หลังจาก clone

ขอให้สนุก อ่าน Roadmap เพื่อดูสิ่งที่อยู่ในคิวถัดไป และจุดที่เปิดให้ชุมชนร่วมพัฒนาได้