บทเรียนที่ได้รับขณะพัฒนาปลั๊กอิน WordPress

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

ในบทความนี้ ฉันจะแบ่งปันประสบการณ์ห้าปีของฉันในการพัฒนาปลั๊กอิน WordPress ปลั๊กอินแรกที่ฉันเขียนคือปลั๊กอินทางการตลาดอย่างง่าย มันแสดงปุ่มเรียกร้องให้ดำเนินการ (CTA) พร้อมวลีค้นหาของ Google ตั้งแต่นั้นมา ฉันได้เขียนปลั๊กอินฟรีอีก 11 ปลั๊กอิน และดูแลรักษาเกือบทั้งหมด ฉันได้เขียนปลั๊กอินสำหรับลูกค้าของฉันประมาณ 40 รายการ ตั้งแต่อันเล็กๆ ไปจนถึงปลั๊กอินที่ได้รับการดูแลมานานกว่าหนึ่งปีแล้ว

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

1. แก้ปัญหา

หากปลั๊กอินของคุณไม่สามารถแก้ปัญหาได้ ปลั๊กอินจะไม่ถูกดาวน์โหลด มันง่ายอย่างนั้น

ใช้ปลั๊กอิน Advanced Cron Manager (การติดตั้งที่ใช้งานมากกว่า 8,000 รายการ) ช่วยผู้ใช้ WordPress ที่กำลังมีปัญหาในการดีบัก cron ของพวกเขา ปลั๊กอินถูกเขียนขึ้นจากความต้องการ — ฉันต้องการบางสิ่งบางอย่างเพื่อช่วยตัวเอง ฉันไม่จำเป็นต้องทำการตลาดแบบนี้เพราะผู้คนต้องการมันอยู่แล้ว มันเกาคันของพวกเขา

ในทางกลับกัน มี Bug — บินบนปลั๊กอินหน้าจอ (การติดตั้งที่ใช้งานมากกว่า 70 รายการ) มันสุ่มจำลองแมลงวันบนหน้าจอ มันไม่ได้แก้ปัญหาจริงๆ ดังนั้นจึงไม่มีผู้ชมจำนวนมาก มันเป็นปลั๊กอินที่สนุกในการพัฒนา

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

ตามที่ David Hehenberger ยืนยันในบทความของเขาเกี่ยวกับการเขียนปลั๊กอินที่ประสบความสำเร็จ ความต้องการเป็นปัจจัยสำคัญในการตัดสินใจของผู้ใช้ WordPress ว่าจะติดตั้งปลั๊กอินเฉพาะหรือไม่

หากคุณมีโอกาสที่จะแก้ปัญหาของใครบางคน จงใช้โอกาส

2. สนับสนุนผลิตภัณฑ์ของคุณ

“ชาวอเมริกัน 3 ใน 5 คนจะลองใช้แบรนด์หรือบริษัทใหม่เพื่อประสบการณ์การบริการที่ดียิ่งขึ้น 7 ใน 10 กล่าวว่าพวกเขาเต็มใจที่จะใช้จ่ายมากขึ้นกับบริษัทที่พวกเขาเชื่อว่าให้บริการที่เป็นเลิศ”

— นิกกี้เยเกอร์

อย่าละเลยการสนับสนุนของคุณ อย่าปฏิบัติเหมือนเป็นความจำเป็น แต่ให้เป็นเหมือนโอกาส

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

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

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

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

นี่คือรายการของการดำเนินการบางอย่างที่คุณสามารถทำได้:

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

ไม่สำคัญหรอกว่าคุณใช้ซอฟต์แวร์ใดเพื่อสนับสนุนผลิตภัณฑ์ของคุณ ฟอรัมการสนับสนุนอย่างเป็นทางการของ WordPress.org ใช้งานได้ดีกับอีเมลหรือระบบสนับสนุนของคุณเอง ฉันใช้ฟอรัมของ WordPress.org สำหรับปลั๊กอินฟรีและระบบของฉันเองสำหรับปลั๊กอินพรีเมียม

3. อย่าใช้ผู้แต่ง

Composer เป็นซอฟต์แวร์จัดการแพ็คเกจ ที่เก็บข้อมูลของแพ็คเกจถูกโฮสต์บน packagist.org และคุณสามารถดาวน์โหลดแพ็คเกจเหล่านั้นไปยังโครงการของคุณได้อย่างง่ายดาย มันเหมือนกับ NPM หรือ Bower สำหรับ PHP การจัดการแพ็คเกจของบริษัทอื่นในลักษณะที่ Composer ทำนั้นเป็นแนวปฏิบัติที่ดี แต่อย่าใช้ในโปรเจ็กต์ WordPress ของคุณ

ฉันรู้ ฉันทิ้งระเบิด ให้ฉันอธิบาย

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

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

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

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

4. รองรับ PHP เวอร์ชันเก่าอย่างสมเหตุสมผล

ไม่รองรับ PHP เวอร์ชันเก่ามาก เช่น 5.2 ปัญหาด้านความปลอดภัยและการบำรุงรักษาไม่คุ้มค่า และคุณจะไม่ได้รับการติดตั้งเพิ่มเติมจากเวอร์ชันเก่าเหล่านั้น

ไปกับ PHP 5.6 เป็นข้อกำหนดขั้นต่ำแม้ว่าการสนับสนุนอย่างเป็นทางการจะถูกยกเลิกภายในสิ้นปี 2018 WordPress เองต้องใช้ PHP 7.2

มีการเคลื่อนไหวที่ไม่สนับสนุนเวอร์ชัน PHP รุ่นเก่า ทีมงาน Yoast ได้เปิดตัวไลบรารี Whip ซึ่งคุณสามารถรวมไว้ในปลั๊กอินของคุณ และจะแสดงข้อมูลสำคัญเกี่ยวกับเวอร์ชัน PHP แก่ผู้ใช้ของคุณ และเหตุผลที่พวกเขาควรอัปเกรด

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

5. เน้นที่รหัสคุณภาพ

การเขียนโค้ดที่ดีนั้นยากในช่วงเริ่มต้น ต้องใช้เวลาในการเรียนรู้หลักการ "SOLID" และรูปแบบการออกแบบ และเพื่อเปลี่ยนนิสัยการเขียนโค้ดแบบเก่า

ครั้งหนึ่งฉันใช้เวลาสามวันในการแสดงสตริงอย่างง่ายใน WordPress เมื่อฉันตัดสินใจเขียนปลั๊กอินตัวใดตัวหนึ่งของฉันใหม่โดยใช้หลักการเขียนโค้ดที่ดีกว่า มันน่าผิดหวังที่รู้ว่าควรใช้เวลา 30 นาที การเปลี่ยนความคิดของฉันนั้นเจ็บปวด แต่ก็คุ้มค่า

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

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

ข้างต้นเป็นเพียงตัวอย่างบางส่วน แต่คุณควรทำความเข้าใจหลักการของ SOLID สิ่งเหล่านี้ใช้ได้กับระบบและภาษาการเข้ารหัสใด ๆ

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

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

6. ทดสอบปลั๊กอินของคุณล่วงหน้า

ฉันเรียนรู้บทเรียนนี้อย่างหนัก การขาดการทดสอบทำให้ฉันต้องเปิดตัวปลั๊กอินเวอร์ชันใหม่ที่มีข้อผิดพลาดร้ายแรง สองครั้ง. ทั้งสองครั้ง ฉันได้รับคะแนน 1 ดาว ซึ่งฉันไม่สามารถเปลี่ยนเป็นรีวิวเชิงบวกได้

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

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

ยิ่งคุณลงทุนทดสอบปลั๊กอินล่วงหน้ามากเท่าไร ก็ยิ่งช่วยคุณประหยัดได้มากเท่านั้นในระยะยาว

ในการเริ่มต้นการทดสอบอัตโนมัติ คุณสามารถใช้คำสั่ง WP-CLI \\`wp scaffold plugin-test\\` ซึ่งจะติดตั้งการกำหนดค่าทั้งหมดที่คุณต้องการ

7. จัดทำเอกสารงานของคุณ

เป็นเรื่องโบราณที่นักพัฒนาไม่ชอบเขียนเอกสาร เป็นส่วนที่น่าเบื่อที่สุดของกระบวนการพัฒนา แต่ก็ไปได้ไกล

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

อีกวิธีในการโค้ดเอกสารคือการใช้ "doc block" ซึ่งเป็นความคิดเห็นสำหรับทุกไฟล์ ฟังก์ชัน และคลาส หากคุณเขียนวิธีการทำงานของฟังก์ชันและหน้าที่ของฟังก์ชัน คุณจะเข้าใจได้ง่ายขึ้นมากเมื่อคุณต้องการแก้ไขจุดบกพร่องในหกเดือนต่อจากนี้ WordPress Coding Standards ครอบคลุมส่วนนี้โดยบังคับให้คุณเขียนบล็อกเอกสาร

การใช้เทคนิคทั้งสองนี้จะช่วยคุณประหยัดเวลาในการเขียนเอกสาร แต่ทุกคนจะไม่อ่านเอกสารรหัส

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

บทสรุป

กฎทั้งเจ็ดนี้ช่วยให้ฉันพัฒนาผลิตภัณฑ์คุณภาพดี ซึ่งกำลังเริ่มเป็นธุรกิจหลักที่ BracketSpace ฉันหวังว่าพวกเขาจะช่วยคุณในการเดินทางด้วยปลั๊กอิน WordPress เช่นกัน

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