DEV Community

Cover image for เลิร์นฮาวพีเพิลติงค์ with Pull request?
Nara, bug editor
Nara, bug editor

Posted on

เลิร์นฮาวพีเพิลติงค์ with Pull request?

น้ำแบบชุ่มๆ

การทำงานบนโปรเจคที่เราไม่ได้มี "ส่วนร่วม" ตั้งแต่ต้น
จะกระทำใดๆก็แต่กับสิ่งนั้น ไม่ว่าจะเป็นการ maintain, add/remove features หรือการ investigating production issues อะไรมันก็ยากไปหมดหากเรา ไม่เข้าใจ ตัว Codebase

การจะได้มาซึ่งสิ่งนั้น, ความเข้าใจ

มันก็มีหลายวิธีทั้งศาสตร์และศิลป์ปนกันไป นึกแบบหยาบๆก็นั่งไล่อ่านโค๊ดทุกบรรทัด ฟังดูเป็นไปได้นะถ้าโปรเจคมันขนาดเล็กถึงเล็กมากมาก คำถามก็คือถ้าขนาดโค๊ดมันใหญ่ขึ้นหรือมีความเป็น Legacy หน่อยๆ ทำไงดีหล่ะ?

ธรรมชาติช่างยากที่จะฝืน คิดเสมอว่าสมองของคนธรรมดาแบบผมนั้นการสร้างความเข้าใจมันก็เกิดโดยการค่อยๆ สะสมมันนี่แหล่ะ จากการที่ผมกระทำอยู่ทุกวันๆ แต่บทความนี้กำลังจะโฟกัสไปที่วิธีการนึง ที่คิดว่าได้ประโยชน์ในแง่ของการเรียนรู้ เราคุ้นเคยกันอยู่แล้ว ก็คือการใส่ใจ Code review หรือการทำความเข้าใจ Pull Requests แม้ว่าผู้รีวิวจะไม่เข้าใจ Codebase ดีพอก็ตาม


หืม..? เราจะรีวิวโค๊ดได้หรอ หากเราไม่เข้าใจ Codebase ดีพอ


ว่ากันแบบสปอยด์ๆ ก็ ยิ่งไม่เข้าใจ ยิ่งเป็นสัญญาณที่ดีในการทำความเข้าใจกับมันมากขึ้น
ถ้าให้เล่าเรื่องแย่ๆ ให้ฟังก็ตอนสมัยผมเริ่มเข้าโปรเจคใหม่ๆ ช่วงแรกเริ่มเลยนะ ผมมักจะ ละเลย กับโค๊ดที่ผมไม่เข้าใจ และให้ความสำคัญกับส่วนที่ตัวเองรู้เรื่องเท่านั้น เพราะคิดแค่ว่าจะได้ให้ Feedback ที่มีคุณภาพจริงๆ กลับไปยังผู้สร้าง PR เช่นคำแนะนำในการแก้โค๊ด


ว่าแต่... Feedback ที่ดีนั้นมีแค่คำแนะนำหรอ? หืออออ


ใช่ครับ จากนั้นผมก็ปล่อยผ่านส่วนมึนงงที่เหลือ และ Approve ไปอย่างหน้าตาเฉย (LGTM, Look good to me) ชิวๆ ครับ งานก็เดินไวดี รู้สึก Productive ระยะสั้น PR ได้ Merge ไว ของ Delivered ตรงเวลา


กลายเป็นว่า สิ่งที่เติบโตมีเพียง Changes ของทีมที่เพิ่มเข้าไปยังโปรเจค แต่ทว่าความเข้าใจของผมที่มีต่อสิ่งมึนงงบางส่วนเหล่านั้นยังคงเหมือนเดิม


หลายเดือนให้หลังก็เริ่มส่งกลิ่น โปรเจคที่เราอยู่คล้ายกับบ้านเช่าชั่วคราว ที่เรายังต้องอยู่แก้ปัญหาที่จะตามมาขณะอาศัย มีเหตุการ์ณนึงที่ต้องพยายามหาบั๊คใน Scenario นึง ขุดไปขุดมา เจอว่ามาจากโค๊ดที่น่าจะเคย Approve ไป แต่เรายังไม่เข้าใจมันสักที แม้จะโชคดีหน่อย เปิด Git blame ละเจอว่านี่คือ Change ของทีมที่เคยเอาขึ้นไปนี่นา แต่ก็ต้องการเวลาให้คนทำนึกออกว่าตัวเองแก้อะไรไป กลายเป็นว่าช้าไปอีก เห้อ


คำถามก็คือ ตอนที่ Approve ส่วนที่มึนงงเหล่านั้นขึ้นไปยัง Master branch ผม Ignore อะไรไปบ้าง?


หลายสิ่งหลายอย่าง อันดับแรกเลยก็คือความ Readability ของโค๊ด การที่มันเข้าใจยากนี่เพราะมันไม่ Clean หรอ ขนาดคนปัจจุบันยัง งง แล้วคนใหม่ในอนาคตที่เขาจะมา Join project นี้ทีหลังหล่ะจะทำยังไง?

อย่างที่สองคือผม Ignore ความสำคัญของตัวเองที่มีต่อทีม คำถามคือถ้าเกิด issue อะไรขึ้นกับ Change แล้วคนที่เข้าใจโค๊ดนั้นมีแค่คนเขียนคนเดียวเท่านั้น คนที่จะดับไฟก็มีแค่เขา อีกทั้งเราจะ Add features อะไรใหม่ที่มันไปแตะChange ตรงนั้นก็ยังต้องถามเขาอีกหรือเปล่านะ?

นั่นแหล่ะครับ การ Approve เร็วๆ แบบที่เราไม่ได้เรียนรู้อะไรใหม่ ก็เหมือนการผลักภาระไปให้คนอื่นในอนาคต พร้อมกับลดทอนคุณค่าของตัวเองไปพร้อมๆกัน


และหากเราจะเริ่มต้นใส่ใจกับ Code review เพื่อแก้ปัญหาที่ว่าไปนั้น เราเริ่มยังไงได้บ้าง?


ผมคิดว่าเริ่มจากคำถามแรกของบทความก่อนเลย "...Feedback ที่ดีนั้นมีแค่คำแนะนำหรอ? หืออออ ..."

น่าสนใจ ผมคิดว่าถ้าเราโฟกัสว่า Feedback เท่ากับ Suggestion แล้วละก็ เราจะกล้าให้ Suggestion ในสิ่งที่เราไม่เข้าใจหรือเปล่าครับ?

นั่นแน่ ผมเลยคิดว่า การตั้งคำถามเพื่อการเรียนรู้ ควรจะเป็นอีกรูปแบบ Feedback ที่ดี
ลองจินตนาการดู มี Dev 2 คนตั้งคำถามกับ PR ด้วยคำถามคล้ายๆ กัน เราคิดว่าผู้สร้าง PR จะตระหนักมากขึ้น ถึงความยากง่ายในการทำความเข้าใจ Code หรือไม่? ทำไมผู้รีวิวถึงไม่สามารถทำความเข้าใจได้ด้วยตัวเอง Change ควรปรับอะไรไหมหน่า... สิ่งนี้ก็จะช่วยให้เกิดไอเดียในการทำให้โค๊ดอ่านง่ายขึ้นเอง

และในแง่ของการเรียนรู้ละ นี่แหล่ะคือโอกาสในการเรียนรู้ที่ดีเลยแหล่ะ เลิร์นฮาวพีเพิลติงค์ ศึกษาเลยว่าด้วยชุดของปัญหาดังกล่าว อะไรคือ Solution ที่ผู้สร้าง PR กำลังนำเสนอแล้วทำไมเขาถึงทำแบบนี้ ยิ่งผู้สร้างPR เป็นคนเก่งเลเวลสูงกว่าเรายิ่งได้ประโยชน์เข้าไปอีก สิ่งเหล่านี้ก็ได้จากการตั้งคำถามกลับไปเท่านั้น

แต่ก่อนจะตั้งคำถามมากมายกลับไป เราลองมาเรียนรู้กันเองก่อนดีไหม ว่ากันตามจริง
ในบางครั้ง ผู้สร้าง PR ก็ไม่ได้สะดวกมาตอบคำถามเราทันทีหรอก อีกอย่างผมคิดว่าเราควรศึกษาทำความเข้าใจด้วยตัวเองเพื่อคัดกรองคำถามที่เป็นคำถามจริงๆ ก่อน


เพื่อเรียนรู้และตั้งคำถาม ผมทำอย่างไรใน Code Review (Github)

หากเป็น Change ที่ผมเข้าใจถึงการใช้งานของ Framework นั้นเลย

ก็อาจจะไม่มีอะไรพิเศษ เปิด PR รีวิว และกดปุ่ม "." เพื่อใช้งานตัว Github online editor นะ ดู Change ง่ายกว่าบน UI หน้าเวปมาก จะเห็น Change ของไฟล์เต็มๆไม่ต้องมานั่งกด expand

หากผมไม่เข้าใจใน Framework หรือหลักการทำงานของมันเท่าไหร่

สิ่งที่ผมจะทำก็คือ

  1. Checkout ไปที่ local branch ของ PR นั้น
  2. วาง Break points ตามที่ต่างๆ แถวๆ Change ที่ปรากฏใน PR
  3. Run debugging mode แล้วทดสอบ Scenario เลย ถ้าเป็น Bug fix ก็ reproduce
  4. ใช้งานฟังก์ชั่น Bookmark ของ IDE (ซึ่ง Vscode กับ Rider มี) ในการ Note ไว้เลยว่า Break point ไหนคือตัวแรก ผมก็ Note ว่า A, break point ถัดมาที่ไหลไปถึงก็ Note ว่า B (ค่อนข้างเป็นศาสตร์และศิลป์ส่วนตัวมาก ทำตามตัวเองสะดวกเลย) เช่นนี้เราก็จะเห็น Flow ของ ของ Change แบบ Overview เลยว่ามันไหลยังไง

Example of step 4
Image description

คราวนี้เราก็จะศึกษาโค๊ดที่เรางงง่ายขึ้นว่า Story ของ Change นี้เป็นอย่างไร Impact กับส่วนไหนบ้าง เราจะได้เห็น Logic การแก้ปัญหาของคนสร้าง PR ง่ายขึ้น


สรุป

หากการทำ Code Review มันใช้เวลาประมาณนึง แต่ก็คุ้มค่าหากเป็นการรีวิวที่มี outcome เช่น มี Dev คนอื่นเข้าใจ Change มากขึ้น หากต้อง Support ก็ไม่ต้องพึ่งพาคนๆเดียวอีกต่อไป

แรกๆ มันอาจจะเป็นความรู้สึกผิด ของการตั้งคำถามมากมาย และ Block process ของการ Approve PR ของ Dev ที่เลเวลสูงกว่า แต่ผมก็เชื่อว่าการยอม Unblock process โดยปราศจากการทำความเข้าใจอย่างถ่องแท้อาจจะไม่เหมาะกับโปรเจคที่ต้องมี Life Cycle ยาวๆ ที่จะมีคนใหม่ๆ เข้ามา Join เราอาจจะกำลังทำร้ายพวกเขาไม่รู้ตัว จาก Codebase ที่ยากต่อการทำความเข้าใจแม้กระทั่งคนที่ทำงานอยู่ ณ ตอน Reivew PR นั้น

Top comments (4)

Collapse
 
thecuriousbig profile image
Tanatorn Nateesanprasert

Good writing

Keep up the good work!

Collapse
 
narawittub profile image
Nara, bug editor

Appreciated!

Collapse
 
hithot1212 profile image
Pitchawat Wiangnai

Love your content.

Collapse
 
narawittub profile image
Nara, bug editor

Thanks for reading!