เลิร์นฮาวพีเพิลติงค์ with Pull request?
Tags: productivity, career
Published: 2023-02-21 19:04:54


## น้ำแบบชุ่มๆ 


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


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

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

---

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

---

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

---

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

---

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

---

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

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

---

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

---

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

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

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

---

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

---

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

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

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

และในแง่ของการเรียนรู้ละ นี่แหล่ะคือโอกาสในการเรียนรู้ที่ดีเลยแหล่ะ **เลิร์นฮาวพีเพิลติงค์** ศึกษาเลยว่า<u>ด้วยชุดของปัญหาดังกล่าว</u> อะไรคือ **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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zg88m3ovbo7nsu0w5abq.png)

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

---

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

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