DotA 7.21 กับสถาปัตยกรรมซอฟต์แวร์
วันนี้ DotA พึ่งออกแพตช์ใหม่ที่ทำให้ผมนึกเรื่องสถาปัตยกรรมซอฟต์แวร์ได้
หนึ่งในการเปลี่ยนแปลงรอบนี้คือ
“All heroes’ primary attribute growth values increased by 15%”
อยากถามให้คิดเล่นๆ ว่า ถ้าเราพัฒนา DotA แล้วท่านลอร์ด Gaben ส่ง Requirement แบบนี้มา คุณจะ Implement อย่างไร
ผมอยากให้จินตนาการก่อนว่า คุณไม่เคยเล่น DotA ไม่รู้จักเกมนี้เลย
คุณรู้แค่ว่า Hero ทุกตัวมี Strength, Agility, Intelligence คุณรู้ว่าแต่ละฮีโร่มี Primary Stats คุณรู้ว่าเวลาเลเวลอัพ ทุกฮีโร่จะได้ Stats เพิ่ม และคุณรู้ว่าท่านลอร์ด Gaben ต้องการให้ Stats ที่เพิ่มใน Patch นี้ สูงขึ้น 15%
ถ้าคุณไม่รู้อะไรขนาดนั้น วิธีการ Implement ที่ง่ายที่สุดคือ
class Hero { // ...... อย่างอื่น
public double getStatsGainPerLevel() {
return this.statsGainPerLevel * 1.15
}}
ตรงตาม Requirement เด๊ะๆ เลย ออก Patch 7.21 กันเถอะ
พอซักพัก งานแข่งขัน TI9 ออกมา พบว่า Phantom Assassin มันโหดมาก ท่าน Lord Gaben ก็เลยบอกว่า แพตช์หน้าเราต้องลด Stats Gain ของ Phantom Ass เหลือ 3.5 ต่อเลเวลนะ
ปัจจุบัน stats gain ของ Phantom Assassin อยู่ที่ 3.2
หลังจาก Patch 7.21 อยู่ที่ 3.2 x 115% = 3.68
ทีนี้คุณจะลดลงเหลือ 3.5 ก็ต้องหักออก 0.18
เราก็จะได้แบบนี้
class PhantomAssassin extends Hero {// ...... อย่างอื่น
public double getStatsGainPerLevel() {
return (this.statsGainPerLevel * 1.15) - 0.18
// 3.5 According to Lord Gaben rules
}}
ทีนี้ Patch หน้าถ้าท่าน Gaben บอกให้ปรับอีก รอบนี้เราต้อง Buff แล้วนะ ไม่มีใครเล่น Phantom Ass เลย เอาซัก 3.6 ละกัน
เราก็ต้องมาคำนวณใหม่ว่าต้องบวกเท่าไหร่ลบเท่าไหร่
โค้ดก็จะยุ่งเหยิงมากๆ
แต่ทีนี้ถ้าคุณเคยเล่น DotA มาระยะนึง คุณจะรู้ว่า การ Implement แบบนี้คือมันบ้ามากๆ
คุณจะรู้ว่าฮีโร่ทุกตัวถูกปรับ Stats ถูก Nerf ถูก Buff ตลอดเวลา ทุกแพตช์
คุณจะรู้ว่า Requirement นี้คุณควรจะไปแก้ Stats Gain ของฮีโร่ทุกตัวในฐานข้อมูล ให้เพิ่มขึ้น 15% ไม่ใช่มาตั้งสูตรคำนวนแบบนี้
คุณอาจจะปรับด้วยมือ หรืออาจจะปรับด้วย Script ก็ตามแต่
แต่สุดท้ายคุณจะรู้ว่า มันต้องไปปรับเลขทุกตัวทีละตัว ในฐานข้อมูล
คุณจะทำแบบนั้น
แต่ลองนึกดูนะครับว่า สมมติ ถ้าคุณเป็น Senior Developer แล้วมี Junior มาถาม
“พี่ครับ บอสก็สั่งให้เราปรับทุกตัวนี่หว่า ทำไมพี่ไม่คูณ 1.15 ไปที่คลาสฮีโร่เลย ในเมื่อทุกตัวก็ Extend จากฮีโร่อยู่แล้ว พี่จะมานั่งแก้ฐานข้อมูลทีละตัวทำไมครับ ผมทำเงี้ย 3 บรรทัดเสร็จ”
คุณจะตอบ Junior Developer คนนั้น ว่าอย่างไรดีครับ
ขอฝากเป็นคำถามให้คิดนะ ขอไม่เฉลย
บทความนี้ผมอยากให้เห็นว่า ความเชี่ยวชาญ Business Domain ของ Developer มันมีผลกับการออกแบบสถาปัตยกรรมซอฟต์แวร์ขนาดไหน
ในที่นี้ Business Domain คือ Game DotA2
และคนที่เล่น DotA2 มานาน จะเข้าใจทันทีว่า การ Implement แบบคูณ 1.15 คือ บ้ามากๆ คุณเข้าใจทันทีว่าเกมมัน Patch และปรับสมดุลกันตลอดเวลา คุณเข้าใจว่า Stats Gain คือจุดที่เปลี่ยนแปลงบ่อย คุณจะไม่ทำบ้าอะไรแบบนั้น
ในขณะที่ถ้าเราสวมหมวกของคนที่ไม่เข้าใจ Business Domain ไม่เคยเล่น DotA2 ไม่รู้จักการ Buff, Nerf, Patch
เขาก็อาจจะบอกว่า “พวกคุณทำบ้าอะไร มานั่งแก้ทุกตัว 60 กว่าตัว ผมทำ 3 บรรทัดเสร็จ” ก็ได้นะ
ดังนั้น สำหรับ Developer ผมอยากให้เข้าใจ Business Domain และเข้าใจ Requirement ของธุรกิจมากๆ เพราะมันมีผลซะยิ่งกว่า Design Pattern อีก อย่างตัวอย่างนี้ที่ผมยกมา คุณรู้ Design Pattern เท่าไหร่ ก็ Implement ให้สวยไม่ได้ ถ้าไม่เข้าใจ Business Domain ของตัวเกม
ส่วน Stakeholder ที่ไม่ชอบอธิบายตัว Domain อยากให้ทีมแค่ทำตาม Spec อย่าถามอะไรมาก
เลิกเถอะนะครับ เพื่อสุขภาพของซอฟต์แวร์ที่คุณรัก
