บทความ IT เจ๋งๆ

หากทีม Developer ของคุณ กำลังประสบปัญหาในการ Review Code บน Github อยู่ละก็ บทความนี้จะเสนอ วิธี Review Code แบบอัตโนมัติบน Github  มาให้คุณใช้เป็นแนวทาง ในบทความนี้จะอธิบายว่า เราจะทำมันได้อย่างไร มี Aspect ใดบ้างของ Process ที่เราจะสามารถ Automate ได้ และจะใช้ Tools ใดบ้าง

การ Create และการ Review Pull Request ถือเป็น 2 สิ่งที่ Developer หลายคนต้องเจอในการทำงาน ใน Project ส่วนใหญ่มักมี Guideline ที่ Developer ต้องปฏิบัติตามหากจะทำ 2 สิ่งข้างต้น จะว่าไปแล้ว มันก็เป็นเรื่องยากสำหรับ Developer ที่จะจำ Guideline ทั้งหมดขณะทำการ Pull Request และมันก็เป็นเรื่องยากยิ่งขึ้นสำหรับ Reviewer ในการทำให้แน่ใจว่าทุกบรรทัดของ Code เป็นไปตาม Guideline ที่กำหนดไว้

การเปลี่ยนจากการ Review Code แบบ Manual มาเป็นแบบอัตโนมัติ นอกจากจะช่วยให้ Developer และ Reviewer ทำงานได้ง่ายขึ้นแล้ว พวกเขาจะได้ใช้เวลาในการปรับปรุงคุณภาพของ Code มากขึ้นและทำงานที่น่าเบื่อน้อยลงอีกด้วย

Automate styling issues

ทีมงานไม่ต้องการให้ Reviewer ต้องขอให้ Contributor เพิ่ม Issue No. และ Description ของ Jira ทุกครั้งที่ทำการสร้าง Pull Request คุณสามารถแก้ไขปัญหาดังกล่าวได้ด้วยการใช้ Bot ในการตรวจสอบแทน ซึ่งสิ่งนี้ช่วยให้ Contributor สามารถทำตาม Project Guidelines ได้ อีกทั้ง Bot ยังสามารถ Verify ได้ว่ามี Description อยู่หรือไม่ โดยทำการตรวจสอบใน Body ของ Pull Request นอกจากนี้มันยังสามารถ Comment ลงใน Pull Request ได้หาก Description เกิดขาดหายไป

นอกจากนี้เรายังสามารถเพิ่ม Pull Request Template เพื่อรับข้อมูลบางอย่างที่เกี่ยวข้องกับ Pull Request นั้นกลับมา แต่วิธีนี้ก็อาจเป็นการเพิ่มข้อขัดแย้งที่ต้องใช้ในการสร้าง Pull Request เมื่อเราเพิ่ม Rules ก็จำเป็นต้องตรวจสอบให้แน่ใจว่า จะเกิดการขัดแย้งกับประสบการณ์ของ Developer ใหม่ ให้น้อยที่สุดเท่าที่จะทำได้ ในเวลาเดียวกันเราจำเป็นต้องรักษาคุณภาพของ Code ด้วย ต่อไป เรามาดูขั้นตอนที่จำเป็นในการสร้าง Bot ดังกล่าวกันดีกว่า

‘Danger’ คือตัวช่วย

Danger จะ Run ในระหว่าง CI Process ของคุณ ซึ่งช่วยให้ทีมสามารถ Review Code แบบอัตโนมัติได้ การใช้ Danger จะสามารถช่วยคุณวิเคราะห์ในการ Review Code ที่ทำอยู่แทบทุกวันได้

คุณสามารถใช้ Danger ในการสร้างบรรทัดฐานของทีมให้เป็นระบบมากขึ้น เพื่อให้มนุษย์อย่างเราๆ ได้มีเวลาคิดเกี่ยวกับปัญหาที่ยากกว่า โดย Danger จะทำการใส่ Message ไว้ใน PRs ของคุณตาม Rule ที่สร้างขึ้นด้วยภาษาสคริปต์อย่าง Ruby จากนั้นเมื่อยึดตาม Rule ที่สร้างขึ้น, Message จะถูกแก้ไขเพื่อสะท้อนสถานะปัจจุบันของการ Review Code

Danger ถูกใช้งานในหลายๆ Project เช่น ruby gems, python apps, Xcode projects, blogs, npm websites และ modules

Danger เป็น Tool ที่ทำงานบน API ของ Github ซึ่งช่วยให้คุณสามารถดึงข้อมูลที่เกี่ยวกับ Pull Request และทำการช่วย check ข้อมูลบางอย่างที่เกี่ยวกับ Pull Request ได้อีกด้วย โดยมันถูก Create และ Maintain โดย Orta และ Contributor อื่นๆ อีกมากมาย หลังจากการติดตั้ง คุณต้องสร้าง File ชื่อ Dangerfile ซึ่งได้รวบรวม Rule ทั้งหมดไว้ข้างใน และ File นี้ควรอยู่ใน Root ของ Project ของคุณ

หลังจากเพิ่ม File นี้เข้าไป ถือว่าคุณมี Rule เรียบร้อยแล้ว ต่อไปคุณต้อง Run Danger ทุกครั้งที่มีคนสร้าง Pull Request ขึ้น

เพิ่ม Danger ไปใน CI workflow ของคุณ

คุณ Mukesh ใช้ Bitrise ใน Mobile SDK Projects มันเป็น Continuous Integration และ Continuous Delivery Service สำหรับ Mobile Apps หากคุณกำลังใช้ CI Service อื่นๆ คุณสามารถตรวจสอบกับคู่มือนี้ดูว่า จะสามารถ Integrate Danger เข้ากับ Service นั้นได้อย่างไร มี Blog ที่โพสต์เกี่ยวกับการ Integrate Danger เข้ากับ Bitrise ซึ่งสามารถสรุปใจความสำคัญออกมาได้ดังนี้

• ติดตั้ง Bundler, ทำการสร้าง Gemfile และเพิ่ม Danger gem เข้าไปใน Gemfile
• สร้าง Dangerfile สำหรับ Project ของคุณ
• สร้าง Bot user บน Github และ Personal Access Token สำหรับ Bot
• จากนั้นเพิ่ม Token ที่ถูก Generate แล้ว เข้าไปบน Bitrise
• เพิ่มขั้นตอน Script เข้าไปใน Workflow ของ Project

Rule ที่เราสามารถทำให้เป็นแบบอัตโนมัติได้

อีกวิธีหนึ่งในการกำหนด Rule ที่เราสามารถทำให้เป็นแบบอัตโนมัติได้ คือ การดูที่ Pull Request API Response ของ Github ซึ่งจากการเปรียบเทียบ API Response กับ Pull Request Checklist หรือ Guideline ทำให้เราสามารถทราบถึงความเป็นไปได้ที่มีอยู่ และนี่คือลักษณะของ Response:

• มันทำการ Return ข้อมูลแทบจะทั้งหมดที่คุณเห็นจากการ Pull Request Webpage บน Github ไม่ว่าจะเป็น Title, Description, Assignee, Reviewers, Labels เป็นต้น
• ยังมีอีกหนึ่ง API ที่จะ Fetch List ของ File ที่เปลี่ยนแปลง โดยในแต่ละ File จะทำการ Return ชื่อของ File, จำนวนของการเพิ่มเข้าและการลบออกจาก File
• แต่เราไม่จำเป็นต้องใช้ API นี้ หากเราจะใช้ Danger เนื่องจากเป็นวิธีที่ง่ายกว่าในการ Interact กับข้อมูลนี้

List ของ Rules ที่เราทำการ Automate

เมื่อเราเพิ่ม Danger ลงใน Repository เราจะพิจารณา Requirement ของเราและ Project อื่นๆ ที่ใช้ Danger และด้านล่างนี้คือบางส่วนของการตรวจสอบ Project

• แจ้งเตือนหากมันเป็น PR ขนาดใหญ่: เรามักจะทำผิดพลาดในการ Push การเปลี่ยนแปลงจำนวนมากๆ ลงใน PR เดียว ซึ่งการ Review PR ถือเป็นงานที่ยาก เราทำการเพิ่มการแจ้งเตือน ซึ่งจะแสดงเมื่อจำนวนบรรทัดที่ Update ใน PR มีมากกว่า 500 บรรทัด
• ควรมี Pull Request Descriptions: บางครั้ง Developer คิดว่า Descriptions  นั้นไม่จำเป็นหรือบางทีเราก็ลืมที่จะเพิ่มมันเข้าไป แม้ว่าคุณจะกล่าวถึง ปริมาณของปัญหา แต่ Descriptions  จะช่วยกำหนด Context ให้กับการ Pull Request เสมอ การจะดูว่า Descriptions  ว่างเปล่าหรือไม่ เราสามารถตรวจสอบความยาวของ Body:

• ตรวจสอบว่าการ Test ขาดหายไป: เราทุกคนรู้ว่าการ Test นั้นมีความสำคัญ แต่เราก็มักจะข้ามขั้นตอนนี้ไป เมื่อใดก็ตามที่เราทำการแก้ไขใน Source Code เราควรเพิ่มการ Test เข้าไปด้วย(หากเป็นไปได้) ดังนั้น ตอนนี้มันเป็นการเตือนว่าหากมีการเปลี่ยนแปลงใดๆ ใน Source Code และ Test Folder ไม่ได้ถูก Modify นั่นหมายความว่า การ Test ครั้งใหม่ได้หายไป
• Update Changelog: ไม่ว่าจะเป็นการ เพิ่ม Feature ใหม่ หรือแก้ไข Bug ก็ตาม ให้ Update Changelog โดยลงรายละเอียดด้วย เรากำหนดให้มีการเพิ่ม Changelog Entry เข้าไปหากการเปลี่ยนแปลงนั้นไสำคัญ หาก Changelog ไม่ได้รับการ Update และ Pull Request ไม่ได้ถูกระบุไว้ว่ามันไม่สำคัญ CI ของเราจะไม่สามารถ Build ได้ และตอนนี้ก็ไม่จำเป็นต้อง Track ไม่ว่า Changelog จะถูก Update หรือไม่ก็ตาม
• ควรใช้การ Rebase มากกว่าใช้การ Merge Commits:เมื่อ Project มีขนาดใหญ่ขึ้น เรามักได้รับคำแนะนำเสมอว่า เราควรหลีกเลี่ยง การ ‘Merge’ Commits เพื่อให้ Project มี History ที่ Clean เราชอบที่จะใช้การ Rebase แทนการ Merge ใน Branch ที่แตกต่างกันมากกว่า เราสามารถเพิ่มการตรวจสอบข้อความในรูปแบบนี้: “Merge branch ‘master’” เพื่อหลีกเลี่ยงการ merge commits

คุณสามารถตรวจสอบ Dangerfile ของ ApplozicSwift หรือใน Project Open Source ยอดนิยมอื่นๆ เช่น React Native หรือ CocoaPods อีกทั้งพบว่า Project อย่าง React Native และ React ก็ใช้ Danger ด้วยเช่นกัน สิ่งนี้แสดงให้เห็นว่ากระบวนการของการ Review แบบอัตโนมัตินี้ ได้กลายเป็นส่วนหนึ่งของ Pull Requests Workflow ไปแล้ว

ที่มา:  https://medium.freecodecamp.org/