Residuality Theory กับการออกแบบ Software Architecture
We need more architects, period.
เล่าแบบสรุป ๆ แต่อาจจะยาวหน่อย (วีดีโอ ~52 นาที) แบ่งเป็น 3 ส่วน
- ปัญหา
- Residuality Theory
- Contagion Analysis
ปัญหา
ปัญหาที่เค้าเล่ามาตรงใจมากคือว่า “We need more architects” ดูจะเป็นปัญหาระดับโลกเลยทีเดียว ที่เรามี architects น้อยเกินไป แล้วคนที่เป็นในระดับดู Architects ได้ เค้าก็เรียนรู้เหมือนกับว่าตกเหวไปแล้วปีนขึ้นมาเองได้ ส่วนคนที่ตกเหวไปแล้วปีนขึ้นมาไม่ได้ก็ไม่ได้เป็น architects อะไรประมาณนี้ LOL
ทีนี้เค้าเกริ่นว่าทำไม software architecture ถึงได้ยากนัก เป็นเพราะว่าโลกเรามีเรื่อง order กับ disorder โดยที่พวก software ต่าง ๆ เป็น order คือเรารู้ว่าใส่ input อะไรลงไป เราจะได้ output อะไรออกมา แต่พวก requirements/biz/human เป็น disorder เหมือนคนที่จะทำอะไรก็ตามก็ต่อเมื่อเค้าอยากทำ เช่น เด็กวัยรุ่นที่ทำอะไรก็มักจะ surprise พวกเราตลอดเวลา
ทีนี้เราเหมือนเอา software เราที่เป็นแบบ order เอาไปวางในวง disorder ตามรูปด้านล่าง แล้ว X นี่คือพวก unknown ต่าง ๆ เช่น feature หรือ system failure พยายามที่จะเข้ามาพัง software ของเรา ซึ่งวิธีในการจัดการในระดับหนึ่งคือการทำ requirement engineering กับ risk management นั่นเอง
แต่ทีนี้ก็ยังมี X (ตัวสีแดง) ที่เป็น unknown unknown จริง ๆ ที่เราหลีกเลี่ยงไม่ได้ และต้องหาวิธีจัดการ
ซึ่งการแก้ปัญหา X (ตัวสีแดง) นี่แหละคือ Residuality Theory ที่เค้าคิดขึ้นมา พอดีคนพูดเค้าสนใจเรื่อง complexity theory แล้วเอาแนวคิดพวกนี้มาใช้กับ software engineering และเพื่อให้ทุกคนเข้าถึงแนวคิดนี้ได้ ก็เลยนิยามสิ่งนี้ขึ้นมา เป็นสะพานเชื่อมกันระหว่าง complexity theory กับ software engineering
Residuality Theory
Residuality Theory จะบอกว่า มีระบบหนึ่ง ที่มีของข้างในเชื่อมต่อ ทำงานร่วมกัน แล้วถ้ามี something X going to happen และเมื่อเกิดขึ้น ระบบนี้ก็จะเปลี่ยนไป ซึ่งเราจะเรียกส่วนที่คงเหลืออยู่ว่า “residue” และ ถ้ามีอะไรสักอย่างเกิดขึ้นอีก future ของระบบนั้น จะเป็น function ของ residue
พูดง่าย ๆ คือ เราออกแบบ architecture ขึ้นมาสักตัวหนึ่ง แล้วใส่ X เข้าไป แล้วใน architecture ของเราอาจจะมี component บางตัวล่ม บางตัวอยู่รอด หรือต้องเพิ่ม component ใหม่ ซึ่งผลลัพธ์หลังจากใส่ X เข้าไป ก็คือ new architecture หรือที่เค้าเรียกว่า residue นั่นเอง
และเนื่องจากเราไม่สามารถควบคุม X ได้ ว่าเราจะเจออะไรบ้าง แต่เราควบคุม residue ได้! ว่าเราอยากจะให้มันเป็นแบบไหน
..ตรงนี้จะไปพูดถึงศาสตร์ complexity ขอข้ามไปนะ..
ถ้าเราเอา architecture ของเรามาเจอ X เข้าไปเรื่อย ๆ (ที่แตกต่างกันไป) เราก็จะได้ภาพ architecture หลาย ๆ ภาพ
และถ้าเราเอาทุกภาพมารวมกัน เราก็จะได้ภาพ architecture ที่แข็งแกร่ง ทนทานต่อ X ที่ผ่านเข้ามา
ทีนี้เค้ายกตัวอย่างระบบชาร์จไฟรถยนต์ให้เห็นภาพมากขึ้นด้วย เค้าออกแบบระบบขึ้นมาก่อน (อาจจะเรียกว่า naive architecture) เสร็จแล้วเอา X มาลิสต์
คอลัมน์ทางขวาสุดคือ change ที่เพิ่มเข้าไป ซึ่งอาจจะเพิ่มระบบใหม่เข้าไปด้วย เช่น ALPR (automatic license plate recognition) เติมเข้ามาเพื่อยืนยันเจ้าของรถ และป้ายทะเบียน ทำให้ชาร์จไฟได้ ตอนที่เกิดเหตุการณ์ที่ไม่คาดคิด X และในทีนี้คือ.. ไม่สามารถล็อกอินจากกุญแจได้
หมายเหตุ: stressor นี่ก็คือ X นั่นแหละ แต่เค้าเปลี่ยนคำใหม่
พอผ่าน X หมดเราก็จะได้ good architecture
Contagion Analysis
ยังไม่จบ ยังเหลือขั้นตอนสุดท้ายอีก 1 ขั้นหลังจากเราได้ good architecture จาก residue มาแล้ว คือให้ดูที่ stressor แต่ละตัวมันไปกระทบกับ component ไหนบ้าง เช่น ในรูปด้านล่าง
มีไปกระทบ C กับ G ซึ่งตอนที่เราออกแบบ เราอาจจะแยก C กับ G ออกจากกันในแง่ functional ที่ทำงานแตกต่างกัน แต่ stressor ดันไปกระทบ.. เค้าเลยบอกว่า จริง ๆ แล้ว C กับ G เนี่ยมัน coupling กันนะ แต่เป็น non-functional coupling.. (ผมนี่ตาสว่างกับคำนี้มาก 🤩)
ถ้าเราเจอ non-functional coupling แบบนี้ และอาจจะมีหลายเส้นเลย วิธีแก้ที่เค้าแนะนำคือให้ทำ incidence matrix
โดยที่แถวคือ X หรือ incident หรือ unknown unknown ที่เกิดขึ้น แล้วคอลัมน์คือ component ที่เรามีอยู่ เช่น ถ้า Server failure ไปกระทบ component อะไรบ้าง ก็ให้ใส่เลข 1 ไว้ แล้วเราจะเห็นได้ว่า ผลรวมของ Server failure เนี่ย รวมแล้วได้ 5 เลย แปลว่าถ้าเกิดเหตุการณ์นี้ขึ้น มันจะ impact มาก ดังนั้นวิธีแก้คือ.. ทำอย่างไงให้มันไม่กระทบไปมากกว่านี้ ก็คือไป refactor ซะ
ส่วนผลรวมที่คอลัมน์จะบอกว่า component ไหนของเราบอบบางบ้าง วิธีแก้ก็มีหลากหลาย เช่น เพิ่ม replica ไหม บลา ๆ เวลาเกิดเหตุการณ์พวกนี้จะได้ทนได้ เราอาจจะเปลี่ยนจากเลข 1 เป็น 0 ก็ได้ ใน component นั้น ๆ
สรุปสุดท้าย..
ถ้าเรามี matrix นี้ เราก็จะอธิบายการออกแบบ architecture ได้เพิ่มขึ้น ก่อนหน้านี้เราอาจจะมีของพวกนี้อยู่ในหัว หรือบน whiteboard แต่เราอาจจะไม่เข้าใจว่าทำไมต้องมีของพวกนี้ ซึ่งตอนนี้เรามีแล้ว
ขั้นตอนพวกนี้ดูแล้วเราสามารถเอามาสอนวิธีคิดต่อได้แบบเป็นขั้นเป็นตอนด้วยนะ น่าจะลดคำตอบเวลาน้อง ๆ มาถามว่า “ทำไมพี่ออกแบบไว้แบบนี้?” ตอบ.. “เออ พี่ก็ไม่รู้เหมือนกันว่ะ รู้แค่ว่ามันต้องแบบนี้แหละ ถึงจะรอด” 😂
งานนี้เป็นงานวิจัยด้วยนะ ลองไปอ่านกันได้นะครับ 👉🏻 An Introduction to Residuality Theory: Software Design Heuristics for Complex Systems
ปล. เค้าปิดท้ายด้วย Proof แต่คิดว่าไปดูกันเองดีกว่า สรุปแบบง่าย ๆ คือ เหมือนนับจำนวน X ที่ architecture เราสามารถทนได้ เทียบกับตัว architecture ก่อนหน้านี้ ถ้ามีค่ามากกว่า ก็แปลว่า architecture ตัวใหม่เราดีกว่าเดิม
