สารบัญ
ทุกบทความในซีรีส์นี้มาจากการที่ผมคุยกับ AI แล้วค้นข้อมูลเพิ่มเติม ผมเป็นคนกำหนดทิศทาง ให้ AI ช่วยสรุป วิเคราะห์ และเรียบเรียงออกมาเป็นบทความครับ
ในตอนที่ 7 ทีมฝนพังแล้วรู้ตัวเร็ว และถอยกลับได้ในไม่กี่นาที
ถึงตรงนั้น ทุกอย่างหลังเขียนโค้ดเสร็จ เครื่องทำให้เกือบหมดแล้ว
ตอนนี้ขยับมาปี 2019
ผมอยากหยุดเล่าทีละยุคไว้ก่อน แล้วถอยออกมาดูภาพใหญ่
งานหนึ่งชิ้น ตั้งแต่ลูกค้าขอ จนลูกค้าได้ใช้ ต้องผ่านมือใครบ้าง
ภาพนี้คือพื้นที่ที่ AI จะเข้ามาในตอนหน้าๆ ถ้าไม่เห็นภาพนี้ก่อน ก็จะไม่เห็นว่า AI เข้ามาช่วยตรงไหน
ฝน ร้าน และทุกคนในร้านยังเป็นตัวละครสมมติ แต่เครื่องมือและเหตุการณ์จริงที่เล่าถึง มีอยู่จริง
ปี 2019 วันแรกของน้องใหม่
ฝนอายุ 49 แล้ว ยังเป็นหัวหน้าทีมของร้านอุปกรณ์เดินป่า
เช้าวันจันทร์ มีน้องใหม่เข้าทีม ชื่อมิว
งานแรกของมิวมาจากลูกค้า
“อยากได้ปุ่มเก็บของที่ชอบไว้ จะได้กลับมาซื้อทีหลัง”
มิวเปิดเครื่อง พร้อมจะเขียนโค้ดเลย
ฝนบอกให้รอก่อน
“เขียนโค้ดเป็นแค่ช่องเดียว มาดูทั้งแผนที่กันก่อน”
แล้วฝนก็หยิบปากกา วาดตัว V ใหญ่ๆ บนกระดาน
ช่องแรก ลูกค้าอยากได้อะไร
ฝนไม่ได้ให้มิวเขียนเอกสาร
ให้การ์ดมาใบเดียว
ด้านบนเขียนว่า “ในฐานะลูกค้า ฉันอยากกดเก็บของที่ชอบ เพื่อกลับมาซื้อทีหลัง”
แบบนี้เรียกว่า user story เล่าว่าใครอยากได้อะไร และอยากได้ไปทำไม
ด้านล่างมีเงื่อนไขว่าเสร็จ 3 ข้อ เรียกว่า acceptance criteria
- กดหัวใจที่หน้าสินค้าแล้ว สินค้านั้นไปอยู่ในหน้ารายการโปรด
- ปิดเว็บแล้วกลับมาใหม่ รายการยังอยู่
- สินค้าในรายการหมดสต็อก ต้องขึ้นบอก
ทำครบ 3 ข้อนี้ ถึงจะเรียกว่าเสร็จ
ในตอนที่ 3 ทีมปี 1968 เขียนสเปกหนาเป็นแฟ้ม แล้วเซ็นปิดก่อนเริ่มงาน
ตอนนี้เหลือการ์ดใบเดียว แต่ชัดกว่า เพราะบอกว่าเสร็จหน้าตาเป็นยังไง
วิธีเขียนแบบนี้ Mike Cohn รวบรวมไว้ในหนังสือ User Stories Applied ปี 2004
การ์ดพวกนี้ ทีมฝนเก็บไว้ใน Jira ที่โตมาจาก Bugzilla ในตอนที่ 5
V-Model คืออะไร?
V-Model คือแผนที่ที่จับคู่ทุกขั้นของการสร้าง กับขั้นตรวจของมันเอง
ฝนชี้ตัว V บนกระดาน
ขาซ้ายเดินลง คือฝั่งสร้าง
ความต้องการลูกค้า ออกแบบทั้งระบบ ออกแบบการต่อกัน ออกแบบแต่ละชิ้น แล้วลงไปถึงก้นตัว V คือเขียนโค้ด
ขาขวาเดินขึ้น คือฝั่งตรวจ
ทดสอบทีละชิ้น ทดสอบตอนต่อกัน ทดสอบทั้งระบบ แล้วขึ้นไปถึงลูกค้าลองใช้
แต่ละชั้นจับคู่ข้ามกัน
ทดสอบทีละชิ้น ตรวจว่าตรงกับที่ออกแบบแต่ละชิ้นมั้ย
ทดสอบตอนต่อกัน ตรวจว่าตรงกับที่ออกแบบการต่อกันมั้ย
ทดสอบทั้งระบบ ตรวจว่าตรงกับที่ออกแบบทั้งระบบมั้ย
ลูกค้าลองใช้ ตรวจกับการ์ดใบแรก ว่าได้ของที่อยากได้จริงมั้ย
รูปตัว V แบบนี้มีคนวาดมาตั้งแต่ปลายยุค 70
ปี 1986 Paul Rook วาดวงจรของซอฟต์แวร์เป็นรูปตัว V ในบทความ “Controlling software projects”
กระทรวงกลาโหมเยอรมนีเริ่มทำมาตรฐานชื่อ V-Modell ปีเดียวกัน แล้วกำหนดให้ใช้ในกองทัพปี 1991
ฝนบอกมิวว่า ทีมไม่ได้เดินตัว V ช้าๆ ทีละเดือนแบบยุคนั้น
แต่วิ่งรอบตัว V วันละหลายรอบ ทุกครั้งที่มีคนแก้โค้ด ฝั่งตรวจเกือบทั้งหมดเครื่องทำให้
ทำไม test ผ่านหมด แต่ของยังพังได้?
เพราะ test แต่ละชั้นตรวจคนละเรื่อง ชิ้นที่ผ่านเมื่อแยกกัน อาจพังตอนเอามาต่อกัน
มิวเขียนส่วนเก็บรายการโปรด กับส่วนแสดงรายการ
test ทีละชิ้นผ่านทั้งคู่
แต่พอต่อกันจริง ส่วนเก็บส่งรหัสสินค้าเป็นตัวเลข ส่วนแสดงรอรับเป็นตัวหนังสือ
หน้ารายการโปรดว่างเปล่า
test ทีละชิ้นไม่มีทางเห็น เพราะแต่ละชิ้นทำถูกตามที่ตัวเองเข้าใจ
ทีมเลยต้องมี test หลายชั้น เป็นรูปพีระมิด เรียกว่า test pyramid
ฐานกว้าง คือ test ทีละชิ้น (unit test) มีเยอะที่สุด รันเร็ว ถูก
ชั้นกลาง คือ test ตอนต่อกัน (integration test)
ยอดแหลม คือ test ทั้งระบบผ่านหน้าจอเหมือนลูกค้ากดจริง มีน้อยที่สุด เพราะช้าและพังง่าย
Mike Cohn คนเดิมเขียนเรื่องพีระมิดนี้ไว้ในหนังสือ Succeeding with Agile ปี 2009
ในตอนที่ 5 ทีมเริ่มมี test อัตโนมัติด้วย JUnit ตอนนี้ฐานพีระมิดยังเป็นแบบนั้น ส่วนยอดพีระมิด ทีมใช้ Selenium ที่เกิดปี 2004 ให้เครื่องเปิดเว็บแล้วกดแทนคน
ก่อนรวมงาน ให้เพื่อนตรวจก่อน
มิวไม่ได้แก้โค้ดกองกลางตรงๆ
แตกสายงานของตัวเองออกมาก่อน เรียกว่า branch
ทำเสร็จ ก็เปิดคำขอรวมงาน เรียกว่า pull request ที่ GitHub เปิดให้ใช้ตั้งแต่กุมภาพันธ์ปี 2008
รุ่นพี่ในทีมเปิดดูทีละบรรทัด แล้วทิ้งความเห็นไว้ 2 จุด เรียกว่า code review
ระหว่างนั้น CI จากตอนที่ 6 ก็รัน test ทั้งพีระมิดให้เอง
คนตรวจผ่าน เครื่องตรวจผ่าน ถึงจะกดรวมกลับเข้ากองกลาง
ผมว่าช่องนี้น่าจับตาที่สุดครับ
เพราะในตอนหน้าๆ งานที่ AI ทำ จะถูกส่งมาเป็น pull request แบบนี้แหละ และคนตรวจจะงานล้นมือ
ชิ้นส่วนที่เราไม่ได้เขียนเอง
ปุ่มหัวใจต้องมีเสียงกับภาพขยับเล็กๆ ตอนกด
มิวไม่ได้เขียนเอง ไปหยิบ package สำเร็จรูปที่คนอื่นแจกฟรีมาใช้
ลงไปตัวเดียว แต่ตัวนั้นใช้ package อื่นอีก และตัวอื่นก็ใช้ต่ออีก
นับดูแล้ว ติดมาอีกหลายสิบตัว
ฝนเล่าเรื่องจริงให้ฟังสองเรื่อง
left-pad ปี 2016
22 มีนาคม 2016 คนเขียน package ชื่อ left-pad ลบมันออกจากที่แจกกลางของ npm
โค้ดสั้นนิดเดียว แต่มี package ใหญ่ๆ ดึงไปใช้ต่อกันเป็นทอดๆ
งานของนักพัฒนาจำนวนมากทั่วโลก build ไม่ผ่านอยู่ราวสองชั่วโมงครึ่ง
Equifax ปี 2017
Equifax บริษัทเก็บข้อมูลเครดิตใหญ่ของอเมริกา ใช้ Apache Struts ชิ้นส่วนฟรีตัวหนึ่ง
7 มีนาคม 2017 คนดูแล Struts ปล่อยตัวแก้ช่องโหว่ออกมา
Equifax ไม่ได้อัปเดตระบบที่โดน
กันยายนปีนั้น Equifax ประกาศว่าข้อมูลส่วนตัวของคนราว 147 ล้านคนรั่ว
ปี 2019 ยอมความกับหน่วยงานรัฐ สูงสุด 700 ล้านดอลลาร์
ตัวแก้มีแล้ว แค่ไม่มีใครเอามาใส่
ให้เครื่องเฝ้าแทน
ทีมฝนเลยใส่ด่านความปลอดภัยไว้ในสายพาน ตั้งแต่ต้นทาง ไม่รอไปตรวจตอนท้าย
แนวคิดนี้เรียกว่า shift-left (ขยับการตรวจไปทางซ้ายของแผนที่) ส่วนการเอาความปลอดภัยเข้ามาอยู่ในสายพานของ DevOps คนเรียกว่า DevSecOps
พฤษภาคมปี 2019 GitHub ซื้อ Dependabot มาใส่ในตัว
มันคอยดูว่า package ที่เราใช้มีช่องโหว่มั้ย ถ้ามี ก็เปิด pull request อัปเดตให้เอง
วันเดียวกัน GitHub เปิดให้ทุกคนใช้ระบบจับรหัสลับที่เผลอหลุดเข้าไปในโค้ด
ทีมฝนใช้ Snyk (ก่อตั้งปี 2015) เช็กช่องโหว่อีกชั้น และ SonarQube ตรวจคุณภาพโค้ด
ทุก pull request ต้องผ่านด่านพวกนี้ก่อนรวม
กล่องเดียวกันทุกเครื่อง
ในตอนที่ 5 ด่านที่ 2 คือเครื่องทดสอบกับเครื่องจริงไม่เหมือนกัน
ตอนที่ 6 ทีมแก้ด้วยสูตรตั้งเครื่อง
ปี 2019 ทีมฝนไปอีกขั้น ใช้ Docker ที่เปิดตัวเดือนมีนาคมปี 2013
Docker ห่อโปรแกรมของร้าน พร้อมทุกอย่างที่มันต้องใช้ ไว้ในกล่องเดียว เรียกว่า container
กล่องเดียวกันนี้ วิ่งบนเครื่องของมิว (dev) เครื่องทดสอบ (staging) และเครื่องจริง (prod)
บนเครื่องมิวใช้ได้ ก็ใช้ได้ทุกเครื่อง
หนี้ที่ไม่มีใครเห็น
ระหว่างทำ มิวไปเจอโค้ดหน้าสินค้าเก่าๆ ที่เขียนรีบๆ ไว้ตั้งแต่ปีก่อน
จะเพิ่มปุ่มหัวใจทีละนิด ก็ต้องแก้ตามไปหลายจุด
ฝนบอกว่านี่คือ technical debt (หนี้ทางเทคนิค)
Ward Cunningham อธิบายไว้ที่งานประชุม OOPSLA ปี 1992 ว่า ปล่อยโค้ดแบบรีบๆ ก็เหมือนกู้เงิน กู้นิดหน่อยช่วยให้ไปได้เร็ว ถ้ารีบใช้คืน
ถ้าไม่คืน ทุกงานใหม่ต้องจ่ายดอกเบี้ยเป็นเวลาที่ช้าลง
คำนี้จะกลับมาอีกตอน AI เขียนโค้ดได้เร็วมากๆ ครับ
SDLC ครบวง งานหนึ่งชิ้นต้องผ่านมือใครบ้าง?
งานหนึ่งชิ้นวนผ่าน 8 ขั้นเป็นวง ตั้งแต่วางแผนจนดูแลต่อ แล้วสิ่งที่เรียนรู้จากขั้นสุดท้าย ก็ไหลกลับไปเป็นงานชิ้นต่อไป
วงนี้เรียกว่า SDLC (Software Development Life Cycle) วงจรชีวิตของการทำซอฟต์แวร์
ถ้ามองย้อนไป ทุกตอนที่ผ่านมาคือการเติมขั้นในวงนี้ทีละขั้น
| ขั้น | เกิดอะไรขึ้น | ใครทำ (ทีมฝนปี 2019) | เครื่องมือปี 2019 | เริ่มเล่าในตอน |
|---|---|---|---|---|
| Planning / Requirements (วางแผน เก็บความต้องการ) | ฟังลูกค้า เขียนการ์ด user story เลือกว่าทำอะไรก่อน | PM กับเจ้าของร้าน | Jira | ตอนที่ 3 สเปก, ตอนที่ 4 ให้ผู้ใช้ลอง, ตอนที่ 5 เจ้าของเลือกงาน |
| Analysis (วิเคราะห์) | ดูว่างานนี้แตะส่วนไหนของระบบ ยากหรือเสี่ยงตรงไหน | PM กับนักพัฒนา | Jira, กระดาน | ตอนที่ 3, ตอนที่ 4 ทำเรื่องเสี่ยงก่อน |
| Design (ออกแบบ) | ออกแบบหน้าจอ และแบ่งระบบเป็นชิ้น | designer กับนักพัฒนา | Figma | ตอนที่ 3 กล่องกับลูกศร, ตอนที่ 7 แยกเป็น service |
| Build (เขียนโค้ด) | เขียนโค้ด แตก branch เปิด pull request | นักพัฒนา | git, GitHub | ตอนที่ 2 บัตรเจาะรู, ตอนที่ 4 เขียนบนจอ, ตอนที่ 5 CVS, ตอนที่ 6 git |
| Test (ทดสอบ) | test ทุกชั้นในพีระมิด ให้เพื่อนตรวจ เช็กความปลอดภัย | นักพัฒนา, QA, คนดูแลความปลอดภัย | JUnit, Selenium, Snyk, SonarQube, Dependabot | ตอนที่ 5 test อัตโนมัติ, ตอนที่ 6 CI, ตอนที่ 8 พีระมิด การตรวจของเพื่อน และด่านความปลอดภัย |
| Release / Deploy (ปล่อยของ) | รวมโค้ดแล้วส่งตามสายพานขึ้นระบบจริง | เครื่องทำ คนกดปุ่ม | Jenkins, Docker | ตอนที่ 6 CI/CD ปล่อยด้วยปุ่มเดียว |
| Operate / Monitor (ดูแลระบบ) | เฝ้าดูว่าระบบปกติมั้ย พังก็ปลุกคนเวร | ops หรือ SRE กับคนเวร | Datadog, PagerDuty, Slack | ตอนที่ 7 monitoring กับ rollback |
| Maintain (ดูแลต่อ) | แก้บั๊ก อัปเดต package ใช้คืนหนี้ทางเทคนิค | นักพัฒนา | Jira, Dependabot | ตอนที่ 5 Bugzilla, ตอนที่ 7 postmortem |
เสร็จขั้นสุดท้าย สิ่งที่เห็นจากการดูแลระบบ บั๊กที่ลูกค้าแจ้ง และเสียงลูกค้า ก็กลายเป็นการ์ดใบใหม่ วนกลับไปขั้นแรก
ตัว V อยู่ตรงไหนในวง
ตัว V คือช่วงกลางของวง ตั้งแต่ความต้องการ ออกแบบ เขียนโค้ด ไปจนถึง test ทุกชั้น
คือช่วงสร้างกับตรวจ
ส่วนวง SDLC เติมสิ่งที่ตัว V ไม่ได้วาด คือปล่อยของ ดูแลระบบ ดูแลต่อ แล้ววนกลับมาเริ่มใหม่
ปี 2019 ทีมฝนวนวงนี้ทุกวัน งานเล็กๆ ชิ้นละไม่กี่วัน
ทุกช่องมีเครื่องช่วยแล้ว
ยกเว้นก้นตัว V
ช่องเขียนโค้ด ยังเป็นมือคนล้วนๆ ทุกบรรทัด
สิ่งที่ผมได้จากยุคนี้
ลองทำเอง
ปุ่มหัวใจของมิวใช้เวลา 3 วัน
ฝนลองนับดู เครื่องตรวจทั้งหมด ทั้ง test ทุกชั้น CI ด่านความปลอดภัย และการปล่อยของ รวมกันไม่ถึงชั่วโมง
ที่เหลือเกือบทั้งหมด มิวใช้ไปกับการเขียนโค้ดซ้ำๆ แบบที่เคยเขียนมาแล้ว และนั่งค้นเว็บว่า package ตัวนั้นใช้ยังไง
ในคิวยังมีการ์ดจากลูกค้ารออีก 40 ใบ
ผมว่าเรื่องสำคัญของตอนนี้คือ ก่อนจะเร่งอะไร ต้องเห็นทั้งวงก่อน แล้วถึงจะรู้ว่าเวลาไปจมอยู่ช่องไหน
เก็บศัพท์
| ศัพท์ | ความหมายแบบภาษาคน |
|---|---|
| SDLC | วงจรชีวิตของการทำซอฟต์แวร์ ตั้งแต่วางแผนจนดูแลต่อ แล้ววนใหม่ |
| user story | การ์ดที่บอกว่าใครอยากได้อะไร และอยากได้ไปทำไม |
| acceptance criteria | เงื่อนไขว่าเสร็จ ทำครบทุกข้อถึงเรียกว่าเสร็จ |
| V-Model | แผนที่ที่จับคู่ทุกขั้นของการสร้าง กับขั้นตรวจของมัน |
| unit test | test ทีละชิ้นเล็กๆ |
| integration test | test ตอนเอาหลายชิ้นมาต่อกัน |
| test pyramid | test ชิ้นเล็กมีเยอะที่สุด test ทั้งระบบมีน้อยที่สุด |
| branch | สายงานที่แตกออกมาจากโค้ดกองกลาง |
| pull request | คำขอรวมงานจาก branch กลับเข้ากองกลาง |
| code review | ให้เพื่อนในทีมอ่านโค้ดก่อนรวม |
| package | ชิ้นส่วนโค้ดสำเร็จรูปที่คนอื่นเขียนแจกไว้ |
| shift-left | ขยับการตรวจไปทำตั้งแต่ต้นทาง |
| DevSecOps | เอาความปลอดภัยเข้ามาอยู่ในสายพานของ DevOps |
| container | กล่องที่ห่อโปรแกรมกับทุกอย่างที่มันต้องใช้ ไปวิ่งได้เหมือนกันทุกเครื่อง |
| dev / staging / prod | เครื่องนักพัฒนา / เครื่องทดสอบ / เครื่องจริง |
| technical debt | โค้ดที่เขียนรีบไว้ แล้วทำให้งานต่อๆ ไปช้าลง |
จดบันทึก
ถ้าเพิ่งเข้ามาอ่านตอนนี้ ย้อนไปเริ่มที่ตอนที่ 1 ได้ครับ
ตอนที่ 2 สอนว่ายิ่งรู้ว่าผิดช้า ยิ่งเจ็บ
ตอนที่ 3 สอนว่ารอยต่อระหว่างคนคือที่ที่ความผิดซ่อนอยู่
ตอนที่ 4 สอนว่าให้คนใช้ดูเร็ว
ตอนที่ 5 ทำให้โค้ดเสร็จทุกสองสัปดาห์
ตอนที่ 6 ทำให้โค้ดถึงมือลูกค้าในวันเดียวกัน
ตอนที่ 7 ทำให้พังแล้วรู้เร็ว และฟื้นเร็ว
ตอนนี้ประกอบทุกอย่างเป็นวงเดียว
ฝนยืนมองตัว V บนกระดานอยู่นาน
แล้วถามขึ้นมาว่า “ถ้าช่องเขียนโค้ดมีผู้ช่วยบ้างล่ะ”
คำถามที่พบบ่อย
SDLC ต่างจาก DevOps ยังไง?
SDLC คือแผนที่ของทุกขั้นที่งานหนึ่งชิ้นต้องผ่าน ตั้งแต่วางแผนจนดูแลต่อ ส่วน DevOps คือวิธีทำงานที่ทำให้ช่วงปล่อยของกับดูแลระบบในวงนี้เร็วขึ้น โดยให้คนเขียนโค้ดกับคนดูแลเครื่องเป็นทีมเดียว และให้เครื่องทำงานซ้ำๆ แทนคน
user story คืออะไร?
การ์ดสั้นๆ ที่บอกว่าใครอยากได้อะไร และอยากได้ไปทำไม เช่น “ในฐานะลูกค้า ฉันอยากกดเก็บของที่ชอบ เพื่อกลับมาซื้อทีหลัง” พร้อมเงื่อนไขว่าเสร็จอีกไม่กี่ข้อ
pull request คืออะไร?
คำขอรวมงานที่ทำแยกไว้ใน branch กลับเข้าโค้ดกองกลาง ให้เพื่อนในทีมอ่านและให้เครื่องรัน test ก่อนกดรวม
ทำไมต้องสนใจ package ที่เราไม่ได้เขียนเอง?
เพราะ package ตัวเดียวอาจดึงตัวอื่นตามมาอีกหลายสิบตัว ถ้าตัวไหนมีช่องโหว่แล้วไม่อัปเดต ระบบเราก็โดนไปด้วย แบบที่เกิดกับ Equifax ในปี 2017
technical debt คืออะไร?
โค้ดที่เขียนรีบๆ ไว้ก่อน ช่วยให้ไปได้เร็วตอนนั้น แต่ถ้าไม่กลับมาแก้ งานต่อๆ ไปจะช้าลงเรื่อยๆ เหมือนจ่ายดอกเบี้ย
Next → ตอนที่ 9: AI ผู้ช่วยข้างคีย์บอร์ด ตอนหน้าเข้ายุค AI ช่องสุดท้ายที่ยังเป็นมือคนล้วนๆ คือช่องเขียนโค้ด จะเริ่มมีผู้ช่วย ผมจะลองดูครับว่ามันช่วยได้แค่ไหน และอะไรเปลี่ยนไปในวงนี้บ้าง
