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

บ่ายวันหนึ่งคุณแก้บัคเสร็จแล้ว คุณกำลังจะส่ง 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 แบบนี้

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

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

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

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

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

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