Videos → A journey of building large scale reusable web components

เกริ่นนำ: ปัญหา UI ไม่สอดคล้องกันในระบบขนาดใหญ่0:00

เรามาเริ่มกันเลยแล้วกันค่ะ section แรกของเรานะคะ ถ้าเกิดว่าระบบของเราใหญ่ขึ้นเนี่ย เชื่อว่าหลายท่านอาจจะสงสัย เอ๊ะ เราจะต้องเจอกับปัญหาอะไรบ้าง แก้ไขยังไง เพราะฉะนั้นเราจะมาพูดคุยกันในหัวข้อนี้นะคะ A Journey of Building Large Scale Reusable Web Components ค่ะ โดยคุณวรายุทธ เลิศกลยานวัฒน์นะคะ เป็น software development engineer จาก Amazon ที่เยอรมนีนะคะ So first section is going to be the topic of A Journey of Building Large Scale Reusable Web Components by Mr. Varayut Lerdkanlayanawat, software development engineer from Amazon Germany. Please a big round of applause to welcome him.

แนะนำวิทยากรและหัวข้อบรรยาย0:53

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

ระบบ AWS และปัญหา UI ที่ไม่สอดคล้องกัน1:26

ครับ ผมชื่อวรายุทธ เลิศกลยานวัฒน์นะครับ ก็ตอนนี้ก็เคยทำงานที่บริษัท Amazon เป็น software development engineer นะครับ ตอนนี้ก็กลับมาไทยแล้วครับ แล้วก็เป็น consult เป็น trainer ด้าน web development ครับ ก่อนอื่นเลยผมอยากให้ทุกคนมาดูตัวระบบ AWS นะครับ หรือว่า Amazon Web Services ซึ่งเป็นระบบ cloud ที่ใหญ่มากๆของ Amazon นะครับ หรือว่าใหญ่ที่สุดในโลกเลยก็ว่าได้ โดย Amazon เนี่ยก็มีระบบ cloud เยอะแยะมากมายครับ ที่ provide ให้กับผู้ใช้งานได้ใช้นะครับ แต่ว่าระบบที่ดังๆที่เราอาจจะรู้จักกันก็จะมีอย่างเช่น ระบบ Lambda ใช่มั้ยครับ ที่ทำให้เราสามารถที่จะ upload โค้ดแล้วก็ run โค้ดของเราได้ โดยที่ไม่ต้องใช้ตัว server เลยนะครับ อีกระบบนึงก็คือระบบ S3 เป็นระบบคล้ายๆกับ Dropbox หรือว่า Google Drive นะครับ ทำให้เราสามารถ upload ไฟล์ขึ้นไปได้

การเติบโตของ AWS และผลกระทบต่อ UI2:22

ถึงแม้ว่า Amazon จะมีระบบ cloud ต่างๆมากมายครับ แต่ว่าทุกๆปีนั้น Amazon ก็มีการซื้อระบบต่างๆเข้ามา

นะครับ โดยในปี 2019 เนี่ยครับ ก็มีระบบต่างๆที่ Amazon ซื้อเข้ามาประมาณ 10 บริษัทใหญ่นะครับ ยังไม่รวมบริษัทย่อยๆอื่นๆ โดย Amazon หวังว่าการที่ซื้อบริษัทต่างๆเข้ามานะครับ ก็เพื่อที่จะให้พัฒนาความพึงพอใจนะครับ ให้ลูกค้าเนี่ยมีความพึงพอใจสูงขึ้น แต่ว่า feedback ที่ได้รับครับ กลับเป็นไปในทางตรงกันข้ามนะครับ โดยอันนี้เป็น webboard webboard นึงที่ดังมาก ในต่างประเทศ กลับมีคนบ่นว่าทำไมระบบ AWS มันถึงไม่ค่อยดีเลยนะครับ

โดยหนึ่งใน comment อันนั้นที่มีคน comment ไว้นะครับ ก็บอกว่า เนื่องจาก Amazon นะครับ ใช้ระบบทีมแบบ two-pizza team นะครับ ก็คือถ้าทีมไหนที่ใหญ่เกินกว่าที่จะกินพิซซ่า 2 ถาดอิ่ม แล้วนะครับ เขาก็จะแตกเป็นทีมย่อยๆนะครับ ผลสุดท้ายก็คือ เรามีทีมย่อยๆเยอะแยะมากมายเลย แล้วแต่ละทีมนั้นก็ทำตัว product ของตัวเองนะครับ แล้วก็ดีไซน์ UI ของตัวเอง สุดท้ายแล้วแต่ละ service เนี่ยก็มี UI ที่แตกต่างกันมากนะครับ

ตัวอย่างปัญหา UI ของ Lambda และ S33:40

เดี๋ยวเรามาลองดูนะครับว่าจริงมั้ยนะครับ ตัวที่ customer complain เข้ามานะครับ โดยเราจะมาดู Lambda กับ S3 ที่เราพูดถึงกัน ซึ่งตัว Lambda นะครับ ก็คือถ้าสมมุติเราลองดูที่ตัว

หน้าจอจะเห็นว่าตัว Lambda เนี่ยจะออกเป็นธีมสีส้ม ใช่มั้ยครับ ส่วนตัว S3 จะออกเป็นธีมสีน้ำเงินนะครับ ถ้าสมมุติผมลองเอา 2 ระบบนี้นะครับมาเปรียบเทียบกัน จะเห็นว่า ขอโทษนะครับ ก็จะเห็นว่าตัว 2 ระบบเนี้ย มันค่อนข้างแตกต่างกันมากนะครับ โดยถ้าสมมุติเราสังเกตตรงเมนู ตรง button ด้านบนนะครับ ตัว Lambda เนี่ยก็จะมีปุ่ม create ซึ่งวางไว้ด้านขวาบนใช่มั้ยครับ ส่วน S3 จะวางปุ่ม create ด้านซ้ายแล้วก็เป็นสีน้ำเงิน แถมยังมี icon ด้วยนะครับ นอกจากนั้นนะครับก็ยังมีตัว breadcrumb ด้านบน ซึ่ง breadcrumb ด้านบนนั้นจะของ Lambda เนี่ย ก็คือเป็นลิงก์ใช่มั้ยครับ สามารถคลิกได้ ส่วนของ S3 เนี่ยก็จะเป็น text ธรรมดา คลิกไม่ได้นะครับ แล้วนอกจากนั้นสุดท้ายแล้วก็คือด้านข้างจะเป็น navigation ใช่มั้ยครับ โดยถึงแม้ว่าทั้ง 2 ระบบเนี้ยมันคล้ายกันมากนะครับ แต่ว่าก็ยังมีการทำงานที่แตกต่างกันอยู่ดีนะครับ ซึ่งสิ่งเหล่านี้เองครับก็ทำให้ user complain เข้ามานะครับ

ปัญหาเรื่องสีและ Accessibility5:05

ทีนี้ผมลองพูดถึงเรื่องสีไปในระดับนึงใช่มั้ยครับ เดี๋ยวผมจะลองมาเจาะลึกเรื่องสีเพิ่ม โดยถ้าสมมุติผมคลิกตัว create bucket นะครับ มันก็จะขึ้นตัว pop-up ขึ้นมา แล้วตัว pop-up นี้นะครับด้านขวาเนี่ยมันก็จะมี field ให้กรอกซัก 3 field ใช่มั้ยครับ แต่ว่าตรง field bucket name จะมี icon เล็กๆอันนึง ซึ่งมันเล็กมากครับก็มองไม่ออกว่ามันคืออะไรกันแน่ ถ้าสมมุติผมซูมเข้าไปนะครับก็จะเห็นว่ามันเป็นเหมือน icon เหมือน information นะครับ

โดยที่ contrast มันต่ำมากๆ มันเลยทำให้ตัวเนี้ยดูยากมากนะครับ ถ้าสมมุติผมลองไปดูตัว Web Content Accessibility Guidelines ที่เป็นตัวที่ระบุว่า contrast ratio ควรจะอยู่ที่เท่าไหร่นะครับ โดยตัว contrast ratio เนี่ยมีอยู่ 2 level ก็คือ double A แล้วก็ triple A โดย double A เป็น minimum contrast ที่ต้องมีค่าอย่างต่ำคือ 4.5 แล้วก็

Triple A เนี่ยก็ต้องมีค่าอย่างต่ำ 7 นะครับ โดยถ้าสมมุติผมลองเช็คตัวไอคอนตัวนี้ที่เราพูดถึงนะครับ โดยใช้ inspect element ใช้ Chrome DevTools แล้วก็เราก็คลิกตัว color ที่อยู่ด้านขวา มันจะขึ้นเป็น color picker ขึ้นมานะครับ แล้วใน color picker นี้มันก็จะบอกว่า ตัว contrast ของ element ตัวนี้นะครับมีค่าเท่าไหร่ โดยค่าที่ปรากฏออกมาก็คือ 1.98 นะครับ ซึ่งต่ำมากๆ ดังนั้น คนที่เป็นคนที่มีปัญหาด้านสายตา

หรือว่าคนตาบอดสีนะครับ อาจจะมองไม่เห็นปุ่มปุ่มนี้เลยก็ได้นะครับ

ปัญหาการใช้งานคีย์บอร์ด6:40

นอกจากเรื่องสีที่เราพูดไปแล้วครับ ก็ยังมีอีกเรื่องนึงคือเรื่องการใช้งานคีย์บอร์ด user ส่วนใหญ่ครับ โดยเฉพาะคนที่เป็น developers หรือว่าคนที่ใช้งาน AWS นะครับ เค้าไม่อยากที่จะใช้งานเมาส์นะครับ

เค้าบางคน prefer ที่จะใช้ตัวคีย์บอร์ดมากกว่า ถ้าสมมุติผมลองกด tab ครั้งแรกนะครับในหน้า S3 มันก็จะโฟกัสตัว input fields อันนี้คือโฟกัสถูกต้องใช่มั้ยครับ ถ้าสมมุติผมกด tab อีกครั้งนึง ผมคาดหวังว่ามันควรจะไปโฟกัสที่ dropdown ด้านขวา แต่ว่าพอผมกด tab แล้วนะครับ มันกลับไปโฟกัสที่ตัว create bucket อันนี้หมายความว่าถ้าสมมุติคนที่ต้องการใช้งานคีย์บอร์ด เค้าจะไม่มีทางที่จะเลือกตัว dropdown ได้เลยนะครับ อันนี้เป็นปัญหามากๆ นะครับ สำหรับผู้ใช้งาน

ความสำคัญของสีและการใช้งานคีย์บอร์ดที่ดี7:30

ดังนั้นเวลาเราดีไซน์ระบบนะครับ

สีเนี่ยครับเป็นเรื่องที่สำคัญมากๆ แล้วก็นอกจากสีที่ดีนะครับ นอกจากจะทำให้คนทุกคนสามารถเข้าใช้งานแอปพลิเคชันเราได้แล้ว สีนั้นยังทำให้บริษัทสามารถสร้าง branding ของตัวเองได้ด้วย นอกจากนั้นเวลาเราสร้างตัวแอปพลิเคชัน feature อะไรก็แล้วแต่นะครับ เราต้องใช้งานตัวคีย์บอร์ด เราต้องลองเทสต์ดูว่าคีย์บอร์ดทำงานได้เหมือนเมาส์หรือเปล่า ซึ่งถ้าเราทำ 2 อันนี้ได้ดีนะครับ เราก็สร้าง customer satisfaction ทำให้ customer พึงพอใจมากยิ่งขึ้นนะครับ

ต้นทุนของการพัฒนา UI ซ้ำซ้อน8:09

เมื่อกี้เราดูไปใช่มั้ยครับว่า เรา 2 ระบบเนี่ยมันมีปุ่มที่แตกต่างกัน มี side navigation ที่แตกต่างกัน นั่นหมายความว่า 2 ทีมเนี้ยครับ ก็ต้องทำการดีไซน์แล้วก็ทำการ develop ตัวปุ่ม 2 ปุ่มนี้แยกกันนะครับ ทำการ develop side navigation แยกกัน ถ้าสมมุติผมลองคำนวณ cost เล่นๆ นะครับ ของการ develop แล้วก็ดีไซน์ตัว feature เหล่านี้นะครับ ผมลองคิดว่าถ้าสมมุติการดีไซน์ feature เหล่านี้ ใช้เวลาประมาณครึ่งเดือนซึ่งถือว่าเร็วมากๆ หรือประมาณ 90 ชั่วโมงนั่นเอง แล้วก็ cost ในการดีไซน์ต่อชั่วโมง ผมคิดว่าสมมุติให้เป็น 60 ดอลลาร์นะครับ แล้วแต่ละทีมเนี่ยก็ต้องดีไซน์ feature เหล่านี้ซ้ำๆ ใช่มั้ยครับ ถ้าสมมุติว่าทุกทีมมี 5 ทีมหรือ 5 product ที่ต้องดีไซน์ feature เหล่านี้ซ้ำๆ อันนี้ก็จะใช้ cost สูงมากนะครับ หรือประมาณ 27,000 ดอลลาร์หรือประมาณ 800,000 บาท ซึ่งถือว่าสูงมากเลยใช่มั้ยครับ ดังนั้นครับ การดีไซน์ feature อะไรก็แล้วแต่ซ้ำๆ นอกจากจะสิ้นเปลืองพลังงาน สิ้นเปลือง resource ของบริษัทแล้วนะครับ ก็ยังทำให้ UI นั้นมีความแตกต่างกัน แล้ว user ก็จะใช้งานยากอีกด้วยครับ

แนวคิดการสร้าง Components เพื่อแก้ปัญหา9:25

ดังนั้นครับ เราควรที่จะมาสร้าง components

ให้กับบริษัทของเราให้ทุกทีมสามารถ share components ร่วมกันได้ ตอนนี้คำถามแรกครับ สำหรับทุกคนอาจจะถามว่า ถ้าสมมุติเราต้องการเริ่มสร้าง components เราต้องใช้ frameworks หรือว่า libraries อะไรนะครับ

การเลือก Framework ที่เหมาะสม: React, Vue และ Web Components9:45

โดย framework ตัวแรกที่ผมนึกถึง สิ่งที่ผมทำก็คือผมเข้าไปใน npm trends ครับ แล้วก็ดูว่า framework ที่ดังๆ อย่างเช่น React, Angular, Vue

ตัวไหนที่มีคน install เยอะที่สุดในรอบ 2 ปีที่ผ่านมานะครับ ก็จะเห็นว่ากราฟสีน้ำเงินเป็นตัว React นั่นเอง ดังนั้น React จึงเป็น framework ตัวแรกครับ ที่ผมนำมาใช้ในการสร้างนะครับ แต่ว่าต่อมาครับ พอผมสร้าง components แต่ละทีมได้ใช้งานแล้ว ต่อมาผมก็พบว่ามีทีมบางทีมครับในบริษัท ที่พอ Vue มันเริ่ม popular มากขึ้น เค้าก็ให้มาใช้ Vue แทนที่จะใช้งาน React แปลว่าตอนนี้ครับผมต้องสร้าง components อีกชุดนึง เพื่อมา support ตัว Vue นะครับ กลายเป็นว่าตอนนี้ผมต้องมี components 2 ชุด ที่ support ตัวนึง support React อีกตัวนึง support Vue เพราะว่ามันไม่สามารถ reuse ร่วมกันได้ จึงเกิดเป็นคำถามครับว่าจะมีวิธีไหนมั้ย ที่เราสามารถที่จะ reuse ตัว components เหล่านี้ได้นะครับ โดยที่เราเขียนครั้งเดียวเราสามารถใช้งานได้ในทุก framework ก็จากการทำ research ครับ ก็ไปพบตัวนึงชื่อว่า web components โดย web components เนี่ยทำให้เราสามารถที่จะเขียนโค้ดครั้งเดียว จากนั้นนะครับเราสามารถที่จะใส่ได้ เอาไปใส่ใน framework ต่างๆ นะครับ แล้วมันก็สามารถทำงานได้โดยที่เราไม่ต้องเขียนใหม่ ผมก็ทำการเทสต์ครับ กับ browser หลักๆ

อย่างเช่น Chrome, Firefox, Safari ตัว web components นี้ก็ทำงานได้ดีนะครับ

ปัญหา Web Components กับ IE และทางแก้11:20

แต่ว่า มีอยู่ browser นึงครับที่มักจะมีปัญหามากกว่าเพื่อน โดยผมจะไม่กล่าว ไม่บอกดีกว่านะครับว่าคือ browser อะไร ตอนนี้นะครับความรู้สึกผมก็คล้ายๆ กับรูปภาพรูปภาพนึงครับ

เราต้องการใช้ web components มากเลย แต่ว่าเรายังมี IE นะ

ผมก็เลยไปหาวิธีแก้ครับ ลองทำ research ต่อว่าจะมีวิธีไหนมั้ย ที่เราสามารถที่จะทำให้ตัว web components เนี่ย สามารถ run บน IE ได้ ผลปรากฏว่าสิ่งที่ผมเจอครับ ก็คือเป็น polyfill ตัวนึงชื่อว่า web-component-polyfill ที่เราสามารถเอาไป drop ในตัว source code ของเรา จากนั้นมันจะทำให้ code ของเราเนี่ย run บน IE ได้ครับ แต่ว่าตัว polyfill ตัวนี้ก็ยังมีปัญหาต่างๆ ตัวอย่างเช่น ปัญหาที่สำคัญมากๆ เลยครับ ก็คือ CSS encapsulation นะครับ

เป็นการที่ปกติแล้วตัว web components เนี่ย มันจะ encapsulate ตัว CSS ไว้นะครับ ทำให้ตัว CSS ภายนอกเนี่ยไม่สามารถมีผลกระทบต่อ CSS ของ component ของเรา แต่ว่าตัว polyfill เนี่ยทำไม่ได้ นั่นหมายความว่าถ้าเราสร้าง components แล้วมีทีมอื่นๆ ที่นำไปใช้งาน ตัว CSS ของเค้าอาจจะ conflict กับตัว CSS ของ web components ของเรานะครับ

การใช้ Pure JavaScript และ Wrapper12:47

สุดท้ายแล้วผมต้องทำการ support IE ด้วย ตัวเลือกสุดท้ายครับ อาจจะต้องใช้ pure JavaScript หรือว่า vanilla JavaScript

ซึ่งเราต้องเขียนเป็น component definitions ขึ้นมา จากนั้นครับเราก็สร้าง wrapper ของแต่ละ framework มา wrap ตัว component definition ตัวนี้นะครับ แล้วทำให้มันใช้งานได้กับ framework เหล่านั้นครับ

โดยวิธีนี้แน่นอนว่าเราเป็นคนควบคุมทุกอย่างครับ มัน flexible มากๆ ดังนั้นเราจะสามารถทำให้มัน support ในทุก browser ได้ ดังนั้นครับข้อสรุปของการเลือก framework ถ้าทีมเรามีขนาดไม่ใหญ่มากนะครับ เราก็สามารถที่จะเลือก framework ที่ทีมทุกทีมในบริษัทเนี่ยใช้งาน แต่ว่าถ้าสมมุติทีมเรามีขนาดใหญ่ขึ้นมา แล้วก็มีใช้งาน framework หลายตัวนะครับ เราอาจจะใช้เป็น web components แต่ก็ต้องดูด้วยว่าเราต้อง support IE มั้ย ถ้าทีมเรามีขนาดใหญ่มากครับ แล้วก็ทีมแตกต่างกันมาก เราอาจจะต้องสร้างเป็น component definitions โดยใช้ pure JavaScript จากนั้นเราก็สร้าง wrapper ในการ wrap นะครับ

นอกจากตัว framework ที่เราได้มาแล้วนะครับ

การออกแบบ API ของ Component: Flexible vs. Rigid13:56

เราก็ต้อง คำถามต่อไปก็คือ แล้วเราจะ design ตัว API หรือตัว properties ของ component อย่างไร การ design API นะครับ วิธีแรกที่ผมคิดเลยก็คือ ผมต้อง support ทีมเป็นจำนวนมากใช่มั้ยครับ ดังนั้นจะทำยังไงก็ได้ให้ component ของเราเนี่ย สามารถที่จะใช้งานได้ในทุกกรณีนะครับ ผมจึงเลือกแบบ API ในรูปแบบของ flexible สมมุติว่าเรามีปุ่มขึ้นมาปุ่มนึง ในปุ่มนี้นะครับเราก็จะมี style เป็น property ของปุ่มของเรานะครับ โดยผมรับเป็น object จากนั้นก็ pass ตัว style property ตัวนี้ครับ เข้าไปในปุ่มนะครับ

หลังจากนั้นครับ ตอนนี้คือเรา pass ทั้ง object เข้ามาเลย ไม่ว่า user จะใส่ CSS เป็นอะไร เราก็ pass เข้าไปใน button ผลปรากฏว่าพอทีมใช้งานครับ แรกๆ ก็ยังใช้ได้ดีอยู่ เค้าก็ pass เป็น color เป็น background เข้ามา เค้าก็ได้ปุ่มออกไปนะครับ จากนั้นครับ ก็พอมีทีมใช้งานมากขึ้น ปรากฏว่าก็มีทีมที่มี creativity สูงขึ้นใช่มั้ยครับ เค้าก็ pass ตัว border-radius ทำให้ปุ่มนั้นมันโค้งมนมากขึ้นนะครับ พอมีทีมใช้งานขึ้นอีก เพิ่มขึ้นอีกนะครับ ก็ได้ปุ่มสีเหลือง สุดท้ายครับเราได้ปุ่มแบบนี้เลย

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

จากการที่ทำเป็น flexible ผมทำเป็นรูปแบบ rigid คือทำให้มันเข้มงวดมากขึ้นนะครับ โดยรูปแบบ rigid จากตอนแรกที่รับเป็น style เป็น property object เข้ามานะครับ ตอนนี้ผมรับเป็น variant ซึ่งรับแค่ primary secondary success แล้วก็ danger โดยผู้ใช้งานเนี่ยไม่สามารถ pass ค่าอื่นๆ เข้ามาได้ นอกจากค่าเหล่านี้ แล้วผมก็ pass ค่านี้นะครับเป็น class name ให้กับ button แล้วก็ใช้ CSS ของเราในการใส่ style เข้าไป

โดยวิธีนี้นะครับก็ทำให้การทำงานเนี่ย มันง่ายมากขึ้นนะครับ การที่เราสมมุติในอนาคตเราจะ add API ตัวไหนเพิ่มเข้าไป เราไม่จำเป็นต้องกลัว breaking change ใช่มั้ยครับ เพราะว่าถ้าสมมุติเราใช้รูปแบบ flexible ถ้าสมมุติเรา add API ตัวไหนเข้าไป เราจะกังวลมากเลยว่า ถ้าสมมุติผู้ใช้งานเนี่ยใส่ style เข้ามา API ใหม่ที่เรา add เข้าไปอาจจะไป conflict กับตัวนั้นได้ แต่การที่เราทำ component ให้เล็กๆ เริ่มจากเล็กๆ ก่อน แล้วค่อยๆ เพิ่ม feature เพิ่ม API ขึ้นมา มันจะปลอดภัยมากกว่า แล้วก็เราจะสามารถ maintain ตัว component ของเราได้ง่ายกว่าครับ

ความสำคัญของการทดสอบ Component16:44

สุดท้ายแล้วครับ พอเราได้ component ของเรามาแล้ว ได้ เรา design API แล้วก็สร้าง component ออกมา สุดท้ายเราก็ต้องทำการ test ใช่มั้ยครับ

โดย component ของเราเนี่ยเราต้องมั่นใจว่า ตัว component มี quality ที่สูงกว่า product quality ของบริษัท นั่นหมายความว่า ถ้าทีมในบริษัทนำ component ไปใช้ เราจะมั่นใจว่า component ของเราเนี่ย ไม่ทำให้ product quality ของบริษัทนั้นต่ำลงนะครับ อันนี้เป็นสิ่งที่เรา make sure ได้ว่า คนที่นำไปใช้เนี่ยเค้าจะมั่นใจที่จะนำ system ของเราไปใช้ ถ้าไม่อย่างงั้นตัวของเราเนี่ย ก็จะไม่มีใครนำไปใช้นะครับ

ตัวอย่างปัญหาและการใช้ Screenshot Test17:23

ถ้าสมมุติผมลองดู feature ตัวนึง

ซึ่งก็คือเป็น search bar ซึ่ง feature ตัวนี้ครับประกอบไปด้วย ตัว component 2 ตัวนะครับ ก็คือ input field กับ button ถ้าสมมุติผมดู CSS ของตัว button นะครับ ก็จะสังเกตว่าตัว button เนี่ย ก็จะมี color background-color แล้วเราก็ set border เป็น none นะครับในตอนนี้ คราวนี้ผมก็ลอง test ตัว feature นี้ครับ โดยการใช้ test ที่เราคุ้นเคยกัน unit test integration test แล้วก็ test อื่นๆ ต่อมาครับ designer ก็นำตัวนี้ไป test ผลปรากฏว่าตัว accessibility test นั้นไม่ผ่าน เนื่องจากพอเค้ากดตัว tab 2 ครั้งครับ เค้าก็ไป focus ที่ตัว search field แต่ผลปรากฏว่าตัว search field เนี่ย มันไม่ขึ้นตัว outline หรือว่า border นะครับ ทำให้ user เนี่ยไม่สามารถรู้ได้ว่า ตอนนี้ focus อยู่ตรงไหนแล้ว ก็คืนนั้นเองครับ ก็ designer ก็บอก developer แล้ว developer ก็ทำการเปลี่ยนแปลง code นะครับ โดยเค้า add ตัว border เข้าไป 1 pixel

เป็นสีฟ้าอ่อนครับ คราวนี้ designer ก็มาลอง test ใหม่ ตอนที่ designer test ใหม่ครับ ก็กด tab 2 ทีแล้วก็ไป focus ตอนนี้นะครับมันก็จะขึ้นเป็นคล้ายๆ กับ ตัว outline border สีฟ้าอ่อนแล้วนะครับ จะสังเกตว่ามันเล็กน้อย มันบางมากเลยใช่มั้ยครับ มันมองไม่ค่อยเห็น คราวนี้ครับ developer ก็ทำการ deploy code แล้วก็เข้านอนครับ

คราวนี้คืนนั้นเอง เขาก็โดนเรียกครับ โดนโทรเรียก

เราก็ต้องตื่นขึ้นมาครับ เหตุผลก็คือ ตัว component ที่ deploy ไปมันใช้งานไม่ได้ มันทำให้ฟอร์มของบริษัทเนี่ย ของ product บาง product มันขยายทั้งหมดนะครับ คราวนี้ developer ก็ต้องตื่นมาดูครับว่าเกิดอะไรขึ้น

อันนี้คือฟอร์มก่อนที่เราจะ add ตัว border เข้าไปนะครับ สังเกตตรงปุ่มจะยังไม่มีตัว outline ตัว border ของเรา แล้วก็ตัวนี้นะครับก็คือเป็นตัวฟอร์มที่เรา add border

เข้าไปแล้วนะครับ ก็จะมี outline อยู่นิดนึง ซึ่งมันเล็กน้อยมากๆ ถ้าเราดู 2 ตัวนี้นะครับ เราแทบจะมองไม่เห็นเลยใช่มั้ยครับว่ามันแตกต่างกันยังไงบ้าง โดยจริงๆแล้วเนี่ย สิ่งที่มันแตกต่างกัน ถ้าสมมุติผมดูสไลด์ก่อนกับอันนี้นะครับ จะเห็นว่ามันเหมือนขยายขึ้นมา 1 pixel ใช่มั้ยครับ เนื่องจาก border ที่เรา add เข้านั่นเอง ถึงแม้ว่าตัว component เหล่านี้จะมี test ต่างๆ ที่เราใช้งานตอนแรกๆแล้วนะครับที่เราใส่เข้าไป แต่ว่า test เหล่านี้เนี่ย ไม่สามารถที่จะจับ bug ตัวนี้ได้ เนื่องจาก function search ก็ยังใช้งานได้อยู่นะครับ ทุกอย่างใช้งานได้ตามปกติ

Percy: Tool สำหรับ Screenshot Test20:28

แต่ว่ามี test อยู่ตัวนึงครับที่จะเป็นประโยชน์มากๆ ในการสร้าง components แล้วมาจับ bug นี้ เราเรียกว่า screenshot test หรือว่าหลายคนเรียกว่า visual regression test นะครับ

โดย tool ที่ผมใช้ครับก็คือชื่อว่า Percy เป็น tool ที่เราสามารถที่จะ run ตัว command line จากนั้น tool ตัวนี้ครับก็จะ take screenshot ของหน้า UI ของเรา แล้วก็อัพโหลดขึ้นไปบนระบบ ตอนนี้จะเห็นว่าตัวลูกศรสีเขียวนะครับที่ชี้ ก็คือเป็น UI ของเราก่อนที่จะทำการเปลี่ยนแปลงโค้ด หลังจากนั้นครับ พอได้ requirement มา developer ก็ add border เข้าไป แล้วก็ทำการเรียกใช้ command ของ Percy อีกครั้ง

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

จากนั้นมันจะโชว์เป็นกรอบสีแดงๆนะครับ อันนี้ก็คือสิ่งที่เปลี่ยนแปลงไปจากเวอร์ชั่นก่อน อันนี้ทำให้เรามั่นใจได้ว่าเราสามารถมองเห็นได้ว่า สิ่งที่เราใส่โค้ดเข้าไปมันมีอะไรเปลี่ยนแปลงไปบ้างนะครับ อันนี้ก็คือ 1 pixel ที่เราใส่เข้าไปเป็น border นั่นเอง

นอกจาก Percy จะสามารถ run ผ่าน command line แล้ว เรายังสามารถ integrate กับตัว version control ได้ด้วย อย่างเช่น Git นะครับ ผ่าน GitHub เราก็สามารถที่จะเช็กได้ว่าถ้ามี pull request ส่งมา เราสามารถที่จะ run ตัว Percy ในการตรวจสอบได้ว่ามีอะไรที่เปลี่ยนแปลงใน UI มั้ย แล้วเราสามารถเข้าไปตรวจเช็กได้ครับว่า สิ่งที่เปลี่ยนแปลงไปนั้นตรงกับที่เราต้องการหรือเปล่า

การสร้าง Design System และ Community22:18

ดังนั้นครับ การทำ components ให้กับทีม

quality ของ components นั้นต้องสูงมากๆนะครับ โดยวิธีการทำให้สูงได้นั้น เราต้อง test ทุกอย่างให้ครอบคลุม และ test อันนึงที่ขาดไม่ได้เลยก็คือ screenshot test โดยการทำ component จริงๆแล้วนะครับ เราไม่จำเป็นต้องให้ทีมใดทีมหนึ่งมีหน้าที่ในการรับผิดชอบ ในการสร้าง components แต่เราควรจะสร้างครับ เป็น community ภายในบริษัทของเรา ที่หลายๆทีมมีส่วนร่วมในการ design แล้วก็สร้าง components พอเราสร้าง components ไปหลายๆตัวครับ สุดท้ายแล้วเราจะได้ component ที่เราสามารถ reuse ได้ภายในบริษัทของเรา ซึ่งจะประหยัดทั้งทรัพยากรด้านเวลา ด้านค่าใช้จ่ายนะครับ นอกจากนั้นเรายังมีเวลาในการ test ด้าน accessibility

ซึ่งสิ่งเหล่านี้ครับ เราจะเรียกมันว่า design system

Design System คืออะไรและตัวอย่างบริษัทที่ใช้23:19

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

สรุปและ Q&A23:54

อันนี้ก็คือประสบการณ์ที่ผมลองสร้าง components สร้างตัว design system ให้กับทีมมากกว่า 100 ทีมได้ใช้งาน ก็หวังว่าจะเป็นประโยชน์สำหรับทุกๆคนนะครับ ถ้าใครมีคำถามหรือว่าต้องการพูดคุย ก็สามารถมาเจอผมได้นะครับ สามารถเข้ามาถามได้ครับ ขอบคุณครับ ขอบคุณค่ะ ขอบคุณนะคะคุณวรายุทธนะคะ

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

After every section ladies and gentlemen, our speaker of each sections, they are he or she will be going out to the Q&A room. In the case you would like to talk to them personally or do you have any questions for them, please proceed to outside of this theater and turn right, you will see the Q&A room on the right hand side of the entrance. And please feel free to talk to them personally. Once you finish and then come back to listen for the next sessions, okay?