Babel Coder

เลือกคน review โค๊ดแบบอัตโนมัติและมีประสิทธิภาพด้วย mention-bot

beginner

บ่ายวันหนึ่งคุณแก้บัคเสร็จแล้ว คุณกำลังจะส่ง pull request ขึ้น Github ตอนนีคุณส่งพร้อมเปิด pull request เรียบร้อย แต่… เอ๊ะ เราจะให้ใครมาดูก้อนโค๊ดชิ้นใหม่ที่เราเขียนไว้อุดบัคดี?

อัญเชิญแก๊งค์ Potential Reviewers มาดู Pull Request คุณ

ในสถานการณ์จริงของทีมใหญ่คงไม่มีนโยบายให้คนทั้งทีมรุมยำอ่าน pull request แน่ เพราะมันเสียเวลาเกินเหตุ เราต้องการคนเพียงไม่กี่คนที่จะมาดูว่าเราทำอะไร ในกรณีของการแก้ข้อผิดพลาดโปรแกรม คงไม่มีใครให้น้องฝึกงานหรือแม่บ้านออฟฟิตข้างๆมานั่งดู pull request ใช่ไหมครับ แต่เราต้องการคนที่เรียกว่า potential reviewers หรือนักรีวิวโคตรชำนาญการเป็นพิเศษ ใครหละจะได้ติดยศประดับบ่าเช่นนี้?

  • กรณีการแก้บัคเราอาจมองหา potential reviewers จากมนุษย์เงินเดือนคนสุดท้ายที่แก้ไฟล์หรือโค๊ดบรรทัดนั้น ถ้าเราแก้บัคที่ไฟล์นี้ เราคงอยากให้เขามาดูว่าเราแก้ถูกไหม จริงไหม?
  • แต่ถ้าไฟล์นั้นโดนรุมกันหลายคนก่อนเราจะจับไฟล์นี้ เราคงอยากอัญเชิญท่านทั้งหลายเหล่านั้นมาดูงานของเรา

แล้วยังไงดี เปิด pull request ครั้งนึงก็ต้องไปนั่งดู history ว่าใครแก้ไขอะไรล่าสุด แล้วค่อยอ้างถึง (mention) ใน Github เพื่ออัญเชิญท่านเหล่านั้นมาดู ยากไปไหม? จะดีกว่าไหมถ้ามีเครื่องมือซักอย่างช่วยเราเลือกผู้มีศักยภาพสูงมาดู pull request ของเรา?

และนั่นคือที่มาของบทความนี้ที่เป็นภาคต่อของทำไมต้อง Code Review? แนะนำ Hound และ Hubot ที่จะนำคุณไปรู้จักกับmention-bot จาก Facebook ที่ทำทุกอย่างตามที่ผมกล่าวข้างต้น

ภายหลังจากที่เราติดตั้งบอทตัวนี้แล้ว (ดูวิธีการติดตั้งใน Github ครับ) สิ่งเหล่านี้จะเกิดขึ้น

  • เมื่อคุณส่ง pull request แล้ว Github จะจุดธูปเรียกให้บอทมาทำงาน
  • บอทจะเข้าไปดู pull request ของคุณ แล้วเรียก git diff เพื่อดูว่าคุณทำอะไรไปบ้าง
  • บอทจะ git blame ดูว่าใครแก้ไขไฟล์/บรรทัด ที่คุณเปลี่ยนแปลงใน pull request นี้
  • บอทจะอัญเชิญท่านเหล่านั้นมาดู pull request ของคุณในฐานะ potential reviewers แบบนี้

mention-bot

คนที่เราเลือกเอง ย่อมดีกว่าที่เขาเลือกให้

แม้การหา potential reviewers จากผู้แก้ไขครั้งล่าสุดจะฟังดูดี แต่ถ้าบรรทัดนั้นกลายเป็นน้องฝึกงานที่แก้ไขเพียงแค่เปลี่ยนชื่อตัวแปรหละ? เราก็จะได้ potential reviewers ที่ชำนาญการด้านการเปลี่ยนชื่อตัวแปรแทนไงครับ ซึ่งมันไม่ใช่!

เหตุนี้เราจึงควรนิยาม potential reviewers ของเราเอง โดยบอกว่าเมื่อไหร่ก็ตามที่มีคนแก้ไขโมดูลนี้ ให้คนๆนี้ที่ชำนาญในเรื่องนี้เป็นคนรับผิดชอบดู pull request เราสามารถตั้งค่าให้ mention-bot ได้ดังนี้

{
  "maxReviewers": 5, // ให้บอท mention คนมา review สูงสุดกี่คน
  "message": "@pullRequester, thanks! @reviewers, please review this.",
  "alwaysNotifyForPaths": [
    {
      "name": "user1",
      "files": ["src/auth/**/*.js"]
    },
    {
      "name": "user2",
      "files": ["src/routes/**/*.js"]
    }
  ],
  "findPotentialReviewers": false // ถ้าตั้งเป็น true มันจะหาคนมา review จาก history ด้วย git blame
  // อื่นๆ
}

จากตัวอย่างที่ยกมานี้เป็นการบอกว่า ถ้าใครแก้ไขไฟล์ภายใต้ src/auth บอทจะเรียก user1 ผู้ชำนาญด้าน authentication ขึ้นมา review pull request ของคุณ แต่ถ้าเป็นเรื่องเกี่ยวกับ routes แล้วจะถือว่า user2 เป็น potential reviewer ทั้งนี้ user1 และ user2 ที่เราใส่ล้วนเป็นชื่อ account ของ Github นะครับ

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


แสดงความคิดเห็นของคุณ


No any discussions