อะหรือ.. อะหรือ.. อะหรือว่า Pull request ยังไม่มีคนกด Approved … ว่าซั่น!
ฝาก PR ยังไงให้ Reviewer แฮปปี้ เราเองก็แฮ๊ปปป ปี้! … ไปดูกัน!… ไปเต๊อะ ไปแอ่ว จังหวัดเจียงฮาย… !
ผู้เขียนได้อ่านบทความ On Empathy & Pull Requests จาก Blog ของทีมงาน Slack Engineering เป็นบทความตั้งแต่ปี 2016 แต่พออ่านแล้วรู้สึกว่ามันเป็นวิธีการทำงานที่น่าสนใจทีเดียว เลยสรุปตามที่ตัวเองเข้าใจมาให้รับชมรับฟังกันจ้า ^^
หากพูดถึงการเอาใจเขามาใส่ใจเรา (Empathy) อาจารย์ Brené Brown แห่ง University of Houston ได้ให้คำนิยามเอาไว้ง่าย ๆ 4 องค์ประกอบตามนี้เลย:
- เป็นคนที่มีความสามารถในการการมองโลกแบบเดียวกับที่คนอื่นมองได้
- เป็นคนไม่ตัดสินใคร
- เป็นคนที่สามารถเข้าใจความรู้สึกของคนอื่น
- เป็นคนที่สามารถบอกสิ่งที่ตนเองเข้าใจในความรู้สึกของคนอื่นกลับไปยังคนคนนั้นได้
โดยหลักการง่าย ๆ เพียง 4 ข้อนี้เองที่ไปเตะปาก! เอ้ย! เตะตาทีมงาน Slack Engineering เข้าอย่างจัง! แล้วก็ได้มีความพยามยามนำหลักการดังกล่าวมาใช้ในการทำงานจริง ๆ กับทีมงาน Developer ซะด้วย! โอ้ววว เขาทำยังไง เราไปดูกัน!
1. Pull request ที่ดีต้องมีท้องเรื่อง
แหมะ.. ยังกับแต่งบทละครเนาะ ต้องมีท้องเรื่อง ฮ่าๆ
เรามาดูเหตุการณ์สมมุติ เวลาที่มี Developer คนใดคนหนึ่งเขียนโค้ดเสร็จแล้วเปิด Pull request กันว่ามันจะเป็นอย่างไร….
Dev ประยุทธ์ คนเปิด PR
- สบ๊าย.. งานเสร็จแล้วโว้ยย ได้เวลาไปทำฟีเจอร์อื่นซักที งมตั้งนาน ปั๊ดโถ่ว!
- ฉันเขียน ฉันรู้ Code ของฉันมันแก้ปัญหาต่าง ๆ ได้ เพราะฉันเป็นคนดรีย์!
- ได้เวลางีบ….. คร่อก
Dev ประวิทย์ คนที่ต้องมาทำ Code review
- อิหยังวะ! ฟีเจอร์นี้มันอยู่ตรงไหนของโปรเจคเนี้ย!
- ฟีเจอร์ที่เอ็งเขียนมันทำงานยังไงฟะ! WTF
- กูมันบิดาแห่งความ “ไม่รู้” เฟ้ย
- กด Approved ….( เฉ้ยยยยย )
เรื่องราวต่าง ๆ เป็นเพียงเหตุการณ์สมมุติ กรุณาใช้ ค.ว.ย. (คิด วิเคราะห์ แยกแยะ) ด้วยจ้า
สุดท้ายการทำ Pull request / Code review ของทีมนี้ก็จะกลายเป็นการทำงานที่ไร้ประสิทธิภาพ แถมยังขาดคุณภาพเอามาก ๆ เพราะอาจจะสุ่มเสี่ยงที่จะเกิดปัญหาต่าง ๆ ภายในโปรเจคได้อีกต่างหาก พูดได้ว่ามีแต่เสียกับเสียจริง ๆ แย่ ๆ…
การมีท้องเรื่องใน Pull request จึงมีความสำคัญมาก ที่จะสามารถบอกผู้ที่เป็น Reviewer ที่จะมาทำ Code review ต่อจากเราได้ง่ายมากขึ้น โดยมีวิธีการทำง่ายนิดเดียว ดังนี้เลย:
- เขียนหัวเรื่อง (PR Title) ไว้ให้สื่อกับงานที่กำลังทำ พยายามนึกถึงว่าถ้ามีคนมาอ่านแล้วเขาจะเข้าใจมันมั้ย ? เพราะมันจะดีมากเลยถ้าคนที่มาทำ Code review แล้วแค่อ่าน PR Title ปุ๊บ สามารถเข้าใจได้ทันทีว่างานนี้มันคืออะไร เกี่ยวกับอะไร
- พยายามเขียนคำอธิบาย (PR Description) เพื่อบอกเรื่องราวของ PR นี้ซักหน่อย อาจจะเริ่มที่ปัญหาคืออะไร ? เคยลองทำวิธีไหนแล้วมันไม่เวิร์กบ้างมั้ย ? ทำไมถึงทำวิธีนี้หล่ะ ? เพื่อเล่าเรื่องว่าทำไมถึงต้องเขียนโค้ดออกมาแบบนี้
- ถ้ามี Link ref จะดีมาก ๆ ไม่ว่าจะเป็น Link ไปที่ Project management ของทีมอย่างเช่นที่ True Digital Group ของเราจะใช้ JIRA อย่างนี้เป็นต้น เพื่อให้คนที่มาทำ Code review เขาจะได้เข้าใจมันมากยิ่งขึ้น หรือ Link อื่น ๆ ที่คุณไปลอกมา เอ้ย! ไปได้วิธีแก้ปัญหามาจาก Developer Community ต่าง ๆ อย่างเช่น Stackoverflow อย่างนี้เป็นต้น
- ถ้ามีบางอย่างที่ไม่มั่นใจว่าทำถูกต้องหรือปล่าว ? เขียนใส่ไปใน PR Description ไปเลยก็ยังได้ เพื่อให้คนที่เป็น Reviewer เขาจะได้มุ่งประเด็นไปที่ตรงนั้นให้คุณด้วย
- อาจจะเพิ่มคำอธิบายไปด้วยเลยว่า หากมันเคยเป็นปัญหา / บั้คที่เคยถูกแก้มาแล้ว มันเคยถูกแก้ไขมาแล้วกี่ครั้ง ? มีวิธีอื่น ๆ อีกมั้ยที่คุณคิดว่ามันน่าจะแก้ปัญหาได้ แล้วเพราะอะไรทำไมคุณถึงเลือกวิธีแก้ปัญหานี้ใน PR ครั้งนี้ ?
ไม่จำเป็นต้องเขียนคำอธิบายละเอียดทั้งหมดจากที่กล่าวมาข้างต้นก็ได้ เพียงแต่หลักการสำคัญก็คือ พยายามใส่รายละเอียดทั้งหมดที่คิดว่าคนที่เป็น Reviewer จะสามารถทำงานได้เร็ว มีประสิทธิภาพ และมีคุณภาพมากที่สุด ให้คิดว่าคนที่เป็น Reviewer กำลังช่วยทำให้งานของเราดียิ่งขึ้น เขาจะต้องรู้อะไรบ้าง ? พยายามทำให้ Reviewer อินไปกับเรื่องราวใน PR ของคุณให้ได้มากที่สุด นั่นคือเป้าหมายแรก!
2. Pull request ที่ดีต้องมีเรื่องเดียว
ใน 1 PR ควรจะมีเพียงการเพิ่ม/ แก้ไข บั้คหรือฟีเจอร์เพียงเรื่อง ๆ เดียว แต่หากมันหลีกเลี่ยงไม่ได้จริง ๆ ที่จะต้องมีหลาย ๆ อย่างรวมกัน ก็ควรจะเป็นเรื่องที่เกี่ยวเนื่องกัน เวลาที่ Reviewer เขามาทำ Code review เขาไม่ควรจะเจอ Surprise อื่น ๆ ที่นอกเหนือจากนี้อีกแล้ว ให้เขาได้โฟกัสเพียงเรื่องเดียว เขาจะได้กด Approved ให้ไว ๆ
พยายามนึกถึงว่าหากตัวเองเป็นฝ่ายที่จะต้องทำ Code review ให้กับ PR คนอื่นบ้างแล้วตัวเราเองจะอยากให้ PR นั้นมีขนาดเล็กแค่ไหน เพราะเจ้าของ PR ทุกคนคงไม่อยากทำให้ Reviewer ต้องละเหี่ยใจเวลาที่จะต้องรีวิว PR ของเราหรอกจริงมั้ย ?
3. Pull request ที่ดีมันต้องสร้างความมั่นใจได้
ต้องกลับไปถึงสาเหตุที่ทีม Developer จะต้องมีการทำ Pull request / Code review กันเลยล่ะ ว่าทำไมเราถึงต้องทำ ? หลัก ๆ ก็คือเป็นการป้องกันปัญหาต่าง ๆ ที่จะเกิดขึ้นภายในโปรเจค สำหรับคนที่เป็น Reviewer ก็จะต้องคิดอยู่เสมอว่าหาก PR ที่เราเข้าไปทำ Code review แล้วมันเกิดปัญหาขึ้นมา คุณเองถึงแม้ว่าจะไม่ใช่คนเขียนโค้ดชุดที่เกิดปัญหานั้น ๆ แต่คุณเป็นกด Approved ด้วยตัวเอง จึงจะต้องคิดอยู่เสมอว่าเรามีส่วนในความรับผิดชอบนั้น ๆ ด้วยนาจา….
สรุป…
การทำ Pull request / Code review ที่ดี เริ่มต้นง่าย ๆ ด้วยความเข้าอกเข้าใจกันของทั้งคนที่เป็นเจ้าของ PR และคนที่เป็น Reviewer นั่นเอง
จากเหตุการณ์สมมุติ (ที่สุ่มเสี่ยงต่อการโดนปรับทัศนคติ) ข้างต้น เรามาลองเปลี่ยนมุมมองใหม่ โดยยึดหลักความเข้าอกเข้าใจกันดูซักหน่อย
Dev ประยุทธ์ ผู้เปิด PR
- สบ๊าย.. งานเสร็จแล้วโว้ยย ได้เวลาไปทำฟีเจอร์อื่นซักที งมตั้งนาน ปั๊ดโถ่ว!
- เขียน PR Title เกริ่นนำซักหน่อย เผื่อพี่ Dev ประวิทย์อ่านแล้วจะเข้าใจทันที
- อธิบาย PR Description เพิ่มอีกซักหน่อยดีกว่า พี่ Dev ประวิทย์จะได้เข้าใจปัญหาของ PR นี้ แล้วจะได้รู้ด้วยว่า ทำไมเราถึงแก้ไขด้วยวิธีนั้นไป
- แปะ JIRA Link ดีกว่า เผื่อพี่ Dev ประวิทย์จะอยากรู้รายละเอียดของงานเพิ่มขึ้น อาจจะมี comment เจ๋ง ๆ ก็ได้
- เอ…. มีบางฟังก์ชั่นเราก็ไม่ค่อยมั่นใจแฮะ… แปะไปใน PR Description เพิ่มอีกซักหน่อยดีกว่า เผื่อพี่ Dev ประวิทย์จะช่วยเราได้ เผื่อพี่แกมีไอเดียที่ดีกว่านี้
- เท่านี้น่าจะโอเคละมั้ง
- ได้เวลางีบ….. คร่อก!
Dev ประวิทย์ คนที่ต้องมาทำ Code review
- อิหยังวะ! ฟีเจอร์นี้มันอยู่ตรงไหนของโปรเจคเนี้ย!
- อ๋อ… อยู่ตรงนี้นี่เอง น้อง Dev ประยุทธ์อธิบายไว้ดีเชียวนะเนี้ย
- เอ…ปัญหาของ PR นี้คืออะไรน้าาา อ่าฮ้า!! เจอละ! น้อง Dev ประยุทธ์อธิบายไว้แล้ว แหม.ละเอียดเชียว
- เอ… ทำอย่างนี้ QA จะโอเคมั้ยน้าา ลองไปดูใน JIRA Link ที่น้องประยุทธ์แปะไว้ดูซักหน่อยดีกว่า จะได้ช่วยกันดูด้วย เผื่อน้องประยุทธ์เค้าลืม
- มีฟังก์ชั่นบางอย่างที่น้องประยุทธ์ไม่ค่อยมั่นใจ งั้นเรา comment ไว้หน่อยดีกว่า ว่าน้องประยุทธ์ทำดีแล้ว!
- พี่จะไม่ใช่บิดาแห่งความ “ไม่รู้” อีกต่อไปเฟ้ย
- กด Approved
และแล้ว เหตุการณ์สมมุติของเรา ก็จบบริบูรณ์ด้วยความเข้าอกเข้าใจกันเป็นอย่างดีของทั้งคู่ งานของทีมก็ไหลลื่น รวดเร็ว ไม่มีปัญหา เพราะไม่มีใครกล้ามี …..
ชะแว๊บบบ…ไปดีกว่า…. เดี่ยวจะยาว ฮ่าๆ
ทัศนคติเจ้าของบทความดีอยู่แล้วครับ ไม่ต้องปรับเน้อออออ
