คำว่า “design system” ในที่นี้ ไม่ได้หมายถึงชุดปุ่มและสีของหน้าเว็บ แต่หมายถึงการออกแบบว่าซอฟต์แวร์ทั้งระบบจะถูกประกอบขึ้นมาอย่างไร ซึ่งคำถามที่วิศวกรเจอทุกวันคือ “จะเริ่มจากอะไร และเผื่ออะไรไว้แค่ไหน”
อธิบายด้วยคำศัพท์เทคนิคจะยาว แต่อธิบายด้วยการสร้างบ้านจะสั้นมาก เพราะซอฟต์แวร์กับบ้านมีนิสัยเหมือนกันอย่างน่าตกใจ คือเริ่มเล็ก แล้วคนอยู่ก็อยากได้อะไรเพิ่มไปเรื่อย ๆ ต่างกันแค่ว่าเราจะวางแผนเรื่องนั้นไว้ตั้งแต่แรก หรือรอให้มันเกิดขึ้นก่อน
อ่านคำบรรยายทั้งหมด
ทางที่ 1: สร้างบ้านหลังเล็กก่อน แล้วค่อยเติม
วิธีนี้เริ่มจากสิ่งที่ต้องการจริงวันนี้ข้อเดียว แล้วเติมความต้องการใหม่เข้าไปทีละเรื่อง ที่เกิดขึ้น ดูว่าบ้านเปลี่ยนไปอย่างไรในแต่ละเหตุการณ์
1เริ่มต้น
บ้าน: สร้างบ้านเล็กหลังเดียว มีประตูบานเล็ก พออยู่สบายสำหรับวันนี้
ซอฟต์แวร์: ระบบแรกที่ทำเพียงงานเดียว เสร็จเร็ว ใช้งานได้จริง ทุกคนดีใจ
2อยากได้ตู้เย็นใหญ่
บ้าน: ตู้เย็นเข้าประตูไม่ได้ ต้องทุบผนังรอบประตู เศษอิฐกระจาย
ซอฟต์แวร์: ฟีเจอร์ใหม่ไม่เข้ากับของเดิม ต้องรื้อส่วนที่เคยทำเสร็จแล้วเพื่อให้มันเข้าไปได้
3อยากได้พื้นที่เพิ่ม
บ้าน: ต่อเติมชั้น 2 สีผนังไม่เหมือนเดิม บันไดแปะอยู่ข้างบ้าน ฐานรากยังเป็นของเดิม
ซอฟต์แวร์: ของใหม่ถูกแปะบนของเก่า ใช้ได้ แต่แต่ละชิ้นไม่ได้ออกแบบมาเข้าด้วยกัน
4ผ่านไปหลายปี
บ้าน: ผนังเริ่มร้าว บ้านเอียง ฐานรากรับน้ำหนักที่ไม่เคยถูกคิดไว้ไม่ไหว ต้องตั้งนั่งร้านซ่อม
ซอฟต์แวร์: แก้จุดหนึ่งพังอีกจุด ทุกการเปลี่ยนแปลงช้าลงและเสี่ยงขึ้นเรื่อย ๆ
ข้อดีของทางนี้ชัดเจน คือได้บ้านเร็ว ใช้เงินน้อยในวันแรก และไม่ต้องเดาอะไรเลย ปัญหาอยู่ที่เหตุการณ์ถัดไป ตู้เย็นที่ใหญ่กว่าประตู ชั้นสองบนฐานรากเดิม ทุกครั้งที่ต่อเติม เรากำลังสร้างบนสิ่งที่ไม่ได้ถูกออกแบบมารองรับมัน ต้นทุนไม่ได้หายไป มันแค่ถูกเลื่อนไปจ่ายทีหลัง พร้อมดอกเบี้ย
ทางที่ 2: เอาการใช้งานทั้งหมดมาตั้งต้น แล้วค่อยออกแบบ
อีกวิธีคือกลับลำดับ ก่อนวางอิฐก้อนแรก ลิสต์ทุกอย่างที่บ้านนี้อาจต้องรองรับให้ครบ แล้วออกแบบให้ทั้งหมดอยู่ร่วมกันได้ตั้งแต่แรก
1ตั้งต้นจากทุกการใช้งาน
บ้าน: รวบรวมให้หมดก่อนว่าบ้านนี้อาจต้องมีอะไร ตู้เย็นใหญ่ ชั้นสอง สวน รถ บ่อน้ำ
ซอฟต์แวร์: ถามทุกคนก่อนเขียนโค้ด ว่าระบบนี้อาจต้องทำอะไรบ้างในอนาคต แล้วเขียนเป็นแบบ
2ลงฐานรากให้พอ
บ้าน: ลงเสาเข็มลึกและโครงสร้างแข็งแรง ส่วนที่แก้ทีหลังยากที่สุดทำให้เสร็จก่อน
ซอฟต์แวร์: ตัดสินใจเรื่องโครงสร้างหลัก ข้อมูลเก็บที่ไหน ส่วนต่าง ๆ คุยกันอย่างไร ให้รองรับของที่โตขึ้นได้
3แบ่งห้องให้ชัด
บ้าน: ตึกใหญ่ที่แบ่งห้องเป็นสัดส่วน ประตูกว้าง มีสวน ทุกส่วนมีหน้าที่ของตัวเอง
ซอฟต์แวร์: แยกระบบเป็นส่วน ๆ ที่ชัดเจน ส่วนหนึ่งเปลี่ยนได้โดยไม่ลามไปทั้งหลัง
4อยากได้ตู้เย็นใหญ่ และชั้นเพิ่ม
บ้าน: ตู้เย็นเลื่อนผ่านประตูกว้างได้เนียน ชั้นบนต่อเพิ่มได้โดยไม่ต้องทุบอะไร
ซอฟต์แวร์: ฟีเจอร์ใหม่เสียบเข้ามาตรงที่เตรียมไว้ ไม่ต้องรื้อของเดิม
สุดท้ายเราได้ตึกใหญ่ที่แบ่งห้องชัดเจน มีสวน มีเสาเข็มที่แข็งแรง และเมื่อเหตุการณ์เดิมมาถึง ตู้เย็นใหญ่ ชั้นเพิ่ม ทุกอย่างเข้าที่ได้โดยไม่ต้องทุบ แต่ราคาที่จ่ายก็จริงเช่นกัน คือกว่าจะได้อยู่ต้องรอนานกว่า จ่ายหนักกว่าตั้งแต่วันแรก และถ้าบางเรื่องที่วางแผนไว้ไม่เคยเกิดขึ้น เราก็จ่ายค่าเตรียมพร้อมไปฟรี ๆ
| ทีละหลัง | วางแผนก่อน | |
|---|---|---|
| ได้ใช้งานครั้งแรก | เร็วมาก | ช้ากว่า |
| ค่าใช้จ่ายวันแรก | ต่ำ | สูง |
| เมื่อมีความต้องการใหม่ | ต้องทุบ ต่อเติม ปะ | เสียบเข้าที่เตรียมไว้ |
| ความเสี่ยง | ซ่อมแพงขึ้นเรื่อย ๆ | เตรียมของที่ไม่เคยได้ใช้ |
แล้ว over engineering คืออะไร?
พูดง่าย ๆ คือ “ทำเกินกว่าที่จำเป็น” เหมือนสร้างบ้านหลังเล็กหลังเดียว แต่ลงเสาเข็มที่แข็งแรงพอสำหรับตึกสิบชั้น ใครเห็นก็บอกว่าเปลืองเกินไป ในโลกซอฟต์แวร์ เราได้ยินคำนี้บ่อยมาก ใช้ตำหนิทั้งแผนที่ใหญ่เกินตัว และระบบที่ซับซ้อนกว่าที่งานต้องการ
แต่มีเรื่องหนึ่งที่คนมักไม่พูดกัน คือ คำว่า “เกิน” ตัดสินได้ก็ต่อเมื่อรู้อนาคต และข้อนี้วิศวกรเองก็ไม่รู้ ลองดูเรื่องเดิมอีกรอบ ด้วยคำถามเดียวคือ ถ้าวันหนึ่งเจ้าของบ้านอยากได้บ่อน้ำล่ะ
1วันนี้ลงเสาเข็มเล็ก
บ้าน: บ้านหลังเล็ก งบพอดี ลงเสาเข็มเล็กตามขนาดบ้าน ไม่เกินตัวเลยสักนิด
ซอฟต์แวร์: ออกแบบให้พอดีกับความต้องการที่รู้อยู่ ณ วันนี้ ไม่ทำเผื่อ
2วันหนึ่งอยากได้บ่อน้ำ
บ้าน: บ่อน้ำหนักมาก เสาเข็มเล็กรับไม่ไหว บ้านเอียงและร้าว
ซอฟต์แวร์: มีสิ่งหนึ่งที่ไม่เคยคิดว่าจะเกิด และโครงสร้างเดิมรับไม่ได้
3อีกโลกหนึ่ง ถ้าลงเสาเข็มใหญ่ไว้ก่อน
บ้าน: ถ้ารู้ว่าจะมีบ่อน้ำ คงลงเสาเข็มใหญ่ไปแต่แรก แต่ถ้าไม่มีบ่อน้ำ ใคร ๆ ก็จะบอกว่าบ้านหลังเล็กลงเสาเข็มใหญ่เกินไปเยอะ
ซอฟต์แวร์: ทำเผื่อไว้เยอะ ถ้าไม่ถูกใช้ ก็คือต้นทุนที่จ่ายทิ้ง ถ้าถูกใช้ ก็คือการตัดสินใจที่ฉลาด
4ไม่มีใครรู้อนาคต
บ้าน: บ่อน้ำ หอคอย สวน หรือไม่มีอะไรเลย ปลายทางซ่อนอยู่ในหมอก
ซอฟต์แวร์: วิศวกรออกแบบจากสิ่งที่รู้ แล้วเดาส่วนที่ไม่รู้ให้ดีที่สุดเท่าที่ทำได้
ถ้าบ่อน้ำไม่เคยเกิดขึ้น เสาเข็มใหญ่ก็คือ over engineering เต็มตัว แต่ถ้ามันเกิดขึ้น เสาเข็มเล็กคือการประหยัดที่พลาด ตัดสินใจเหมือนกันทุกอย่าง ต่างกันที่ผลของอนาคตที่ไม่มีใครเห็น มันมีสองทางที่พลาดได้
วันนี้เกิน แต่วันหน้าพอดี
เสาเข็มใหญ่ที่ตอนนั้นดูเปลือง กลับรับบ่อน้ำ ชั้นเพิ่ม และอะไรอีกมากได้สบาย คนที่ตัดสินใจครั้งนั้นดูเหมือนมองการณ์ไกล
วันนี้พอดี แต่วันหน้าไม่ไหว
ทุกอย่างพอดีกับความต้องการวันนั้น ดูสมเหตุสมผลทุกขั้น จนความต้องการที่ไม่เคยคิดมาถึง แล้วระบบก็ขยายต่อไม่ได้
ตรงนี้คือความจริงที่ไม่ค่อยมีใครยอมรับ ตอนตัดสินใจ วิศวกรไม่ได้รู้ว่าอันไหนเกิน อันไหนพอดี รู้แค่ว่าตอนนี้ข้อมูลมีเท่าไร และเดาอนาคตได้ดีแค่ไหน คำว่า over engineering จึงมักถูกพูดหลังเรื่องจบ เมื่อเรารู้แล้วว่าอนาคตเป็นอย่างไร
สรุปสั้น ๆ
ทั้งสองทางไม่มีทางไหนถูกตลอด
ทีละหลังเร็วและถูกในวันแรก วางแผนก่อนมั่นคงกว่าในวันที่ต้องโต แต่ละทางซื้อสิ่งหนึ่งโดยแลกกับอีกสิ่งหนึ่ง
ส่วนที่แก้ยาก ควรคิดนานกว่าส่วนที่แก้ง่าย
เสาเข็มกับสีผนังไม่เหมือนกัน สีทาใหม่ได้ทุกเมื่อ แต่ฐานรากแก้ทีหลังแทบไม่ได้ วิศวกรมักใช้เวลากับส่วนแรกมากกว่า
การเดาอนาคตเป็นส่วนหนึ่งของงาน
เราเดาผิดได้ และจะผิดบ้างแน่นอน เป้าหมายจึงไม่ใช่การเดาให้ถูกทุกครั้ง แต่คือไม่เดาผิดแบบที่แก้ไม่ได้
สิ่งที่ Engineer อยากรู้ก่อนออกแบบ
ที่จริงทั้งหมดนี้คือเหตุผลที่วิศวกรมักถามกลับว่า “จะเอาไปใช้ทำอะไร” ก่อนตอบว่า “ทำได้” เพราะยิ่งรู้คำตอบของคำถามเหล่านี้มาก การเดาอนาคตยิ่งแม่นขึ้น และโอกาสลงเสาเข็มผิดขนาดก็ยิ่งน้อยลง
ความสัมพันธ์ของข้อมูล
อะไรเกี่ยวข้องกับอะไร
ลูกค้า ออเดอร์ และสินค้า โยงกันอย่างไร ถ้าผังความสัมพันธ์ผิด ทุกอย่างที่สร้างทับจะเอียงตามไปด้วย
เหมือนบ้าน: ครัวต้องอยู่ใกล้ท่อน้ำ ห้องน้ำกับห้องนอนควรอยู่ติดกันไหม
ปริมาณข้อมูล
วันนี้เท่าไร ปีหน้าเท่าไร
ร้อยรายการกับร้อยล้านรายการ ต้องออกแบบคนละแบบ แม้หน้าตาที่ผู้ใช้เห็นจะเหมือนกัน
เหมือนบ้าน: บ้านสำหรับ 3 คน กับหอพัก 300 คน ใช้เสาเข็มคนละแบบ
use case ในการใช้งานข้อมูล
ข้อมูลถูกใช้ทำอะไร
อ่านบ่อยหรือเขียนบ่อย ดูรายงานเดือนละครั้งหรือกดทุกวินาที ใช้งานแบบไหนก็จัดเก็บแบบนั้น
เหมือนบ้าน: ครัวร้านอาหารกับครัวที่บ้าน ออกแบบไม่เหมือนกัน
จำนวนคนใช้พร้อมกัน
ช่วงที่คนเข้ามากที่สุดคือเมื่อไร
ระบบที่รับคนร้อยคนได้ ไม่ได้แปลว่ารับคนสิบล้านคนในวันเปิดจองได้
เหมือนบ้าน: ห้างวันธรรมดากับวันลดราคา คนเท่ากันไหม
ความเร็วและความพร้อมใช้งาน
รอได้กี่วินาที ล่มได้กี่นาที
ยิ่งต้องเร็วและต้องไม่ล่ม ยิ่งแพง จึงต้องรู้ก่อนว่าเรื่องไหนสำคัญจริง
เหมือนบ้าน: ลิฟต์โรงพยาบาลกับลิฟต์บ้านพัก ยอมให้เสียไม่เท่ากัน
ความถูกต้องและความปลอดภัย
ข้อมูลผิดได้ไหม ใครเข้าถึงได้บ้าง
ยอดเงินผิดหนึ่งบาทไม่ได้ แต่ยอดไลก์ผิดนิดหน่อยได้ ข้อมูลส่วนตัวต้องจำกัดคนเข้าถึง
เหมือนบ้าน: กุญแจบ้านกับกุญแจห้องนิรภัย ไม่ควรเป็นดอกเดียวกัน
ความต้องการเปลี่ยนบ่อยแค่ไหน
ส่วนไหนจะถูกแก้เรื่อย ๆ
ส่วนที่ต้องเปลี่ยนบ่อยต้องออกแบบให้เปลี่ยนง่าย ส่วนที่เปลี่ยนยากต้องคิดให้รอบคอบกว่า
เหมือนบ้าน: ฉากกั้นห้องเลื่อนได้ กับผนังรับน้ำหนักที่ทุบไม่ได้
งบ เวลา และทีมที่ดูแล
ทำอะไรได้จริง และใครจะดูแลต่อ
ระบบที่ซับซ้อนเกินกว่าที่ทีมจะดูแลไหว คือหนี้ที่รอวันทวง
เหมือนบ้าน: บ้านสวยแต่ไม่มีใครซ่อมได้ ก็ไม่ใช่บ้านที่ดี