ยุคที่โค้ดทดสอบกลายเป็นคูเมืองใหม่ (Moat)
(saewitz.com)-
ความย้อนแย้งของความสำเร็จ: ยิ่งโปรเจกต์เติบโตมากขึ้น ก็ยิ่งต้องแบกรับภาระของความเข้ากันได้ย้อนหลังและโค้ดเบสขนาดมหาศาล (The Ship of Theseus) ขณะที่คู่แข่งสามารถนำสเปก API, เอกสาร และโค้ดทดสอบของโปรเจกต์เดิมไปให้ AI เรียนรู้ เพื่อสกัดเอาเฉพาะคุณค่าหลัก แล้วสร้างเป็น 'เวอร์ชันที่เบากว่าและทันสมัยกว่า' ได้แทบจะในพริบตา
-
กรณีศึกษา Cloudflare vs Vercel: Cloudflare ใช้เอกสารจำนวนมหาศาลและชุดทดสอบของ Next.js ที่ Vercel สั่งสมมาหลายปี เพื่อสร้างรันไทม์ที่เข้ากันได้กับ Next.js แบบเพรียวบางบนพื้นฐานของ Vite ได้ภายในเวลาเพียงหนึ่งสัปดาห์ (ปัจจุบันถูกนำไปใช้กับเว็บไซต์รัฐบาลสหรัฐฯ cio.gov ด้วย)
-
โค้ดทดสอบคือสินทรัพย์: ในอดีต ตัวโค้ดเองคือสิ่งสำคัญ แต่ตอนนี้ 'สัญญาของซอฟต์แวร์ (Contract)' และ 'กรณีทดสอบ' กลายเป็นสินทรัพย์ที่มีมูลค่าสูงที่สุด การเปิดเผยสิ่งเหล่านี้ก็ไม่ต่างจากการมอบพิมพ์เขียวความละเอียดสูงที่ทำให้คู่แข่งสามารถคัดลอกบริการของเราไปได้ทั้งชุด
-
วิสัยทัศน์ล่วงหน้าของ SQLite: SQLite เปิดเผยโค้ด แต่ยังคงปิดชุดทดสอบขนาดมหาศาลเอาไว้ โดยมีขนาดมากกว่าซอร์สโค้ดถึง 590 เท่า (92 ล้านบรรทัด) สิ่งนี้กลายเป็น 'คูเมือง' ที่ทำให้พวกเขารักษาระบบนิเวศโอเพนซอร์สไว้ได้ พร้อมกับมีพลังในการป้องกันทางธุรกิจ
-
บทสรุป: ในยุค AI บริษัทโอเพนซอร์สเชิงพาณิชย์กำลังเผชิญกับช่วงเวลาที่ต้องตัดสินใจระหว่าง 'ความไม่เห็นแก่ตัวอย่างสมบูรณ์ (โอเพนซอร์ส)' กับ 'การอยู่รอดของธุรกิจ' ต่อจากนี้ โปรเจกต์จำนวนมากน่าจะหันไปปิดโค้ดทดสอบแบบ SQLite เพื่อสร้างกำแพงทางเทคโนโลยีของตนเอง
19 ความคิดเห็น
ถ้ามองตามมุมมองนี้ ก็เป็นไปได้ว่าเอกสารอย่าง ADR(Architecture Decision Records) หรือ CIR(Change Intent Records) อาจได้รับการให้คุณค่ามากกว่าตัวโค้ดเสียอีก
น่าประทับใจมากครับ แม้จะเป็นบทความสั้น ๆ แต่ก็เข้าใจและเห็นด้วยได้ทันที ดูเหมือนว่าความปลอดภัยของโค้ดทดสอบอาจสำคัญกว่าซอร์สโค้ดเสียอีก
สำหรับผม มันฟังดูเหมือนกำลังบอกว่าอย่าละเลย e2e tests เลย แต่ก็อยากรู้เหมือนกันว่าท่านอื่นคิดกันอย่างไร
ผมไม่ใช่นักพัฒนาเลย... แต่สนุกกับการลองเล่น AI ก็เลยให้มันช่วยเขียนโค้ดบ้าง มันดันสร้างและเก็บเทสต์โค้ดไว้เยอะมากทั้งที่ผมไม่ได้สั่ง ที่แท้ก็มีเหตุผลแบบนี้นี่เอง
พอถามว่านี่มันจำเป็นไปเพื่ออะไร มันก็บอกว่าตอนมันเขียนโค้ดมันต้องใช้ เลยบอกว่าอย่าลบนะ
โอ้... น่าจะจริงครับ
แนวทางของ SQLite น่าประทับใจมากครับ การเก็บ test suite ที่มีขนาดมากกว่าโค้ดถึง 590 เท่าไว้เป็นความลับนั้น สุดท้ายก็หมายความว่า "คุณค่าที่แท้จริงของซอฟต์แวร์อยู่ที่สเปกของการทำงาน" นั่นเอง
จริง ๆ แล้วทุกวันนี้พอลองสร้างโปรเจกต์ด้วยเครื่องมือ AI coding จะพบว่า ถ้ามีแค่ README + เอกสาร API + test code ของโปรเจกต์เดิม ก็สามารถทำซ้ำฟังก์ชันหลักได้เร็วอย่างน่าทึ่ง ผมดูแลอยู่ 7 โปรเจกต์และรู้สึกได้ด้วยตัวเองว่า ยิ่งเป็นโปรเจกต์ที่มีการทดสอบดี กลับยิ่งทำซ้ำได้ง่ายอย่างน่าประหลาด
แต่มีจุดหนึ่งที่ถูกมองข้ามไปในกรณี Cloudflare vs Vercel คือ "การทำซ้ำ" กับ "การให้บริการจริง" เป็นคนละปัญหากันโดยสิ้นเชิง หากจะทำซ้ำทั้ง edge case ของ Next.js, ecosystem ของปลั๊กอิน และการพึ่งพาคอมมูนิตี้ต่าง ๆ ให้ได้ครบ แค่ test code อย่างเดียวก็ยังไม่พอ สุดท้ายแล้ว moat อาจเป็นการผสมกันของ test code + community + ความรู้ความชำนาญด้านการดำเนินงานก็เป็นได้ครับ
ผมเป็นนักพัฒนาเดี่ยวที่ดูแลอยู่ 7 โปรเจกต์ และบทความนี้ก็แทงใจมากครับ
ด้วยอานิสงส์ของเครื่องมือ AI สำหรับเขียนโค้ด ความเร็วในการพัฒนาช่วงแรกพุ่งแบบบ้าคลั่งก็จริง แต่โค้ดที่กองขึ้นมาอย่างรวดเร็วโดยไม่มีเทสต์ สุดท้ายก็กลายเป็นนรกแห่งการรีแฟกเตอร์อยู่ดี โดยเฉพาะเวลาต้องดูแลหลายบริการพร้อมกัน โปรเจกต์ที่ไม่มีเทสต์นี่น่ากลัวจนไม่กล้าแตะ เพราะทุกครั้งที่ไปแก้ฟีเจอร์หนึ่ง ก็กังวลว่าจะมีที่อื่นพังตามมาหรือเปล่า
อุปมาเรื่อง "เทสต์ = คูเมือง" นี่แม่นมากครับ คู่แข่งอาจคัดลอกโค้ดได้ แต่การจะลอกแม้กระทั่ง test suite ที่ครอบคลุม edge case หลายพันแบบนั้นไม่ใช่เรื่องง่าย โดยเฉพาะเมื่อ AI อาจเก่งเรื่องสร้างโค้ด แต่การสร้างสถานการณ์ทดสอบที่มีความหมายยังเป็นพื้นที่ที่ต้องอาศัยความรู้เชิงโดเมนจากมนุษย์อยู่มาก ยิ่งทำให้ประเด็นนี้ชัดเจนขึ้นไปอีก
แต่ก็ขึ้นอยู่กับสายงานเหมือนกันนะ บางที่แทบไม่มี test coverage เลย ก็เลยทำให้ต้องคิดหนักเหมือนกัน ฝั่งนั้นก็ดูเหมือนว่ายังทำโค้ดดี ๆ ได้ไม่เก่งเท่าสาขาอื่นอยู่เหมือนกันครับ
ขอทราบได้ไหมว่าคือสาขาอะไร? (ไม่ได้จะหาเรื่องนะครับ/คะ แค่อยากรู้จริง ๆ ด้วยความสงสัยล้วน ๆ)
สายงานที่ผมทำอยู่ก็ไม่ได้สุดโต่งถึงขนาดนั้นเหมือนกัน แต่ผมทำวิจัยและพัฒนาในสาย AI อยู่
นอกจากเฟรมเวิร์กที่นิยมใช้กันทั่วไปแล้ว ในทางปฏิบัติก็มีกรณีที่สภาพแวดล้อมเป้าหมายสำหรับการ deploy โมเดลแตกต่างจากสภาพแวดล้อมที่ใช้ฝึกมา
บางครั้งมีโอเปอเรชันบางอย่างที่ไม่รองรับ ทำให้ต้องสร้าง custom operation แยกตามแต่ละแพลตฟอร์ม และในกรณีแบบนี้ก็มักมีหลายครั้งที่ไม่สามารถทดสอบได้ทันทีในสภาพแวดล้อมที่พัฒนา
บางครั้งก็มีกรณีที่ต้องออกแบบโมเดลด้วยตัวเอง ซึ่งแม้จะเขียน test code โดยใช้ข้อมูลบางชุดได้ แต่ค่าต่าง ๆ สามารถเปลี่ยนไปตามความน่าจะเป็นขึ้นอยู่กับ dataset และปรากฏการณ์อย่างค่าพุ่งระเบิดในบางช่วงเวลาก็ครอบคลุมด้วย test code ได้ยาก
ผมคิดว่าน่าจะยังมีสภาพแวดล้อมอีกไม่น้อยที่ทดสอบได้ยากกว่าของผมครับ
นี่เป็นเพียงความเห็นส่วนตัวของผม แต่ผมคิดว่าน่าจะเป็นสายงานที่ใช้ Notebook กันบ่อย หรือเป็นสาย AI ที่คำตอบออกมาในเชิงความน่าจะเป็น..หรือไม่ก็สาย Game Client เป็นต้น
เรื่องนี้ผมก็พูดกับคนรอบตัวบ่อยเหมือนกัน แต่สุดท้ายแล้ว ในอนาคตคงยากที่จะไล่ดูโค้ดทั้งหมดได้ ดังนั้นผมคิดว่าถ้าไม่เขียนเทสต์ให้กับลอจิกที่สำคัญจริง ๆ มีเรื่องใหญ่แน่นอน
มีการเพิ่มไว้ที่ท้ายบทความด้วย โดยมีการพูดกันว่า tldaw ก็รันทดสอบแบบไม่เปิดเผยเช่นกัน (บอกว่าเป็นมุกครับ)
https://github.com/tldraw/tldraw/issues/8082
ถ้าดู SQLite ทดสอบอย่างไร
SQLite เปิดเผยทั้งหมดก็จริง แต่มีโค้ดทดสอบมากกว่าซอร์สโค้ดถึง 590 เท่า และส่วนนี้เป็นความลับทั้งหมด
มีการครอบคลุมสาขา 100% มีเทสต์เคสนับล้านรายการ และทำ mutation test มากกว่าหนึ่งพันล้านครั้ง
พอเข้าไปอ่านในประเด็นแล้ว เขาบอกว่า "เป็นมุก" นะ
ดูเหมือนว่าจะเป็นการทดสอบแบบ Joke สินะ
โห อย่างนั้นเอง ผมดูแค่ด้านบนเอง 555
ผมคิดว่าประเด็นหลักที่ว่า “ให้ความสำคัญกับการทดสอบมากกว่าซอร์ส” นั้นถูกต้องจริง ๆ ครับ แต่ก็ไม่แน่ใจเหมือนกันว่ากลยุทธ์ที่เปิดแค่โอเพนซอร์สโดยไม่เปิดการทดสอบจะยังใช้ได้ผลหรือไม่ เพราะก็ดูเหมือนว่าจะเก่งพอที่จะดึงรายการทดสอบออกมาจากซอร์สได้เหมือนกัน..
ทำผิดเหมือนกันนะ
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
ดูเหมือนจะเป็นบทความที่เชื่อมโยงกับเรื่องนี้นะครับ ตอนทำโอเพนซอร์ส ตอนนี้ก็คงเป็นไปได้ว่าเราอาจจะต้องระมัดระวังมากขึ้นในการเปิดเผยโค้ดทดสอบ