Topic 10

Topic 10

โค้ด Ruby ใช้ร่วมจากโฟลเดอร์ en/ ของต้นฉบับ เพื่อให้สองภาษาผูกกับชุดทดสอบเดียวกัน

ภาพรวม

ทำไมหัวข้อนี้จึงสำคัญ

หัวข้อนี้สอนการพัฒนาแบบแตกเป็นรอบสั้น ๆ ที่ทดสอบได้ แทนที่จะมองเป็นงานชิ้นเดียวว่า "สร้างทั้งเกมให้เสร็จ" Rock-paper-scissors ถูกเลือกมาเพราะ domain มันตั้งใจให้ง่าย พอที่จะเปิดพื้นที่ให้เราคุยเรื่องกติกา การตัดสินผลหนึ่งรอบ การเก็บคะแนน และ dependency injection ได้ชัด

สิ่งที่ผมอยากให้คุณทำได้เมื่อจบหัวข้อนี้

เมื่อจบหัวข้อนี้ คุณควรจะ:

จุดที่ผมใช้ดูความเข้าใจ

ผมอยากให้คุณอธิบายได้ว่าทำไมเกมจึงถูกแยกเป็นเรื่องกติกา เรื่องรอบ และเรื่องแมตช์ แทนที่จะยุบทุกอย่างลงใน script เดียว

โน้ตสั้น

เกมเล็ก ๆ มีประโยชน์ตรงที่กติกาเข้าใจง่าย ผู้เรียนจึงเอาความสนใจไปไว้ที่การตัดสินใจด้าน การออกแบบได้เต็มที่:

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

จุดที่ Ruby ทำได้ดีในหัวข้อนี้:

จุดที่ต้องระวังในหัวข้อนี้:

คำถามชวนคิด:

ตัวอย่างแบบลงมือดู

Example 1: แยกกติกาออกมาก่อน flow ของเกม

มันล่อตาล่อใจมากที่จะเขียน logic แบบ if/else ของเกมทั้งหมดไว้ใน object หลักเลย แต่ในเชิงการสอน วิธีที่ดีกว่าคือแยกกติกาออกมาก่อน:

rules . winner ( "rock" , "scissors" ) # => :player_one worked_examples.md ruby เหตุผลที่ตัวอย่างนี้มีประโยชน์:

Example 2: ทดสอบ game loop แบบกำหนดผลได้

เกมมักมีความสุ่ม แต่ tests ไม่ควรสุ่มไปด้วย

ถ้าท่าของคอมพิวเตอร์มาจาก object ร่วมงานที่ส่งเข้ามาจากภายนอก ชุดทดสอบก็จะควบคุมลำดับได้:

source = instance_double ( "MoveSource" ) allow ( source ). to receive (: next_move ). and_return ( "scissors" , "rock" ) worked_examples.md ruby นี่คือบทเรียนด้านการออกแบบที่สำคัญที่สุดของหัวข้อนี้: แยกพฤติกรรมที่ไม่นิ่งออกไป