ก่อนจะเข้าสู่เนื้อหา พี่รูฟบอกว่าหัวข้อ LeSS Architecture เนี่ย ในวันนี้พี่รูฟจะใช้เป็น Let’s Start talking about Software Architecture ก็คือไม่ได้เกี่ยวกับ LeSS (Large Scale Scrum) แต่เกี่ยวกับ Software Architecture นั่นเอง เป็น Session สุดตึงยามเช้าเพราะกำลังงัวเงียเลย 5555555 เช้าสุด ๆ จะเป็นยังไงมาลุยไปด้วยกันครับ
- เราชอบเอา Software ไป Map กับงานก่อสร้างและสถาปัตยกรรม แต่เราเข้าใจกันจริง ๆ หรือเปล่าว่าคำว่า Architecture มันหมายความว่ายังไง
- ถ้าพูดถึง Architecture จะมีตึกนึงที่สวยมากใน London ชื่อ Senate House ที่เป็นตึกของ University of London
- พี่รูฟเล่าไปถึงตอนที่สร้างตึกว่าตึกนี้ได้รับโจทย์มาให้เป็นตึกที่ต้องไม่ถูกลอกเลียนแบบด้วยคนอื่น และออกแบบด้วย Architecture Style แบบ Art Deco ซึ่งได้รับแรงบันดาลใจจากยุคกลาง
- เมื่อเลือกแล้วว่าจะใช้ Architecture Style แบบนึง ภายในตึก รวมถึงของตกแต่งก็ต้องสอดคล้องไปกับ Style นั้น ๆ เราเรียกสิ่งนี้ว่า Architecture Pattern
- ระหว่างการก่อสร้างตึกนี้เกิดสงครามโลกครั้งที่ 2 ทำให้ถูกตัดงบ ทำให้สร้างได้ไม่ตามแบบที่วางไว้
- แม้จะไม่เหมือนที่วางไว้ แต่ส่วนที่สำคัญมันก็เสร็จและก็เป็นไปตาม Architecture ที่วางไว้
- จากจุดนี้แปลว่าการทำ Architecture ก็มี Priority เหมือนกันว่าควรสร้างตรงไหนก่อน ไม่ได้สามารถสร้างมั่ว ๆ ได้
- จริง ๆ แล้ว Architecture นั้นประกอบไปด้วย Style และ Pattern โดย Style นั้นมีไว้เพื่อกำหนด Pattern โดยที่ตัว Architecture นั้นไม่ได้มีความหมายอะไรไปมากกว่าสิ่งที่เราอยากได้มันคืออะไร บอกแค่เพียงแค่จุดสำคัญของมันคืออะไร
- Software Architecture ตามนิยามคือภาพ High-Level ของระบบ Software เพื่อใช้ตัดสินใจในการทำงานในองค์กร (เป็นนิยามที่โคตร Abstract)
- ซึ่งความสำคัญของ Software Architecture คือทำให้ Developer รู้ว่าอะไรคือสิ่งของที่สำคัญ รวมถึงสิ่งนี้สามารถใช้สื่อสารระหว่าง Stakeholders
- จริง ๆ ในเนื้อหาจะมีอีก 2 ข้อคือเรื่องของ Scalability กับ Maintainability แต่พี่รูฟตั้งแง่กับมัน โดยมองว่า 2 สิ่งนี้ถ้ามีเงินเดี๋ยวมันจะตามมาเอง
- ในฝั่งของ Software Architecture จะไม่เหมือนกับงานก่อสร้างอย่างนึงคือ Architecture ของงานก่อสร้างจะคงทนอยู่อย่างงั้นตลอด แต่ของงาน Software จะต้องเปลี่ยนไปตาม Requirement ยุคสมัย และงบ 55555
- Architecture Styles และ Patterns ของฝั่ง Software มีให้เลือกเยอะมาก เลือกตามความสามารถของทีมกับความเร่งรีบของธุรกิจ เมื่อมีข้อจำกัดมา เราจะถูกบีบให้เลือกตามข้อจำกัดเอง
- ถ้าเราต้องทำของที่ Requirement ไม่ชัดและไม่เคยมีใครทำมาก่อน เราจะเหมือนเท Resource ไปเรื่อย ๆ และตัว Software ก็ขยายไปเรื่อย ๆ
- หลาย ๆ คนมักบอกว่าตัวเองกำลังทำสิ่งที่ไม่เคยมีใครทำมาก่อน แล้วก็จะข้ามขั้นไม่ยอมทำ Architecture Design และระบบก็จะบวมไปเรื่อย ๆ
- แต่จริง ๆ แล้วมักจะตกหลุมพรางเพราะตัวเองกำลังทำสิ่งที่คนอื่นทำมาอยู่แล้ว ภาพใหญ่สุดมันคือการขาย Products & Services นั่นแหละ
- มีสิ่งที่เรียกว่า eTOM (Enhanced Telecom Operations Map) ซึ่งเป็นเหมือน Blueprint ว่าถ้าจะทำ Products & Services ใด ๆ ต้องมี Process อะไรบ้าง ถ้าอยากทำ Products หรือ Services อะไร เข้าไปดูในนั้นแหละ ไม่ต้องคิดเอง
- เวลาลูกค้ามาจ้างแล้วถามว่า “ที่ดีคืออะไร” อย่าไปแบบสมองโล่ง ๆ แล้วบอกว่าจะเรียนรู้ด้วยกัน อันนั้นลูกค้าอาจจะขอเงินคืน 555555
- เวลาเรารับ Requirement มา ให้เปิด eTOM ดูว่า Requirement ที่เรารับมาประกอบด้วย Service อะไรบ้าง ถ้าเป็นของที่มีคนทำอยู่แล้วและไม่ใช่ Core หลักให้ Buy ถ้าเป็น Core หลักให้ Build
- Architecture ที่ดีที่สุดไม่มีอยู่จริง ให้เราเลือกและบอกว่าคิดยังไงถึงได้ Architecture นี้มาดีกว่า
- จากประสบการณ์พี่รูฟ ในระบบ Software ขนาดใหญ่ ไม่เคยมีของที่ใช้ Pattern เดียวกัน เราต้องค่อย ๆ ดูแต่ละจุดเพื่อดูว่า Pattern ไหนตอบโจทย์แต่ละจุดที่สุด
- เราไม่จำเป็นต้องเลือก Pattern ที่ยิ่งใหญ่ตั้งแต่ Day 1 ของระบบ ต้องรีบ Launch ละให้ Business ไปขาย
- เรามีโอกาสที่จะฝันอยากจะใช้ Pattern แบบหล่อเท่ แต่ให้หันมาถาม Business ด้วยว่าไหวไหม ไม่ไหวก็ลืมความฝันนั้นไปก่อน
- อย่าเป็นคนที่ Design Architecture แต่ไม่เคยเห็น Code ที่ตัวเอง Design ถ้า Software Architect ไม่เคยเขียน Code = กลับไปขายก๋วยเตี๋ยวไป๊!
- Key หลักคือ ก่อนจะเอาอะไรให้ลูกค้า ทำการบ้านเยอะ ๆ อ่านหนังสือเยอะ ๆ
- หลังจากวาง Architecture เสร็จแล้ว ค่อยคิดว่าจะ Tech Stack อะไรในการ Implement สิ่งนั้น ๆ
Session สมองบวมจบลงแต่เพียงเท่านี้ ขนาดมานั่ง Rewrite เอง ยังสมองบวมอีกรอบ พี่รูฟสุดยอดจริง ๆ ครับ FC พี่รูฟ เย้ ๆ