4 เหตุผล ทำไมเราควรแบ่ง Pull Request ให้เล็กลง
เชื่อว่าชาวเดฟอย่างเรา ๆ โดยเฉพาะอย่างยิ่งกับเพื่อน ๆ ที่ทำงานร่วมกับทีม หรือกำลังพัฒนาโปรเจกต์ที่ค่อนข้างใหญ่ น่าจะคุ้นเคยกับ Pull Request (PR) ไม่มากก็น้อย เพราะเป็นเครื่องมือที่ช่วยรีวิว code ให้มีประสิทธิภาพ ก่อนจะรวมเข้า branch หลักของโปรเจกต์
แล้ววว… สมมติว่า ถ้าเรากำลังพัฒนาฟีเจอร์นึงอยู่ เราก็เลยแตก Branch ใหม่ออกมา สำหรับทำงานนี้ เพื่อน ๆ คิดว่า เราควรเปิด PR เมื่อไหร่? ตอนที่ทำ Subtask สักชิ้นเสร็จ หรือตอนที่ทำครบทั้งฟีเจอร์ดี?
บทความนี้จะพาทุกคนไปหาคำตอบกันค่ะ ด้วยเหตุนี้เอง เราก็เลยจะมาเล่า เหตุผลดี ๆ ทำไมเราควรแบ่ง PR ให้เล็กลง🤏
1. รีวิวได้เร็วขึ้น ง่ายกว่าที่เคย
เมื่อเราย่อย PR เป็นส่วนเล็ก ๆ จะทำให้ code กับ file changes ต่อ 1 PR ลดลง และนี่ส่งผลต่อหัวใจของเหล่า Reviewers ทุกคนแน่นอน
นึกภาพว่า เราต้องรีวิว code เยอะ ๆ กับ รีวิว code จำนวนน้อย ๆ เราก็คงรู้สึกเหมือนกันใช่ไหมว่า แบบหลังน่าจะใช้เวลาแป๊บเดียว และทำเสร็จได้ ‘เร็วกว่า’
ในมุมเจ้าของ PR ก็เร็วขึ้นเช่นกัน เมื่อ code น้อยลง ก็จะได้ comment เร็วขึ้น และ (คาดหวังได้ว่า) comment ต่อ 1 PR อาจจะน้อยลง (แถมขอบเขตของงานใน PR นั้น ก็แคบลง) ตอนแก้ไขหรือตรวจสอบ ก็จะทำได้ง่ายและเร็วขึ้นค่ะ
2. ลดความซับซ้อน เพิ่มประสิทธิภาพ
PR ที่ยิ่งใหญ่ มาพร้อมกับความปวดหัวที่ใหญ่ยิ่ง!
เพราะการอ่าน code และทำความเข้าใจมันเป็นเรื่องยาก พอไม่เข้าใจ ก็อาจจะรีวิว PR นั้นแบบผิวเผิน เผลอมองข้ามข้อผิดพลาดบางอย่างไป โฟกัสได้ยาก ความละเอียดก็ลดลงไปด้วย
เมื่อ PR เล็กลง ตัว code น้อยลง เพื่อนที่มารีวิว ก็จะอ่านละเอียดมากขึ้น และ comment ได้ตรงจุด
นอกจากนี้ เมื่อติดปัญหาก็จะหาวิธีแก้ได้มีประสิทธิภาพมากขึ้น เพราะเราเข้าใจตรงกันนั่นเอง
และในมุมของ Senior เอง อาจจะเคยรู้สึกว่า
‘อันที่จริงน่าจะมีวิธีที่ดีกว่านี้ แต่จะให้น้องรื้อใหม่หมดก็คงไม่ทันละ’
ดังนั้น ถ้าแบ่ง PR ให้เล็กลง แล้วส่งให้ทีมช่วยกันรีวิวแต่เนิ่น ๆ จะเปิดโอกาสให้เพื่อน ๆ มาแนะนำเพิ่มเติมได้ทันท่วงที
3. ทำงานไหลลื่น Workflow ไม่มีสะดุด
ถ้าเราต้องทำงานร่วมกับทีม การย่อย PR จะเพิ่มความคล่องตัว เพราะเราไม่ต้องรอให้ PR ก้อนใหญ่ (ที่อาจมีส่วนเกี่ยวข้องกับเรา) รวมเข้า Branch หลักนาน แต่ละคนยังคงเดฟได้ไม่มีสะดุด ทั้งยังลดโอกาสเกิด conflict ระหว่าง code ของเราและ code ของเพื่อนอีกด้วย
ในกรณีที่จำเป็นต้อง cherry-pick (เช่น ตอนเลือกงานไป deploy) ถ้าเราแบ่ง PR เป็นส่วนเล็ก ๆ จะทำให้ตอนเลือก commit ทำได้ง่ายและแม่นยำมากขึ้น เพราะเรารู้ว่า PR ไหน เปลี่ยนหรือแก้เรื่องอะไรไปบ้าง ทำให้ cherry-pick ได้สะดวก
นอกจากนี้ ถ้า PR รวมเข้ากับ branch หลักแล้วเกิดปัญหาขึ้น ก็จะหาสาเหตุได้ง่ายกว่า เพราะ PR ของเรามีขนาดเล็ก การเปลี่ยนแปลงไม่เยอะนั่นเอง
4. Mindset และ Culture ที่ดี มีได้ด้วยมือเรา
เมื่อเรารู้สึกว่าการรีวิว PR เป็นเรื่องที่ง่ายขึ้น เราก็จะรู้สึกอยากส่อง PR เพื่อนในทีมมากขึ้น และทำให้การอ่าน code ไม่ใช่เรื่องที่ต้องเครียด ทั้งหมดนี้ จะทำให้เราและทีมรู้สึกสนุกมากขึ้น
และแน่นอน ทุกครั้งที่ PR ของเรา approved แล้วกำลังจะ merge เข้า branch หลัก ก็เหมือนกับว่า เราทำภารกิจสำเร็จ เป็นหนึ่งในแรงบันดาลใจในการเขียน code
ผลพลอยได้ก็คือ เราจะรู้สึกอยากทำอีก เพราะ PR เล็ก ๆ ทำให้เราเห็นว่า เป้าหมายไม่ได้ไกลเกินเอื้อมอีกต่อไป
การแบ่ง Pull request ที่ดี ก็มาจากการแบ่ง Subtask ที่ดี วิธีการแบ่งจะขึ้นอยู่กับสิ่งที่เราทำอยู่ ซึ่งต้องอาศัยความเข้าใจเนื้องานร่วมด้วย
โดยรวม เราอาจจะแบ่งตามลำดับสิ่งที่ต้องทำก่อน-หลัง เช่น เพิ่ม Table ใหม่ ตามด้วยเพิ่ม API เส้นใหม่ หรือ Refactor code เก่าให้เสร็จก่อน แล้วงานใหม่หรือฟีเจอร์ใหม่ค่อยเปิดเป็นอีก PR
สรุปแล้ว การแบ่ง PR ของเราให้เล็กลง เป็นอีกวิธีที่จะทำให้เราพัฒนาซอฟต์แวร์ได้เร็วขึ้น เพิ่มประสิทธิภาพ และส่งเสริมการทำงานร่วมกันในทีม ทำให้งานดำเนินไปได้อย่างราบรื่นยิ่งขึ้นนั่นเองงง 💪
เอาล่ะ ! PR รอบหน้า
เพื่อน ๆ พร้อมยังคะ ? มาย่อย PR อันใหม่ให้เล็กลงกันเถอะ !
