Architecture Kata คืออะไร? เทคนิคที่ Tech Team เก่งๆ กำลังใช้ฝึก Architect

TL;DR:

โอกาสในการฝึก design software architecture ในงานจริงมีน้อยมาก ดังนั้น Architecture Kata คือ "การฝึกซ้อม" เพื่อให้ทีมได้มีโอกาสฝึก design software architecture พูดคุย ถกเถียงเรื่อง Trade-offs, และนำเสนอไอเดียกัน โดยหัวใจสำคัญ ❤️ คือการฝึก "กระบวนการคิด" ไม่ใช่การหา "คำตอบที่ถูกที่สุด"

คำว่า “kata” คืออะไร?

Kata (型) เห็นก็น่าจะรู้อยู่แล้วว่ามาจากญี่ปุ่น หมายถึง “รูปแบบ/ท่าทาง” ในพื้นฐานของศาสตร์นั้น เช่น การชงชา (ตักชา เทน้ำร้อน) คาราเต้ ดาบ เป็นต้น

เป้าหมายของการฝึกฝน kata หรือรูปแบบพื้นฐานต่าง ๆ เพื่อให้ผู้ที่เรียนรู้ เกิดการจดจำขั้นตอนและสามารถนำไปปรับใช้ เมื่อจดจำขั้นตอนและสามารถนำไปใช้ได้ซ้ำ ๆ ก็จะเกิดเป็นทักษะที่ติดตัว เป็น muscle memory ที่มีความแม่นยำ ทำให้สามารถใช้ทักษะนั้นได้อย่างเป็นธรรมชาติ

ก็เหมือนนักกีฬา ที่ทำสิ่งที่คล้ายกัน ยกตัวอย่าง เช่น นักบอล เวลาที่ใช้ “แข่งจริง” น้อยกว่าเวลาที่ใช้ “ฝึก” ต่างกันหลายเท่า การฝึกที่ว่าจะเน้นพื้นฐาน เช่น การเลี้ยงลูก การส่งบอล ยิงลูกโทษ เป็นต้น

แล้ว Software Architect ล่ะ อะไรที่ความแตกต่างระหว่างมือใหม่ กับคนที่ประสบการณ์

แน่นอนว่า อาจจะมีคนเดาออกอยู่แล้ว คำว่า “ประสบการณ์” ยังไงล่ะ คือความแตกต่าง

วันนี้เราเลยจะพาไปทำความรู้จักวิธีที่จะเปลี่ยนจาก software architect ที่ไม่มีประสบการณ์ ให้กลายเป็นคนที่มีประสบการณ์ นั่นคือการฝึกฝน ด้วย “Architecture Kata”

ที่มา Architecture Kata

คนที่ทำให้เรามีคำว่า architecture kata คือ Ted Neward

Ted Neward | ภาพจากเว็บ gotopia

เขาก็ตั้งคำถามแบบเดียวกันกับที่เราสงสัยนั่นแหละว่าจะทำยังไงให้ architect มีสิ่งที่เรียกว่า “ประสบการณ์”

ขอยก quote เขามาเลยละกัน

So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career? — Ted Neward

“เราจะมี Architect เก่งๆ ขึ้นมาได้ยังไง ในเมื่อตลอดชีวิตการทำงานของคนหนึ่ง อาจจะมีโอกาสได้ลงมือออกแบบระบบจริงๆ ไม่ถึง 5-6 ครั้งด้วยซ้ำ” — Ted Neward

Architecture Kata คืออะไร?

architecture kata คือแนวทางหนึ่งในการ “ฝึก” ในการเป็น software architect ได้

โดยเป็นกิจกรรมจะเกิดประโยชน์อย่างมากสำหรับกลุ่มเล็ก ประมาณ 3-5 คน ที่จะมาพูดคุย ออกแบบระบบร่วมกัน

และจะมีคนที่เป็น moderator ที่คอยควบคุมเวลา แจกโจทย์ และอำนวยความสะดวกตลอดกิจกรรม (อารมณ์เหมือนเล่นบอร์ดเกม)

พอแต่ละกลุ่มได้โจทย์ สามารถถามคำถามกับ ลูกค้า ก็คือ moderator เพื่อให้ได้ข้อมูลที่จำเป็นสำหรับการออกแบบระบบ หลังจากได้หมดเวลาจะต้องมานำเสนอแนวทางการออกแบบให้ทีม และ moderator ฟัง และแลกเปลี่ยน feedback กัน

เริ่ม Architecture Kata ยังไง? ด้วย 8 ขั้นตอน

หากเพื่อน ๆ อยากลองเอาไปใช้ ฝึกกับทีมที่บริษัท หรือเพื่อน ขอแนะนำ 8 ขั้นตอนในการทำ architecture kata ไปดูกัน

1. หาทีม อย่างน้อยซัก 3 คน

form team(s) | ภาพจาก unsplash

• หาเพื่อนร่วมทีม: แค่มีประสบการณ์ทำซอฟต์แวร์มาบ้าง (สัก 1 ปีก็กำลังดี) ลองชวนทั้ง Frontend, Backend, หรือ QA มาแจมกัน จะได้มีไอเดียหลากหลาย
• ขนาดทีมที่พอดี: ขนาดกำลังดีคือ 3-5 คน ถ้าคนเยอะไปอาจจะคุยกันนาน จนเถียงกันไม่จบ! มีทริคคือพยายามให้ทีมเป็นเลขคี่ เวลามีเรื่องต้องโหวตจะได้ไม่เสมอกัน หาคนตัดสินได้ง่าย
• ยิ่งมีหลายทีมยิ่งสนุก: โดยใช้โจทย์เดียวกันทั้งหมด เชื่อเถอว่าสุดท้ายแต่ละทีมไม่มีทางออกแบบเหมือนกันแน่นอน และเราจะได้เห็นว่าปัญหาเดียวกันสามารถแก้ได้ด้วยหลายวิธี

Note:

• ทั้งกิจกรรม ไม่จำเป็นต้องใช้ laptop ให้การหาข้อมูล
• ถ้าเป็น on-site ขอแค่มี flip chart + post-it + ปากกา ก็พอ
• ถ้าเป็น remote ขอ whiteboard tool ที่สามารถจด + เขียน diagram ได้

2. เลือกโจทย์

moderator อาจจะเอาโจทย์จากในเน็ต หรือเอาจากระบบที่ทำงานกันจริง ๆ ก็ได้

ถ้าคิดไม่ออกจะเอาโจทย์ จากไหน ลองดู

• Architectural Katas
• Fundamentals of Software Architecture Katas

3. อธิบายโจทย์ + ซักถาม (10 min)

moderator จะทำการแจกโจทย์ หลังจากอธิบายโจทย์เสร็จจะให้ทีมสามารถถามคำถามได้

ถ้าทีมถามคำถามที่ไม่ได้มีชี้แจงในโจทย์ อาจจะให้ทีมตั้งสมมติฐานแล้วตัดสินใจกันเองเลย ว่าควรเป็นยังไง

format ของโจทย์จะประกอบด้วย 4 ส่วน

• Short Description: อธิบายสั้น ๆ ว่าเรากำลังทำธุรกิจอะไรอยู่ ให้เห็นว่าเราอยู่ context ไหน
• Users: ใครคือคนใช้งานระบบบ้าง เช่น ผู้ใช้ทั่วไป ผู้ดูแลระบบ แล้วจำนวนของผู้ใช้มีประมาณกี่คน
• Requirements: ความต้องของระบบควรทำอะไรได้บ้าง
• Additional Context: ข้อมูลเพิ่มเติม
  • ข้อจำกัด เช่น มีงบประมาณไม่เกิน xx บาท
  • แพลตฟอร์มที่ใช้ เช่น web application, mobile application
  • แผนในอนาคตถ้าสำเร็จ เช่น ขยายไปภูมิภาคอื่น, ควบรวมกิจการกับบริษัท local

มาดูตัวอย่างกัน

architecture kata โจทย์ Hot Diggety Dog!

ตัวอย่างนี้คือโจทย์ชื่อว่า Hot Diggety Dog!

• Short Description: ร้าน hot dog ที่อยากจะมีระบบ point of sale
• Users:
  • Operators - คนดูแลหน้าร้าน 50 คน
  • Customers - คนที่จะมาซื้อ hot dog หลักพันคน
  • Inventory Staff - พนักงานเติมสต็อควัตถุดิบให้สาขา
  • Accounting - ฝ่ายบัญชี ที่ต้องการข้อมูลยอดขายไปใช้กับโปรแกรมบัญชีตัวอื่น
• Requirements เช่น
  • สามารถจัดการโปรโมชัน เช่น โค้ดส่วนลด, ซื้อ 2 แถม 1
  • เก็บข้อมูลเวลาและสถานที่ ที่ขาย
  • ส่งข้อมูล สินค้าคงคลังให้กับ มือถือของ เจ้าหน้าที่จัดสต็อค (ที่เป็นคนเตรียมวัตถุดิบให้แต่ละสาขา)
• Additional Context เช่น
  • อยากได้ระบบออกมาใช้งานให้เร็ว แต่… ต่อรองได้ เพราะไม่อยากต้องมารื้อระบบใหม่ในช่วง 3 ปีหลังจากนี้
  • เงินไม่ใช่ปัญหา เลือกสิ่งที่ดีที่สุดได้เลย

4. Architecture Characteristics (15 min)

architecture characteristics หรือ A.K.A. quality attributes, non-functional requirements, system capabilities เช่น deployability, testability, maintainability เป็นต้น

หน้าที่ของ architect คือการแปลงสาสน์ที่ได้จากลูกค้าว่าระบบต้องการอะไร

เช่น

• “ไม่อยากต้องมารื้อระบบใหม่ในช่วง 3 ปีหลังจากนี้” → maintainability
• “ต้องการข้อมูลยอดขายไปใช้กับโปรแกรมบัญชีตัวอื่น” → Interoperability

ตรงส่วนนี้แอดมักจะใช้ architecture characteristics worksheet ของ Mark Richards

Architecture Characteristics Worksheet

download ที่นี่: Architecture Characteristics Worksheet

5. Logical Components (60 min)

เราต้องการระบุให้ได้ว่าระบบต้องมี component และ interaction ระหว่าง component เป็นยังไง

เช่น เราบอกว่า component จะมี sale service ส่งข้อมูลไปหา inventory service เป็นต้น

Component & Communication between components

Note:

• การออกแบบตรงนี้เราจะใช้เทคนิคอะไรก็ได้ที่รู้จัก เช่น Event Storming, DDD, Actor, Actor/Action Approach, Workflow Approach
• ยังไม่จำเป็นต้องคิดไปถึงว่า จะใช้ database, caching, queue ให้มอง high level ก่อน เดี๋ยว physical component จะได้ออกแบบในขั้นตอนถัด ๆ ไป

6. Architectural Style (20 min)

เลือก architectural style ที่เหมาะสมกับระบบ Mark Richards มีเทคนิค คือการเอา Architecture Characteristics มาเป็นแนวทางในการเลือก style เบื้องต้น

• cost $ หมายถึง ค่าใช้จ่ายที่ใช้ เช่น ค่า infrastructure, จำนวน developer ที่ต้องดูแล ยิ่งดาวเยอะหมายถึง infrastructure จำนวน server ที่ใช้เยอะขึ้น ส่งผลให้มีค่าใช้จ่ายเพิ่มขึ้นตาม
• star ⭐️
  • 1 ดาว หมายถึง style ตัวนั้น รองรับ characteristics น้อยที่สุด เมื่อเทียบกับ style อื่น
  • 5 ดาว หมายถึง style ตัวนั้น รองรับ characteristics ได้ดีที่สุด เมื่อเทียบกับ style อื่น

Architecture Styles Worksheet

download ที่นี่: Architecture Styles Worksheet

Note:

• จำนวนดาว มาจากการมุมมองวิเคราะห์ของ คนเขียน Fundamentals of Software Architecture (Neal Ford & Mark Richards)
• จำนวนดาวขึ้นอยู่กับการเปรียบเทียบ relative กับ style ตัวอื่น

7. Diagramming Architecture (60 min)

เขียน diagram ที่บอกว่าระบบประกอบไปด้วยอะไรบ้าง ทำงานอย่างไร

• C4 model
• physical components & technology stack
  • Mobile Device (Tablet)
  • API Gateway
  • Managed Database
  • Managed Cache

8. Presenting Solution (5 min)

นำเสนอให้ทีมอื่น และ moderator ฟัง ไม่จำเป็นต้องเล่าทั้งหมด เล่าเฉพาะส่วนที่สำคัญ

อารมณ์เหมือนเรามา pitch เพื่อเอา budget ไปพัฒนาระบบ

Presentation | ภาพจาก unsplash

หลังจากนั้นให้ทีมอื่น และ Moderator ให้ Feedback สิ่งที่ดี และสิ่งที่สามารถปรับปรุงได้

---

จบไปแล้วกับ 8 ขั้นตอน หลายคนอาจจะถาม “โหพรี่ เราต้องทำเบอร์นี้เลยหรอ”

• คำตอบคือ "ไม่จำเป็น!"

คำถามที่เจอบ่อย

สรุป

จากจุดเริ่มต้นที่ว่า "เราจะมี architect เก่งๆ ขึ้นมาได้อย่างไร ถ้าพวกเขาแทบไม่มีโอกาสได้ออกแบบระบบจริงๆ เลย” … มาถึงตรงนี้ เราคงได้คำตอบแล้วว่า Architecture Kata คือหนึ่งในทางออกนี้

Architecture Kata เราไม่ได้ต้องการคำถามที่ถูกต้อง แต่คือการเรียนรู้กระบวนการที่ได้มาซึ่งคำตอบสำคัญกว่ามาก เพราะถ้าเรามีวิธีการอยู่กับตัว จะปัญหาอะไรก็ไม่น่ายากเกินไปใช่ไหมละครับ 😀

จะเห็นข้อดีจากการทำ Architecture Kata นอกจากเรื่อง การทำ System Design แล้วยังมีเรื่องของ Communication, Questioning, Trade-off Analysis ด้วย

ขอบคุณทุกคนที่อ่านจนจบ 😀 ลองไปชวนเพื่อนในทีมสัก 2-3 คนมาทำฝึกทำ Architecture Kata เพราะ การเรียนรู้ เกิดจากการ “ลงมือทำ”

อ้างอิง

• Architectural Katas

Running an Architecture Kata Session