สารบัญ
ทุกบทความในซีรีส์นี้มาจากการที่ผมคุยกับ AI แล้วค้นข้อมูลเพิ่มเติม ผมเป็นคนกำหนดทิศทาง ให้ AI ช่วยสรุป วิเคราะห์ และเรียบเรียงออกมาเป็นบทความครับ
เคยสงสัยมั้ยครับ ว่าแอปที่เรากดใช้ทุกวัน เขามีวิธีสร้างกันยังไง
ไม่ใช่แค่ “เขียนโค้ด” นะ
แต่หมายถึงทั้งกระบวนการ ตั้งแต่คิดว่าจะทำอะไร ไปจนถึงปล่อยให้คนใช้
เรื่องนี้มีชื่อเรียกว่า SDLC ย่อมาจาก Software Development Life Cycle แปลง่ายๆ คือ “วงจรการสร้างซอฟต์แวร์” ว่ามีกี่ขั้น ทำอะไรก่อนหลัง
ช่วงนี้ผมได้ยินคำใหม่บ่อยมาก คือ ADLC ที่เขาว่าจะมาแทน SDLC ในยุคที่ AI ลงมือสร้างซอฟต์แวร์เอง
พอไปขุดดู ก็เลยรู้ว่า ถ้าจะเข้าใจของใหม่ให้ขาด ต้องย้อนไปดูของเก่าก่อน
เอางี้ ผมไล่เรียนมันทีละยุคเลย แล้วลองทำเองจริงๆ ด้วย

ยุคศูนย์หนึ่ง: ราวปี 1950
ยุคแรกสุด คอมพิวเตอร์ตัวใหญ่เท่าห้อง

คนเขียนโปรแกรมต้องสั่งงานด้วย machine language คือภาษาที่เครื่องเข้าใจตรงๆ เป็นเลข 0 กับ 1 ล้วนๆ
ลองนึกภาพเขียนจดหมายยาวๆ ด้วยเลขศูนย์กับหนึ่งดูนะ
พลาดตัวเดียวก็พังทั้งฉบับ
เลยไม่แปลกที่ software ยุคนั้นทั้งแพงทั้งเต็มไปด้วย bug (bug = จุดผิดพลาดในโปรแกรม ที่ทำให้มันทำงานเพี้ยน)
ตัวอย่างดังๆ ของยุคนี้มีสอง project
- SAGE: ระบบป้องกันภัยทางอากาศของสหรัฐฯ ใช้คอมพิวเตอร์คอยดูข้อมูลเรดาร์ว่ามีเครื่องบินข้าศึกเข้ามามั้ย เป็น project software ยักษ์ยุคแรกๆ ที่ใช้คนมหาศาล
- SABRE: ระบบจองตั๋วเครื่องบินของ American Airlines ที่ทำร่วมกับ IBM เปลี่ยนการจองตั๋วจากกระดาษกับโทรศัพท์ มาเป็นคอมพิวเตอร์ เริ่มใช้งานจริงราวต้นทศวรรษ 1960
สอง project นี้พิสูจน์ว่า software ทำเรื่องใหญ่ได้จริง
แต่ก็พิสูจน์ด้วยว่า การสร้างมันยากโคตรๆ 555+
ยุคทีมใหญ่กับ Waterfall: ราวปี 1960-1970
พองานใหญ่ขึ้น ทีมก็ใหญ่ขึ้น
ปรากฏว่ายิ่งคนเยอะ ยิ่งวุ่น project ส่งช้า งบบานปลาย บางงานทำเสร็จแล้วใช้ไม่ได้ก็มี
วงการเรียกช่วงนี้ว่า software crisis หรือ “วิกฤต software” คำนี้ถูกพูดถึงในงานประชุมวิชาการช่วงปลายทศวรรษ 1960
ทางแก้ที่คนยุคนั้นคิดได้ คือ Waterfall (แปลตรงตัวว่าน้ำตก)
หลักคือทำทีละขั้น เสร็จขั้นหนึ่งค่อยไหลลงขั้นถัดไป เหมือนน้ำตกที่ไหลย้อนกลับขึ้นไปไม่ได้
- Requirements: เก็บความต้องการว่าลูกค้าอยากได้อะไร
- Design: ออกแบบว่าระบบจะหน้าตายังไง ทำงานยังไง
- Build: ลงมือเขียนโค้ด
- Test: ทดสอบหา bug
- Deploy: ปล่อยให้คนใช้งานจริง
ฟังดูเป็นระเบียบดีใช่มั้ย
แต่ปัญหาคือ กว่าลูกค้าจะได้เห็นของจริงก็ปาเข้าไปขั้นท้ายๆ แล้ว ถ้าเข้าใจผิดกันตั้งแต่แรก ก็ต้องรื้อแทบทั้งหมด
ยุค Iterative: ราวปี 1980
คนเริ่มสงสัยว่า ทำไมต้องรอให้ทำเสร็จทั้งหมดก่อนแล้วค่อยให้ลูกค้าดู
เลยเกิดแนวคิด Iterative คือแบ่งงานเป็นรอบๆ แต่ละรอบสร้างของที่ใช้ได้จริงขึ้นมาส่วนหนึ่ง เอาให้ลูกค้าดู ฟังว่าเขาว่ายังไง แล้วค่อยทำรอบต่อไป
ลองนึกถึงการสร้างบ้าน
- แบบ Waterfall ช่างจะเขียนแบบทั้งหลังให้เสร็จ แล้วสร้างจนจบ เจ้าของบ้านได้เข้าไปดูอีกทีก็วันส่งมอบ ถ้าห้องครัวเล็กไป ตอนนั้นก็ต้องทุบทิ้ง
- แบบ Iterative รอบแรกสร้างห้องนอนกับห้องน้ำให้อยู่ได้ก่อน เจ้าของเข้าไปอยู่แล้วบอกว่าหน้าต่างหันผิดทาง แดดบ่ายส่องเข้าเต็มๆ ช่างต้องเจาะผนังย้ายหน้าต่างห้องนั้น ซึ่งก็เหนื่อยอยู่ แต่เหนื่อยแค่ห้องเดียว แล้วตอนสร้างห้องครัวรอบต่อไป ช่างก็รู้แล้วว่าหน้าต่างต้องหันไปทางไหน บ้านค่อยๆ โตขึ้นทีละรอบ และไม่ต้องทุบทั้งหลัง
ตัวอย่างดังของยุคนี้คือ Spiral Model ของ Barry Boehm (spiral แปลว่าก้นหอย) แต่ละรอบมี 4 ขั้นวนซ้ำ คือวางแผน หาความเสี่ยงที่น่ากลัวที่สุดแล้วจัดการก่อน สร้าง แล้วให้ลูกค้าดูและประเมิน พอวนรอบใหม่ ของก็ใหญ่ขึ้นเรื่อยๆ เหมือนเส้นก้นหอยที่วงกว้างออกไปทีละรอบ
ข้อดีคือ ถ้าเข้าใจผิดกัน จะเจอตั้งแต่รอบแรกๆ ตอนที่แก้ยังถูกอยู่ ไม่ต้องไปเจอตอนท้ายที่ต้องรื้อทั้งหมด
แต่ยุคนี้แต่ละรอบยังกินเวลาหลายเดือน และยังมีเอกสารเยอะ ซึ่งเป็นเหตุให้ยุคต่อไปอยากทำรอบให้สั้นกว่านี้อีก
ยุค Agile: ราวปี 1990 ถึง 2001
พอเข้ายุค 1990 โลกเปลี่ยนเร็วมาก ทั้งอินเทอร์เน็ต ทั้งธุรกิจออนไลน์
แผนที่วางไว้ปีหนึ่ง พอทำเสร็จ ตลาดก็เปลี่ยนไปแล้ว
ปี 2001 กลุ่มนักพัฒนา software มารวมตัวกันแล้วเขียน Agile Manifesto ออกมา (manifesto = แถลงการณ์ประกาศหลักการ ส่วน agile แปลว่าคล่องตัว)
หัวใจของ Agile สรุปแบบภาษาคนได้ประมาณนี้
- ทำเป็นรอบสั้นๆ ไม่กี่สัปดาห์ แทนที่จะลากยาวเป็นปี
- เอา software ที่ใช้งานได้จริงมาให้ดู สำคัญกว่าเอกสารหนาๆ
- คุยกับลูกค้าบ่อยๆ ตลอดทาง ไม่ใช่คุยแค่ตอนเริ่มกับตอนจบ
- พร้อมเปลี่ยนแผน เมื่อเจอข้อมูลใหม่

เอาตรงๆ นี่คือจุดที่วงการเปลี่ยนวิธีคิดครั้งใหญ่ จากเน้นวางแผนให้เป๊ะ มาเป็นเน้นปรับตัวให้ไว
ยุค Continuous Delivery กับ DevOps: ราวปี 2010
ยุคนี้ software ไม่ได้ขายเป็นแผ่นแล้ว แต่รันอยู่บนเว็บตลอดเวลา
คำถามเลยเปลี่ยนจาก “ปีนี้ออก version ใหม่กี่ครั้ง” เป็น “วันนี้อัปเดตได้กี่ครั้ง”
เกิดสองคำสำคัญ
- Continuous Delivery: ทำให้ software พร้อมปล่อยใช้งานได้ตลอดเวลา โดยให้ระบบอัตโนมัติช่วยทดสอบและปล่อยของ ไม่ต้องรอคนทำมือ
- DevOps: มาจาก Development (ทีมสร้าง) รวมกับ Operations (ทีมดูแลระบบ) คือให้สองทีมที่เคยแยกกันมาทำงานด้วยกัน รับผิดชอบด้วยกัน
ตัวอย่างที่คนชอบยกคือ Netflix
Netflix ปล่อยอัปเดตได้หลายครั้งต่อวัน เพราะใช้ระบบอัตโนมัติช่วยแทบทุกขั้น
ที่เด็ดคือเขามีเครื่องมือชื่อ Chaos Monkey (แปลตรงตัวว่าลิงป่วน) ที่คอยสุ่มปิดระบบบางตัวทิ้งแบบตั้งใจ
อ้าว ทำพังเองเลยเหรอ
ใช่ครับ เพราะอยากรู้ว่าถ้าวันหนึ่งพังจริง ระบบจะยังรอดมั้ย ซ้อมพังตอนพร้อม ดีกว่าไปเจอพังตอนไม่พร้อม
ยุคปัจจุบัน: ADLC
ยุคนี้ไม่ได้เปลี่ยนทีเดียวทั้งหมด แต่ AI ค่อยๆ ขยับเข้ามาทีละขั้น
ขั้นแรก AI เป็นผู้ช่วยข้างตัว
ปี 2021 GitHub เปิดตัว Copilot ซึ่งเป็น AI ที่คอยเดาว่าเราจะพิมพ์โค้ดอะไรต่อ แล้วเติมให้ เหมือนมือถือที่เดาคำถัดไปให้ แต่เดาได้ทีละหลายบรรทัด
ปลายปี 2022 ChatGPT ออกมา คนเริ่มพิมพ์ขอว่า “เขียนโค้ดแบบนี้ให้หน่อย” แล้วก๊อปไปวางเอง
ตอนนั้นคนยังเป็นคนทำงานหลัก AI แค่ช่วยให้พิมพ์เร็วขึ้น
ขั้นต่อมา AI เริ่มรับงานไปทำเองบางส่วน
ทีนี้ AI ไม่ได้แค่ตอบคำถามแล้ว แต่เป็น AI agent คือ AI ที่รับงานไปลงมือทำเองเป็นขั้นๆ ได้ เช่น เปิดไฟล์ แก้โค้ด รันทดสอบ ถ้าพังก็แก้เอง แล้วส่งงานกลับมาให้คนตรวจ
คนเลยเริ่มขยับจาก “คนเขียนโค้ด” ไปเป็น “คนสั่งงานและคนตรวจงาน”
ADLC ย่อมาจาก Agentic Development Lifecycle คือวงจรการสร้าง software ที่ AI agent เป็นคนลงมือทำแต่ละขั้น ส่วนคนตั้งเป้าหมาย แล้วคอยอนุมัติตามด่านสำคัญ
แล้วต่อไปจะไปถึงไหน
ลองไล่ดูทั้งเส้นทาง ตั้งแต่ต้นจนจบ
- ศึกษาตลาด ดูคู่แข่ง ฟังว่าคนต้องการอะไร
- สรุปออกมาเป็น requirement และ spec ว่าจะสร้างอะไร
- ออกแบบ เขียนโค้ด ทดสอบ
- deploy ขึ้นใช้งานจริง แล้วคอยดูว่ามีปัญหาไหม
ตอนนี้ AI ทำข้อ 3 ได้เยอะแล้ว และเริ่มทำข้อ 1, 2, 4 ได้บางส่วน
บางคนเชื่อว่าวันหนึ่ง AI จะทำได้ครบทั้งเส้น ตั้งแต่คิดว่าควรสร้างอะไร จนปล่อยขึ้นใช้งานเอง โดยแทบไม่มีคนเข้าไปแตะ
แนวคิดนี้มีคนเรียกว่า software factory หรือโรงงานผลิต software ถ้ายังมีคนคอยตรวจคอยอนุมัติอยู่ เรียกว่า light factory แต่ถ้าไม่มีคนอยู่ในโรงงานเลย ทำงานเองทั้งหมด จนไม่ต้องเปิดไฟ เรียกว่า dark factory

ฟังดูไกล แต่ก็ใกล้กว่าที่คิดนะ 555+
เรื่องนี้ยังใหม่มาก ชื่อเรียกก็ยังไม่นิ่ง ใครพูดก็เรียกไม่เหมือนกัน
ผมเลยอยากเริ่มจากยุคแรกสุด แล้วเดินมาทีละยุค จะได้รู้ว่าแต่ละขั้นที่ AI กำลังเข้ามาแทน เดิมทีคนทำกันยังไง และทำไมถึงทำแบบนั้น
ซีรีส์นี้ผมจะทำอะไร
ซีรีส์นี้เป็นบันทึกการเรียนของผมเอง ไม่ใช่ตำรา
แต่ละตอนคือหนึ่งยุค แล้วผมจะทำสามอย่าง
- ลองทำเอง: ลองสร้างอะไรเล็กๆ ด้วยวิธีของยุคนั้นจริงๆ ว่ามันรู้สึกยังไง
- เก็บศัพท์: จดคำศัพท์ที่คนยุคนั้นใช้ พร้อมความหมายแบบภาษาคน
- จดบันทึก: สรุปว่าทำแล้วเจออะไร ติดตรงไหน ได้เรียนรู้อะไร
ผมเชื่อว่าการได้ลงมือเอง จะทำให้เข้าใจว่าทำไมแต่ละยุคต้องเปลี่ยนวิธี
และพอเข้าใจของเก่า ก็จะมองของใหม่อย่าง ADLC ออกว่าอะไรเปลี่ยนจริง อะไรแค่เปลี่ยนชื่อ
Next → ตอนหน้าผมจะเริ่มที่ยุคศูนย์หนึ่ง ลองเขียนโปรแกรมแบบคนยุค 1950 ดูซักตั้ง ว่าจะทรมานแค่ไหน 555+