อ่านเจอบทความเรื่อง The continual evolution of Airtable’s codebase: Migrating a million lines of code to TypeScript
ทำการอธิบายว่าที่ Airtable ทำการปรับปรุง code กันอย่างไรบ้าง ?
กับ code ที่มีกว่า 1 ล้านบรรทัด
จาก Vanilla JavaScript ไปยัง TypeScript
ตั้งแต่เริ่มจนถึงปัจจุบัน และในอนาคต
โดย history ของการพัฒนาเป็นดังนี้
- เริ่มจาก Vanilla JavaScript
- นำ Browserify มาใช้งาน ซึ่งทำการ import CommonJS มาใช้งาน
- ทำการแปลงรูปแบบของการเขียน class จาก Backbone style มาเป็น ES6 style
- ทำการ custom เป็น component เพื่อ convert ไปยัง ReactJS component
- แน่นอนว่าเลือก Flow ซึ่งทำงานกับ ReactJS ได้ดี เข้าสู่ยุคของ Static type
- ต่อมาทีมคิดว่า Flow ไม่ตอบโจทย์แล้ว ทั้งในแง่ของ productivity, community และ tool ต่าง ๆ
- ทำการแปลงจาก Flow มายัง TypeScript
แนวทางของ Airtable สำหรับทุก ๆ การเปลี่ยนแปลง
ประกอบไปด้วย
- ต้องไม่ส่งผลกระทบต่อ product และผู้ใช้งานในเชิงลบ
- ในการเปลี่ยนต้องไม่ลด type safty ลง จะเห็นได้จากการเปลี่ยนจาก Flow มายัง TypeScript
- พยายามทำให้มันง่ายที่สุด เนื่องจากการเปลี่ยนแปลงมีจำนวนมาก ดังนั้นต้องค่อย ๆ เปลี่ยนแปลงและปรับปรุงไปทีละส่วนเล็ก ๆ (Incremental) เช่น type-by-tpye หรือ file-by-file เป็นต้น
แต่ถ้าทำการเปลี่ยนแปลงเยอะ ๆ
จะสร้างเครื่องมือในการ migrate เป็น TypeScript ขึ้นมา
เพื่อช่วยจัดการเรื่องที่ซ้ำ ๆ หรือมี patternคือ
GitHub :: Airtable’s TypeScript Migration Codemod
ในการเปลี่ยนแปลง จะทำการสร้าง branch แยกออกไปทำ
จากนั้นทำการตรวจสอบเรื่อง type checking
รวมทั้งมี automated test เพื่อทำให้มั่นใจว่ายังคงทำงานตามที่คาดหวัง
เมื่อทุกอย่างผ่านเรียบร้อยจึงทำการ merge มายัง main branch
เพื่อทำการ deploy ต่อไป
ในการทำงานก็มีเรื่องราวและแนวคิดมากมาย ที่น่าสนใจ
ทั้งการแปลงจาก createReactClass component มาเป็น ES6 class component
ในส่วนของ Automation team ทำการสร้าง helper method
สำหรับการ generate TypeScript type ออกมา
เพื่อใช้ในการกำหนดและ validate schema
ในส่วนของ Enterprise team ทำการเปลี่ยนจาก ts file มาเป็น tsx file ให้หมด
เพราะว่า จะได้ใช้เพียงแนวทางเดียวไปเลย
จะเห็นได้ว่าที่ Airtable จะค่อย ๆ ทำการเปลี่ยนแปลง
พร้อมกับสร้างเครื่องมือมาลดงานที่ซ้ำ ๆ
ช่วยทำงานให้ทำงานได้เร็วขึ้น
พร้อมทั้งยังต้องมี automated test เพื่อช่วยตรวจสอบความถูกต้องด้วยเสมอ
รวมทั้งยังชี้ให้เห็นข้อดีของ static type ด้วยว่า
ถ้า code มีขนาดใหญ่แล้ว เรื่อง type จะสำคัญมาก ๆ
เพื่อลดความเสี่ยงและความผิดพลาดได้มากขึ้น
และเน้นที่เรื่องของ code quality และ การพัฒนาอย่างต่อเนื่อง
ปล. ในปัจจุบัน Airtable ก็ยังมี code เก่า ๆ อยู่เช่นกันยังย้ายไปไม่หมด
