แนวทางปฏิบัติแนะนำ

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

แนวทางปฏิบัติแนะนำโดยทั่วไป

เราขอแนะนำให้คุณใช้แนวทางปฏิบัติแนะนำต่อไปนี้สำหรับส่วนเสริมทั้งหมดที่คุณพัฒนา

กำหนดการเป็นเจ้าของส่วนเสริมก่อนเริ่มต้น

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

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

ขยายขอบเขตการใช้งาน Google Workspace ไม่ใช่ทำซ้ำ

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

กำหนดขอบเขตให้แคบ

เมื่อ กำหนดขอบเขต อย่างชัดเจน ให้เลือกชุดขอบเขตที่มีสิทธิ์ น้อยที่สุดเท่าที่จะเป็นไปได้เสมอ ตัวอย่างเช่น อย่าให้ส่วนเสริมขอสิทธิ์เข้าถึงปฏิทินของผู้ใช้แบบเต็มด้วยขอบเขต https://www.googleapis.com/auth/calendar หากส่วนเสริมต้องการเพียงสิทธิ์เข้าถึงแบบอ่านอย่างเดียว สำหรับสิทธิ์เข้าถึงแบบอ่านอย่างเดียว ให้ใช้ขอบเขต https://www.googleapis.com/auth/calendar.readonly

หลีกเลี่ยงการพึ่งพาไลบรารีมากเกินไป

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

เวลาในการตอบสนองที่อธิบายไว้ข้างต้นจะมีผลกับโปรเจ็กต์ Apps Script ที่ใช้เป็นไลบรารีฝั่งเซิร์ฟเวอร์เท่านั้น คุณสามารถใช้ไลบรารี JavaScript ฝั่งไคลเอ็นต์ เช่น jQuery ได้อย่างอิสระโดยไม่พบเวลาในการตอบสนองนี้

แนวทางปฏิบัติแนะนำสำหรับส่วนเสริมของ Google Workspace

แนวทางปฏิบัติแนะนำต่อไปนี้มีผลกับส่วนเสริมของ Google Workspace และการใช้ บริการการ์ดเท่านั้น

ใช้การ์ดเพียงไม่กี่ใบ

หากส่วนเสริมใช้การ์ดมากเกินไป การกำหนดค่าการนำทางจะซับซ้อนและจัดการได้ยาก

หลีกเลี่ยงการสร้างการ์ดมากกว่าที่จำเป็น

ใช้ฟังก์ชันการสร้างวิดเจ็ต

เมื่อเขียนโค้ดที่สร้าง Card หรือออบเจ็กต์ UI ที่ซับซ้อนอื่นๆ ให้พิจารณาใส่โค้ดนั้นไว้ในฟังก์ชันของตัวเอง ฟังก์ชันการสร้างนี้ควรสร้างออบเจ็กต์และส่งคืนออบเจ็กต์นั้นเท่านั้น ซึ่งจะช่วยให้คุณสร้างออบเจ็กต์นั้นขึ้นมาใหม่ได้อย่างรวดเร็วทุกครั้งที่ต้องรีเฟรช UI อย่าลืมเรียกใช้ build() หลังจากใช้ คลาส Builder ใน บริการการ์ด

ทำให้การ์ดเรียบง่าย

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

ใช้การ์ดข้อผิดพลาด

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

เขียนการทดสอบและข้อความทดสอบ

คุณควรทดสอบส่วนเสริมทั้งหมดที่สร้างขึ้นอย่างละเอียด สร้างบิลด์ทดสอบฟังก์ชันที่สร้างการ์ดและวิดเจ็ตโดยใช้ข้อมูลทดสอบ แล้วตรวจสอบว่ามีการสร้างออบเจ็กต์ตามที่คาดไว้

เมื่อใช้ฟังก์ชันเรียกกลับการดำเนินการ คุณมักจะต้อง สร้างออบเจ็กต์การตอบกลับ คุณสามารถใช้คำสั่งต่อไปนี้เพื่อตรวจสอบว่ามีการสร้างการตอบกลับอย่างถูกต้อง

    Logger.log(response.printJson());

เรียกใช้ฟังก์ชันทดสอบที่คุณสร้างขึ้นโดยตรงจากเอดิเตอร์ Apps Script โดยใช้เมนูเรียกใช้ เมื่อมีส่วนเสริม ที่ใช้งานได้แล้ว ให้ติดตั้งเวอร์ชัน ที่ยังไม่ได้เผยแพร่เพื่อให้คุณทดสอบได้

ใช้ข้อมูลทดสอบที่เหมาะสมกับแอปพลิเคชันโฮสต์แต่ละรายการที่ส่วนเสริมขยายขอบเขตการใช้งาน ตัวอย่างเช่น หากส่วนเสริมขยายขอบเขตการใช้งาน Gmail คุณอาจต้องมีอีเมลทดสอบ 2-3 ฉบับและรหัสข้อความของอีเมลเหล่านั้น เพื่อให้แน่ใจว่าส่วนเสริมจะทำงานตามที่คาดไว้เมื่อได้รับเนื้อหาข้อความที่แตกต่างกัน คุณสามารถรับรหัสข้อความสำหรับข้อความที่ต้องการได้โดยการแสดงรายการ ข้อความโดยใช้Gmail API users.messages.list วิธี หรือโดยใช้บริการGmail ของ Apps Script

แนวทางปฏิบัติแนะนำสำหรับการประชุมในปฏิทิน

หากส่วนเสริมผสานรวมตัวเลือกการประชุมในปฏิทินของบุคคลที่สาม เข้ากับ Google ปฏิทิน ให้ทำตามแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้

ทำให้ onCreateFunction มีขนาดเล็ก

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

ใช้ช่อง ConferenceData ที่เหมาะสมสำหรับข้อมูลการประชุม

เมื่อสร้าง ConferenceData ออบเจ็กต์ คุณสามารถป้อนรายละเอียดเกี่ยวกับการประชุม (รหัสการเข้าถึง หมายเลขโทรศัพท์ รหัส PIN, URI ฯลฯ) ตรวจสอบว่าได้ใช้ช่อง EntryPoint ที่เกี่ยวข้องสำหรับ ข้อมูลนี้ อย่าใส่รายละเอียดเหล่านี้ในช่องหมายเหตุ ConferenceData

อย่าผนวกรายละเอียดการประชุมเข้ากับกิจกรรมในปฏิทิน

ส่วนเสริมไม่จำเป็นต้องเพิ่มข้อมูลเกี่ยวกับการประชุมของบุคคลที่สามที่สร้างขึ้นลงในคำอธิบายกิจกรรมในปฏิทิน ปฏิทินจะดำเนินการนี้โดยอัตโนมัติเมื่อจำเป็น