วิธี Coding อย่างไรให้ไร้ Bugs บน ​WordPress

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

 

Bug = ค่าใช้จ่าย เสียเวลา เสียความน่าเชื่อถือ

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

 

Bug ในที่นี่หมายถึงอะไร

Bug ในที่นี่พูดถึง ฟังก์ชั่น ความสามารถ และการแสดงผลของเว็บไซต์ เช่น ใส่ข้อมูล Contact Form แล้วกดไม่ไป หรือ การแสดงผล Responsive แล้วแสดงผลไม่ถูกต้อง Element ใหญ่ไปทำให้ล้นออกมาอีกบรรทัดนึง เป็นต้น และที่สำคัญ คือ “แก้ Bug ก่อนที่ลูกค้าจะเห็น”

 

สร้างรากฐานที่มั่นคง

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

 

ใช้หลักการ Engineering

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

 

ใช้ Plugins / Themes

การใช้ Plugins / Themes  ที่ใช้งานอยู่เป็นประจำทำให้ทำงานง่าย โดยที่เมื่อคุณรู้ว่าปัญหาที่เคยเกิดขึ้นกับไซต์นี้ แล้วไปเกิดกับไซต์อื่นๆ คุณก็สามารถแก้ปัญหาได้อย่างง่ายดาย เพราะเคยแก้มาแล้ว โดยไม่ต้องค้นหาให้เสียเวลา คุณ Mike บอกว่า “เค้าทำงานมา 5 ปี ถ้าคุณพูดชื่อ URL กับชื่อเว็บไซต์ที่เค้าเคยทำ เค้าจะรู้ทันทีว่าปัญหาที่เกิดขึ้นคืออะไร เพราะว่าผมใช้ Plugins / Themes ที่ใช้งานอยู่เป็นประจำ และปัญหาที่เคยเกิดขึ้นมาแล้ว”

 

Dev Tools

  • WORDPRESS STANDARDS – เป็น Best Practice ในการเขียน PHP, JS, CSS, HTML มาตรฐานของ WordPress เอง
  • 10UP ENGINEERING STANDARDS – Best Practice ของ 10UP Engineer
  • INPSYDE STANDARDS – เป็นมาตรฐานของบริษัท INPSYDE

 

Content / Post นั้นสำคัญไฉน

ถ้าเราทำโครงเปล่าๆ ที่ไม่มี Content ไปให้ลูกค้า เราจะไม่ทราบเลยว่า ถ้าใส่ Post เข้าไปหน้าตาจะออกมาเป็นอย่างไร อาจจะมีการตีกลับมาได้ กลายเป็นเหมือนลูกค้าเป็นคนทดสอบให้เราโดยการใส่ Content เพราะฉะนั้นทุกครั้งที่มีการทดสอบเว็บไซต์ต้องใส่ Post เข้าไปเสมอ ลองใส่ข้อมูลเข้าไปให้หมดทุกอย่าง รูป แท็ก Table Element ต่างๆ เราจะพบ Bug ก่อนที่ลูกค้าจะเจอก็เป็นได้… (ทำเสียงคนอวดผี)

 

ทดสอบเว็บไซต์ด้วย ข้อมูลจริง

หลายๆ ครั้งที่มาใส่ Dummy Text หรือ นั่งมโนว่ามันน่าจะเป็นอย่างนั้น อย่างนี้ แต่ข้อมูลจริง ข้อมูลอาจจะทะลุหน้าต่างจอ หรือดันตกบรรทัด ถ้าเราใส่กับข้อมูลจริง อาจจะทำการปรับ size ต่างๆ ให้ออกมาสวยงาม เหมาะสม

 

Content Tools

  • TEST CONTENT LIBRARY – อันนี้เป็นปลั๊กอินที่คุณ Mike สร้าง แค่กดใช้งาน ก็จะทำการ Insert Post 50-60 Posts กับ Insert Category 60 Row ประหยัดเวลาได้มากโข
  • THEME UNIT TEST – อันนี้เป็นการทดสอบ Theme จะทำการลง เช่น Sample Menu ลึกลงไป 10 Level. หรือ Element แปลกๆ เท่าที่จะนึกออก

 

Unit Test

ทดสอบส่วนที่เล็กที่สุดของเว็บไซต์ ทำการเขียน Code เพื่อมาทดสอบ Code คือ Code แบบ Inception ข้อดีคือ ถ้าลูกค้าจะเปลี่ยนอะไรบน Production เราสามารถทดสอบและเห็นผลลัพธ์หรือ Bug ก่อนที่จะ Push ขึ้นไปยังเว็บไซต์ของลูกค้า

 

Unit Test Tools

  • WP MOCK – สามารถเลียนแบบ Core Function ของ WordPress แล้ว มาทดสอบใน Unit Test ได้
  • WP FACTORY

 

Code Audit

  • ความปลอดภัย – การส่งตัวแปรต่างๆ ได้ทำการ Escape หรือ Sanitize ก่อนที่จะส่งเข้าไปใน DB ก่อนหรือเปล่า
  • Code อ่านง่าย – ถ้า Dev คนใหม่มา สามารถทำความเข้าใจได้ง่าย หรือเรากลับมาแก้ในภายหลัง ก็ยังทำความเข้าใจได้ง่าย
  • ความรัดกุม – เขียนด้วยความระมัดระวัง และไม่มีผลกระทบในภายหลัง

 

Code Audit Tips

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

 

Automate Code Review Tools

Tools ข้างบนจะเป็นตัวช่วย Review Code แบบ Automatic แค่เอา Repository ไปผูกไว้  Push ขึ้นไปผลลัพธ์ก็จะแจ้งออกมา โอ้โหไก่ย่าง มันสุดยอดมาก แต่มันเสียตังค์ครับ

 

นอกเหนือจากนั้น

  • Checklist วิธีนี้ที่ผมใช้บ่อยๆ แล้วทีมสามารถดู Progress ได้ด้วยว่าเราทำหรือยัง เป็นวิธีเบสิค ที่ใครๆ ก็ใช้ได้ครับ
  • Browser Test ทดสอบผลลัพธ์จากทุก Browser ทุกเวอร์ชั่น
  • Device Lab เอามือถือ เทปแลต จริงๆ มาทดสอบ อันนี้ลงทุนค่อนข้างเยอะ แต่ก็ยังมีวิธีโดยใช้เว็บ https://www.browserstack.com/ ครับ

 

การทดสอบภายใน

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

Me -> Dev -> PM -> Designer

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

 

ติดตามสถานะการทำงาน

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

 

อันนี้คือลิงค์ที่คุณ Mike Selander พูดเกี่ยวกับหัวข้อนี่เอาไว้นะครับ ถ้าใครสนใจไปกดติดตามเค้าได้

ส่วนอันนี้เป็น Slide ครับ

http://mikeselander.com/presentations/world-without-bugs/#/

Comments

Tagged , , , , ,
shares