Videos → How I met my superset of JavaScript

แนะนำวิทยากรและหัวข้อ How I Met My Superset of JavaScript0:00

มาต่อกันเลยค่ะ ถัดไปก่อนจะไปพักเบรกทานอาหารกลางวันกันนะคะ ขอเชิญพบกับทางวิทยากรท่านนี้จะมาเล่าให้ฟังถึงเรื่องของการทำ TypeScript ค่ะ ในหัวข้อ How I Met My Superset of JavaScript นะคะ ขอเสียงปรบมือต้อนรับคุณสิริรัตน์ รุ่งเพชรรัตน์ CTO จาก Builk One Group Thailand สวัสดีค่ะ

ทำไม Builk One Group ถึงเลือก TypeScript0:36

ขอกลับมาที่หน้าแรกก่อนนะคะ

วันนี้ค่ะ ยุ้ยนะคะ มาจากบริษัท Builk One Group ค่ะ จะมาเล่าเรื่องราว love comedy แล้วกันค่ะ ถือว่ามันเป็น love comedy ในการ transition นะคะ จาก AngularJS มาเป็น TypeScript ค่ะ ตั้งชื่อมันว่า How I Met My Superset of JavaScript ใครเคยดู How I Met Your Mother คะ มันเป็นเรื่องราว love comedy ประมาณนั้นแหละค่ะ

สำหรับ talk นี้นะคะจะแบ่งออกเป็น 2 part part แรกเราจะลงกันเรื่อง technical ซักเล็กน้อยว่า ตอนที่ทำเนี่ย มันมีอุปสรรคอะไรนะคะ แล้วก็อีก part นึงจะเป็นเรื่องของการ convince ค่ะ ถ้าหากว่าเราอยากจะ transition เทคโนโลยีอะไรในบริษัทเรา เราจะพูดกับทุกคนที่อยู่ในบริษัทว่ายังไงนะคะ การเปลี่ยนเทคโนโลยีอะไรซักอย่างสำหรับยุ้ยแล้ว มันจะเหมือนกับการพาแฟนใหม่เข้าบ้านค่ะ ก็เราจะมีการพบรักกับแฟนคนใหม่ก่อนเนาะ ในขณะเดียวกันเราก็ยังมีเทคโนโลยีเก่าที่เป็นแฟนคนเก่า นั่งรอเราอยู่ที่บ้านเหมือนกัน แถมเรายังมีลูกๆ ที่ร่วมกันพัฒนามันขึ้นมา ก็คือเหล่า developer tester เท่านั้นยังไม่พอค่ะ เรายังมีคุณพ่อคุณแม่ของเรา คุณพ่อคุณแม่ของญาติของแฟนเราอีกต่างหากนะคะ ที่คอยพร่ำบอกเราว่าคนเก่าเนี่ยเป็นคนที่ดีขนาดไหน แล้วทำไมเราถึงไม่ควรเปลี่ยน

ข้อดีของ TypeScript: Strongly Typed, OOP, Compatibility, Open Source2:07

เพราะฉะนั้นเราไปเริ่มกันที่ part technical ก่อนดีกว่าค่ะ รักแรกพบนะคะ ครั้งแรกที่เราได้พบ TypeScript นะคะ ต้องบอกก่อนว่าสำหรับ Builk One Group เนี่ย เชี่ยวชาญเรื่องการใช้งาน AngularJS มาก

แล้วนอกจากเชี่ยวชาญเรื่องนั้นไม่พอ เรายังเชี่ยวชาญเรื่องการมี backend เป็น C# พอพูดอย่างงี้แล้วเนี่ย พอจะเข้าใจแล้วใช่มั้ยคะ ว่าทำไมเราถึงเลือก TypeScript มาเป็นอาวุธใหม่ของเรา มาเป็นแฟนคนใหม่ของเรา เพราะว่าเรามีความเชี่ยวชาญในการสร้างป้อมปราการค่ะ ทุกคนคงจะเคยชินดีว่าการสร้าง Angular application ขึ้นมาซักตัวนึงเนี่ย เหมือนการสร้างป้อมปราการ มันไม่ใช่ว่าจะขึ้นมากันได้ง่ายๆ มีเทคโนโลยี learning curve ที่ค่อนข้างเยอะพอสมควร สำหรับคนที่เป็นมือใหม่ เพราะฉะนั้นมันถึงเป็นสิ่งที่เราที่เป็นผู้พัฒนา application

ให้กับวงการก่อสร้างนะคะ แน่นอนแต่ละแอปมันตัวใหญ่มาก ERP ซักตัวอะไรอย่างเงี้ย ชอบมันมากๆ เพราะว่ามันบริหารจัดการและ maintain ได้ง่าย ก็ไม่ได้หมายความว่าตัวอื่นมันจัดการยากเนาะ นี่ก็เลยเป็นเหตุผลค่ะ ที่วันนึงน้อง solution architect ที่บริษัทค่ะ ตอนนี้ก็เป็น solution architect ที่อื่นแล้วนะคะ เขามาบอกว่า

ได้ดีค่ะ ก็คือเขาก็บอกว่ามี tech ตัวใหม่พี่ที่น่าสนใจนะคะ

เขาบอกให้เราฟังว่าเนี่ย มันเป็น strongly typed นะ การเปลี่ยนจาก Angular JavaScript ให้กลายเป็น strongly typed เป็นไปได้ยังไงวะ เพราะว่าเมื่อก่อนนี้เราก็รู้กันเนาะ ว่าเราอยากจะประกาศอะไรแล้วโยนมันไปที่ไหน JavaScript ก็รับได้หมด แต่ทีนี้ มันก็จะตามมาด้วยปัญหาที่ว่า เวลาเราจะมา debug เช็กค่ากันสักทีนึงอะ กลายเป็นว่าไม่รู้เลยว่าค่านี่มาจากไหน เสียเวลาในการ debug ไปมากมาย ข้อนี้ก็เลยเป็นจุดเด่นแรกที่น้องเขานำเสนอนะคะ แล้วเราก็ซื้อเลย ซื้อเลยตั้งแต่ข้อแรก ต่อไปการเป็น OOP concept ค่ะ ทุกคนอาจจะไม่รู้เหมือนกันนะ อาจจะใช้ class ในการจัดการ JavaScript ของตัวเองรึเปล่า แต่ว่าตรงนี้ มันทำให้เกิดความเป็น module ความเป็น OOP object-oriented programming ได้ง่ายๆ นะคะ

ก็เลยเป็นอีกข้อนึงที่เราอยากใช้ เพราะเมื่อก่อนเราอยากจะทำ class ที เราก็ต้องใช้ prototype เนาะ

ถึงจะทำ class ขึ้นมาได้ ถึงจะมี function ได้ง่ายๆ แล้วเรียกใช้ไปได้ทุกที ต่อไปข้อต่อมาที่เรารู้สึกรักมันก็คือความ compatible ค่ะ อันนี้มันเป็นสิ่งที่จำเป็นสำหรับ application ที่เราทำมากๆ

สำหรับความ compatibility นะคะ ด้วยความที่ตัว Builk One Group เองเนี่ย มี application ตัวนึงที่เป็น ERP ตัวใหญ่มาก

สำหรับตัวนั้นน่ะนะคะ เลยทำให้เรามีการ transition ได้ยากมาก พอ transition ยากหมายความว่า มันมีโค้ดเยอะมากที่เราจะต้องเปลี่ยนแปลงมัน เพราะฉะนั้นการที่มันสามารถ compatible กับตัว JavaScript เวอร์ชันเก่า ES เวอร์ชันเก่าได้เนี่ย ก็เลยทำให้เราไม่จำเป็นที่จะต้องทิ้ง library นับร้อยที่เรามีอยู่กับระบบนั้นไปนะคะ ยังใช้ร่วมกันได้ แล้วก็มันก็กลายเป็นว่าสภาพเราก็เหมือนแฟนเก่ากับ แฟนใหม่อยู่ในบ้านเดียวกัน จับมือกันอย่าง happy ดีด๊า ทีนี้ข้อสุดท้ายที่รู้สึกว่าเป็น strong point ที่เราเลือก

เพราะว่าเราชอบที่มันเป็น open source แล้วก็มี Microsoft community เป็นคน support อีกทีนึงนะคะ การเป็น open source เนี่ย มันจะทำให้ภาษาใดๆ ก็ตามน่ะ มันเติบโตได้รวดเร็วเนาะ library อะไรก็ตามที่เป็น open source เพราะว่ามันจะมีคนร่วมเดือดร้อนกับเราเยอะมาก ถ้าหากว่ามันเจอ bug เจอ defect อะไรขึ้นมา อย่างน้อยเราก็รู้ว่าเราไม่ได้ทำงานอยู่คนเดียวค่ะ แล้วด้วยความที่มันเป็น Microsoft support อย่างเงี้ย ก็แปลว่าอย่างน้อยเวลาเรา pull request เข้าไปอะ มันก็จะมีคนที่มีความเชี่ยวชาญ เป็นกลุ่มคนกลุ่มนึงที่ทำงานอยู่ตรงนี้มานาน

และถนัดกับการสร้างป้อมปราการแบบเรามากเลย

คอย check pull request ให้เรานะคะ อย่างน้อยเราก็รู้ว่าเราไม่ทำอะไรผิดพลาดออกไปแน่ๆ และนั่นก็เลยเป็นเหตุผลหลักๆ ค่ะ จริงๆ มันมีมากกว่านี้ค่ะ แต่พูดมากกว่านี้เดี๋ยวเขาจะหาว่าอวย TypeScript

ปัญหาที่พบเจอระหว่างการเปลี่ยนมาใช้ TypeScript6:37

เพราะฉะนั้นเรามาดูกันดีกว่าว่าระหว่างที่เราทำตัว

transition จาก AngularJS ให้กลายเป็น TypeScript เนี่ย ปัญหาหลักๆ ที่ถือว่าเป็นเรื่องน่าปวดหัวค่ะ ของมันมันคืออะไร ไม่ใช่การ install webpack ค่ะ อันนั้นง่าย แต่ว่าสิ่งที่เราเจอหลักๆ ค่ะ ก็คือ product ตัว ERP ของเราที่มัน มี tech เทคโนโลยีเก่าๆ อยู่เยอะมาก ตอนนี้เราไปเจอปัญหาว่าตอนที่เราพยายามจะ

transform สัก module นึงเนี่ย ให้มาใช้ TypeScript อะ โอเค webpack ไม่ยากเนาะ แต่ว่าที่มันไปยากมันกลายเป็นว่า มันมีเรื่องราวของ language features กับ runtime features ขึ้นมาค่ะ เราก็คงรู้กันอยู่แล้วเนาะ ว่า developer environment น่ะ เราก็ใช้คอมไฮเทคกันสุดๆ ไม่ว่า run อะไรเราก็ run ผ่านอยู่แล้วค่ะ แล้วด้วยความที่ TypeScript มันยืนพื้นอยู่บน modernized JavaScript เนาะ

มันก็จะเป็นพิษเลยละกัน กับพวก Windows server

Windows application เก่าๆ ที่เราใช้ IE ตัวเก่าๆ เลย แล้วด้วยความที่มันเป็น construction industry ค่ะ คนที่ใช้งานระบบ ERP ของเราตัวนี้ มันไม่ใช่คนที่ไฮเทคอย่างที่ developer เราเป็น เพราะฉะนั้น ตอนที่เราเขียนโค้ดไปอะ กลายเป็นว่าเราต้องเช็กดีๆ ค่ะ ว่าโอเคมันเขียนได้เนาะ ใน language เนี่ย ใน language features เนี่ยมันมี แต่เวลาพอไป runtime ที่เครื่อง user แล้วอะ ไอ้ตัว runtime features ใน browser ตัวนั้นมันอาจจะไม่มีสิ่งนี้ให้เรียกใช้อยู่ ก็กลายเป็น error กันไปกลับมาอย่างมหาศาล เพราะฉะนั้น สิ่งที่ดีของเจ้า TypeScript ตัวนี้เลย ก็คือเราสามารถกำหนด target มันได้เนาะ target ได้ว่าเราจะไปใช้ runtime ตัวไหน ในการ compile มัน เราจะกำหนด library ตัวไหนเพื่อมาเป็น polyfill ให้มัน ถ้าเติมเต็มความ compatible กลับไปใน browser ตัวเก่าๆ

ถ้าอันนี้ยังไงก็ตามก็คือทำใน config นะคะ tsconfig อะ

ความท้าทายในการขอ Refactor โค้ด8:48

แล้วข้อสุดท้ายเนี่ยค่ะ ที่ถือว่าเป็น challenge สุดๆ เลยเหมือนกัน ก็คือการขออนุญาต refactor อยากรู้ว่าใครที่อยู่ในจุดที่จะต้องขออนุญาต refactor บ้างคะ ยกมือให้ดูหน่อยได้มั้ยอะ นั่นไง เต็มไปหมด 3-4 คนก็ถือว่าเต็มแล้วค่ะ ขอบคุณมากค่ะ

ยากไหมคะ ในการที่จะขอ refactor สักอย่าง อย่างที่บอกเมื่อกี้เนาะ เราเหมือน one big family นะคะ เราจะมี existing technology ของเราอะค่ะ ก็คือเป็นบรรดาแฟนเก่าของเรา บางทีไม่ใช่มีคนเดียวเนาะ เราก็ต้องยอมรับว่า tech stack ของเรามันสร้างมาจากโลกเก่า สารพัดสารเพเหมือนกัน นอกจากนี้ เราก็ยังมี dev และ tester ค่ะ อย่างที่บอกเค้าเป็นลูกๆของเราเนาะ ผู้ร่วมสร้าง product ด้วยกันมา PM ค่ะ อันนี้อาจจะเป็นคนที่ยืนขาฝั่ง tech นิดหน่อย แล้วก็ฝั่ง business อีกนิดหน่อย อันนี้เค้าอาจจะฟังเรารู้เรื่อง สุดท้ายค่ะ product owner, business development

แล้วก็บรรดา C-level และ board ทั้งหลายของเรา อันเนี้ยเป็นเหมือนไม้ตายเนาะ ถ้าเราพูดกับเค้ารู้เรื่องได้เนี่ย ไม่ว่าอะไรเราก็ได้ทำค่ะ ทีนี้ก็เลยมีเทคนิคเล็กน้อย ที่อยากจะเล่าให้ฟังละกัน

ระหว่างที่ขออนุญาตในการ refactor เราจะทำยังไงกับกลุ่มคนเหล่านี้บ้าง

เทคนิคการขออนุญาต Refactor กับทีม Dev, Tester และ PM10:11

เราขอย้อนกลับมาที่ทีม dev ก่อนนะคะ

ทีม dev กับ tester เนี่ยถือว่าเป็น tech-savvy people เนาะ เค้าคุยกับเรารู้เรื่อง จริงๆแล้วสิ่งที่เค้าอยากได้มันมีไม่เท่าไหร่หรอกค่ะ ก็คือสิ่งที่ทำให้เค้า performance เพิ่มขึ้น สิ่งที่ทำให้ชีวิตเค้าสะดวกขึ้น การ debug น้อยลง ของการมี strong type จาก TypeScript เนี่ย โอเคอย่างน้อยมันก็ทำให้เค้า dev เร็วขึ้น การที่คนใหม่ๆที่เข้ามาเนี่ย สามารถทำลายป้อมปราการที่เค้าสร้างเอาไว้แล้วได้ยากขึ้น อีกนิดนึง อันเนี้ยก็จะทำให้เหล่าพี่ๆเนี่ยเค้าสบายใจมากขึ้น อันเนี้ยเป็นสิ่งที่ convince เหล่า dev ได้นะคะ แล้วก็ tester เนี่ย จริงๆเค้าก็แค่คาดหวังว่า เมื่อ transition ไปแล้วอ่ะ ทุกอย่างมันยัง run ได้ปกติ ถ้าหากว่าเราหา library อย่างอะไรสักอย่าง ที่จะเอามาใช้แทนสิ่งที่เค้ามีตอนนี้ได้นะคะ มันก็ใช้การได้ แค่นี้เค้าก็ happy แล้ว ซึ่งจริงๆแล้วเนี่ย ด้วยความที่ TypeScript มัน build on JavaScript ธรรมดาเนาะ ตัว library เดิมที่เคยใช้ในการทำ test ก็ยังใช้ได้อยู่ค่ะ ก็เลยไม่ได้มีปัญหาอะไร ตอนนี้เราก็ใช้ Cypress เนาะ solution architect เลือกให้มาอีกแล้วค่ะคนนี้นะคะ

ทีนี้ก็แปลว่าเรื่อง performance เรื่องความเร็วเงี้ย เป็นสิ่งที่คุยกันได้ในทีมรู้เรื่อง ทุกคนจะเริ่ม buy กับเรา และลูกๆเราจะเริ่มโอเคกับเทคโนโลยีใหม่ พร้อมที่จะมีแม่ใหม่กันมากๆ แต่ทีนี้ เราก็ต้องไป convince คนต่อไปค่ะ ก็คือ PM คนที่มีความรู้ด้าน tech อยู่ครึ่งนึง

ถ้าหากว่าสิ่งที่เค้าเข้าใจอ่ะ นอกจากขา tech แล้วอ่ะ จะมีอีกเรื่องนึงที่เค้า concern ค่ะ ก็คือโปรเจคที่ทำอยู่มันจะเสร็จตามเวลาจริงหรือเปล่า ซึ่งตรงเนี้ย มันเป็นสิ่งที่บีบให้เค้าต้องเขี่ยวเข็ญ

กับเราขึ้นมานิดนึงอะนะคะ เพราะฉะนั้นการคุยกับเค้าว่า ตัวเลขที่เค้าจะต้องเสียไป

cost ที่เราจะต้องเสียไป เวลาที่เราจะต้องเสียไปกับการทำสิ่งเนี้ย มันมากมายขนาดไหนก็ ถ้าหากว่าเราหั่นมันเป็นชิ้นเล็กๆค่ะ ค่อยๆทำการ refactor ไป อย่างของ ERP ตัวเนี้ย เราก็เริ่มจากการ เฮ้ย ถ้าหากว่าจะทำ module ใหม่ขึ้นมา เราขอ build ขึ้นมาบน stack ใหม่เลยนะ อันเนี้ย ก็จะคุยกันได้ง่ายมากกว่าค่ะ เพราะว่าเราก็เตรียมลูกๆของเราไว้แล้วว่า เดี๋ยวเราจะใช้เทคโนโลยีใหม่เนาะ เราส่งเค้าไปเรียน ส่งเค้าไปเตรียมตัวเรียบร้อย และแปลว่าเวลาเค้ามา dev อีกทีนึงเนี่ย มันก็น่าจะใช้เวลาไม่นานจากที่น่าจะเป็นล่ะ เวลาทำ feature ทีนี้คนเนี้ยค่ะ PM ก็จะเป็นตัวหลักที่จะช่วยในการ convince ของเราต่อไปในขั้นที่สูงขึ้นอะนะคะ

วิธีการโน้มน้าว Product Owner, C-Level และ Board13:07

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

แต่ใครจะลองก็ได้ เชื่อว่าหลายคนคงลองนะคะ อย่าง solution architect คนเก่าเนี่ยก็ลองบ่อยเลยค่ะ เพราะว่ามันต้องใช้เวลาในการ research เนาะ เรื่องพวกนี้ ทีนี้ เหล่าคนเหล่าเนี้ยค่ะ จริงๆแล้วเค้าคือคน ที่กำหนดนโยบายบริษัท เค้าคือคนที่ตัดสินใจ มีอำนาจสูงอะค่ะ ว่าเราจะเลือกเดิน way นี้ หรือเลือกเดินทางอื่น หรือจะเลือกจมอยู่กับสิ่งเก่าของเรา เพราะฉะนั้นทางที่ดีคือการทำให้เค้าเข้าใจค่ะ ซึ่งการทำให้เค้าเข้าใจเนี่ย เดี๋ยวสรุปมาให้ดูเป็นอีกสไลด์นึง ง่ายๆ

ฝั่งนั้นเดี๋ยวเราค่อยพูดกันอีกทีนะคะ

เทคนิคการสื่อสารกับ Non-Tech-Savvy People14:18

มาดูฝั่งสีน้ำเงินกันก่อนนะคะ non-tech-savvy people นะคะ ทำให้เราเข้าใจค่ะ ซึ่งสิ่งที่เค้าเข้าใจอย่างที่บอกเมื่อกี้ คล้ายๆ PM ค่ะ เค้าเข้าใจเรื่องตัวเลข บอกเค้าว่า เวลาที่จะใช้มันคือเท่าไหร่

ถ้าหากว่าเรา design ระบบมาแล้ว เราเตรียมแล้วว่า transition มันต้องเจอกับอะไรบ้าง research มาเรียบร้อยอย่างเงี้ย เราค่อนข้างจะวางได้ไม่พลาดหรอกค่ะ ว่ามันจะใช้เวลาเพิ่มจากเดิมอีกซักกี่วัน แล้วก็อย่างที่บอกแนะนำให้ทำกับ module ใหม่ก่อน หรือค่อยๆ refactor ทีละส่วนก่อน โอเค เดี๋ยวตอนเนี้ยเราลองเปลี่ยน .js เป็น .ts ง่ายๆดูก่อนเนาะ อะไรอย่างเงี้ยจะทำให้พอคุยกันได้ คุยกันรู้เรื่อง ทีนี้ ต่อไปค่ะ เค้าบอกว่าอย่าใช้คำว่า refactor

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

ถ้าหากว่าไม่ทำในตอนนี้ เราจะเจอกับอะไรในอนาคต อย่างยกตัวอย่างเป็นอันนึงแล้วกันที่ใช้แล้วก็ค่อนข้างได้ผลค่ะ ก็คือมันมีเรื่อง application ที่เป็น monolithic อยู่ 1 ตัวเนาะ

เราเชื่อว่าตอนนี้เรากำลังจะทำ software as a service เราอยากจะเปลี่ยนตัว monolithic นี้ ให้กลายเป็น multi-tier application เพราะว่ามันจะได้ scale ได้เนาะ monolithic คือมันไปไหนก็ไปกันเป็นก้อนน่ะค่ะ จะ scale ทีเดียวก็เอาตังค์ฟาดเข้าไปค่ะ อัพ server เข้าไป ซึ่งเราไม่ได้มีเงินมากขนาดนั้นเนาะ ต้องยอมรับความเป็น tech startup

การวางแผนและการเแอบ Research เพื่อการ Refactor16:03

ทีนี้ก็เลยต้องบอกเขาค่ะว่า

ตอนนี้ค่ะ เรายังรับได้ที่ระดับหมื่นกว่าคน

พันคนหรืออะไรก็ว่าไปนะคะ แต่ถ้าหากว่าในวันพรุ่งนี้พี่วางแผน คือแน่นอนทาง business เขามีการวางแผนอยู่แล้วค่ะ ว่าเขาอยากจะได้ตัวเลขยอดต่อไปที่เท่าไหร่ เขาก็จะบอกเรามาค่ะว่า

สักปีหน้าหรือว่าสัก 6 เดือนข้างหน้าเนี่ย ฉันจะเพิ่ม user จากตอนนี้หลักหมื่นให้กลายเป็นหลักแสนน่ะค่ะ ถึงตอนนี้เราบอกเขาได้แล้วค่ะว่า server ที่พี่มีอยู่มันกำลังจะไม่ไหวค่ะ เรานับถอยหลังให้เขาได้ ว่ามันกำลังจะไปตายตรงไหน คือการนับถอยหลังนี่คือการบอกจำนวนเหมือนกันค่ะ ว่าเทคโนโลยีเนี่ยมันต้องการการเปลี่ยนแปลง แล้วถ้าหากว่าเปลี่ยนไม่ทันในเวลานี้มันกำลังจะเกิดอะไรขึ้นนะคะ ซึ่งกลายเป็นว่าถ้ายังดึงดันที่จะทำอย่างนั้นต่อไป กลายเป็นว่าเขาจะเสีย opportunity ซะอีกนะคะ

ก็เลยถือว่าเป็นการ big improvement ไปเรื่อยๆ ค่ะ แล้วก็วางแผนออกมาเป็นระยะว่า เราจะเริ่ม improve จากอะไรก่อน แล้วค่อยทำอะไรถัดไปนะคะ

แต่สุดท้ายที่สุดเขาก็บอกว่า เออมันก็มีเนาะที่มันเป็นไปไม่ได้ คือจริงๆแล้วถ้าหากว่าเราอยู่ใน level ที่สูงขึ้นมาสักหน่อยอ่ะค่ะ มันจะมีเวลาที่มากขึ้นให้เราทำการ research อะไรอย่างเงี้ย ก็จริงๆแล้วในจังหวะนั้นน่ะค่ะ คือจังหวะที่เราจะทำอะไรไปก่อน แล้วค่อยมาขอโทษทีหลัง ซึ่งนั่นก็คือการแอบ research ไปก่อนนะคะ ลองขึ้น project ลองเปลี่ยนตัว stack จาก project เดิมไปก่อน เพื่อเราจะได้มีตัวเลขมาบอกเขาได้เหมือนกันค่ะ สุดท้ายทำเพื่อ serve ตัวเลขล้วนๆ เลย ว่าเราจะต้องใช้เวลาเท่าไหร่ ต้องใช้คนกี่คนนะคะ ซึ่งอันนี้กลายเป็นว่าถ้าหากว่าเขาทำเสร็จแล้วเนี่ย มันจะไปเปิดโอกาสให้กับธุรกิจของเขาได้มากขึ้นกว่าที่เขาคิดอ่ะค่ะ

คือสุดท้ายแล้วทั้งสองฝั่งเนี้ยค่ะ

สรุป: ทำให้ชีวิต Dev ดีขึ้น และเพิ่มโอกาสทางธุรกิจ18:07

สุดท้ายนี้ก็ใกล้จะจบแล้วค่ะ ใกล้จะจบแล้วเราจะได้กินข้าวกันแล้ว ก็คือฝั่ง tech savvy อ่ะค่ะ สุดท้ายยังไงก็ตามอ่ะ เขาก็ต้องการที่จะทำให้ชีวิตเขาดีขึ้นเท่านั้นเองนะคะ ไม่ว่าจะโค้ดได้เร็วขึ้น bug น้อยลง อีกอย่างนึงที่อยากจะบอกก็คือ อย่างฝั่งของ Builk One Group เองเนี่ยนะคะ เรามีระบบ pool dev อ่ะค่ะ มี dev กองกลางค่ะ แล้วก็มี application เป็น asset รอยอยู่ นั่นหมายความว่า ถ้าหากว่าเราส่ง dev 1 กองกำลังเข้าไปแก้ไข

application ไหน asset ตัวไหนอย่างเงี้ย เมื่อถึงเวลาเขาทำเสร็จเขาออกมา เขาอาจจะทิ้ง bug ไว้ก็ได้ ถ้าหากว่าเราไม่มีระบบแข็งแกร่งพอ ที่จะป้องกันไม่ให้ newbie ทั้งหลายเข้าไปทำอะไรที่เขาไม่รู้จักอ่ะค่ะ เพราะฉะนั้นตอนนี้เราเลยเลือก tech stack ให้กลายเป็น TypeScript ซะทั้งหมดเลย ทั้ง backend เป็น strong type อยู่แล้ว C# frontend ก็กลายเป็น TypeScript หมดแล้ว นั่นหมายความว่าการเกิด bug มันจะน้อยลงค่ะ แค่นี้ tester ก็ happy dev เราก็ happy ไปด้วย PM ก็ happy อยู่แล้วค่ะไม่ต้องวนกลับมาแก้ซ้ำ ทีนี้ฝั่ง non-tech savvy อ่ะค่ะ สิ่งที่เขาต้องการก็แค่ว่า มันจะยังได้ opportunity ที่เขาอยากได้อยู่หรือเปล่า แล้วถ้าเราสามารถสื่อสารกับเขาได้นะคะ ว่าเราจะต้องทำให้เขาเสีย cost อีกเท่าไหร่

แล้วก็การเสีย cost ครั้งนี้ อาจจะเปิด opportunity อะไรให้เขา ซึ่งนั่นอาจจะเป็นเงินมูลค่าอีกหลายล้านก็ได้ แค่นี้ค่ะเขาก็จะ happy แล้ว ถ้ายังไงก็ขอจบเรื่องราวของวันนี้ไว้เท่านี้ก่อนนะคะ ขอให้ happy transition กันค่ะ ขอบคุณค่ะ

ขอบคุณวิทยากรและประกาศพักเบรก19:49

ขอบคุณคุณสิริรัตน์นะคะ ขอบคุณ speaker ทุกท่านในช่วงครึ่งวันเช้าด้วยนะคะ เดี๋ยวตอนนี้เราจะไปพักเบรกและรับประทานอาหารกลางวันกัน ท่านไหนยังไม่ได้เลือกเมนูนะคะ อย่าลืมเข้าไปที่ browser app.javascriptbangkok.com นะคะ ท่านไหนที่กำลังทยอยเดินออกนะคะ เดี๋ยวเราเริ่ม section บ่ายตอนบ่ายโมงตรงนะคะ เริ่มตรงเวลานะคะบ่ายโมงตรง ท่านไหนเลือกเมนูอาหารแล้ว ก็เอาหน้าจอเนี่ยไปโชว์ไว้กับพี่ๆเจ้าหน้าที่ที่ชั้น 7 ตรงจุดลงทะเบียนนะคะ เขาจะแจกเป็นคูปองอาหาร แล้วก็เรายังมีแจกของที่ระลึกฟรีด้วย ท่านใดที่ยังไม่ได้รับก็เอา badge เนี่ยแหละค่ะ ป้ายชื่อเนี่ยไปโชว์เจ้าหน้าที่ เขาก็จะแจกเป็นของที่ระลึกฟรีเหมือนกันนะคะ แล้วก็ยังมีสินค้าอื่นๆ ต่างๆ มากมาย สินค้าที่เราจำหน่ายเป็นเซตเนี่ย ก็จะเป็นราคาพิเศษด้วยนะคะ ลดพิเศษก็เรียนเชิญได้ที่บริเวณชั้น 7 เช่นกันนะคะ

เดี๋ยวเจอกันตอนบ่ายโมงตรงนะคะ section ถัดไปเริ่มบ่ายโมงตรงนะคะ Do not forget to choose your lunch meal at

app.javascriptbangkok.com and then show us there you can get the lunch coupon on the seventh floor. See you again over here at 1 o'clock sharp. And for the free souvenir we have provided for you too. Just show our staff at the registration on the seventh floor your badge and then you will get the free souvenir. Okay, so see you at 1 o'clock sharp. Thank you. ก็เรียนเชิญพักผ่อนรับประทานอาหารตามอัธยาศัย เจอกันบ่ายโมงตรงค่ะ