กิจกรรม code review นั้น เป็นสิ่งที่ขาดไม่ได้เลยในการพัฒนา software
เพื่อช่วยปรับปรุง code ที่เราพัฒนาขึ้นมา ให้มันดียิ่งขึ้น
รวมทั้งเป็นการแบ่งปันความรู้ต่างๆ ซึ่งกันและกัน
แต่ในการทำงานจริงๆ แทบจะไม่มีใครทำ code review เลย !!
มันแปลกดีนะ …
หรือมีก็มีตำแหน่ง code reviewer ขึ้นมา
ซึ่งก็กลายเป็นคอขวด หรือ ปัญหาขึ้นมาอีก
โดยไม่ได้ปรับปรุง code และ กระบวนการพัฒนา software มันดีขึ้นเลย
หลายครั้งกลับทำให้เลวร้ายลงไปอีก
เนื่องจาก code review กลายเป็นการจับผิดไปซะอย่างนั้น !!
คำถาม
แล้วเราจะทำอย่างไรดีล่ะ เลิกทำ code review ไปเลยได้ไหม ?
คำตอบ
ไม่อยากทำ code review หรอ ?
งั้นทำแบบนี้สิ
ปกติขั้นตอนการพัฒนาระบบเป็นแบบนี้หรือเปล่า ?
- เลือก feature ที่จะพัฒนา
- สร้าง branch ( Feature branch )
- เขียน code
- สร้าง Pull request
- ระบบ Continuous Integration ทำงานแบบอัตโนมัติ
- มีใครสักคนมา review code
- ทำการ merge code เข้าไปยัง master branch
ขั้นตอนการทำงานแบบนี้ มันเรียบง่าย และ แจ่มมากๆ
แต่ลองมาทำแบบใหม่กันไหม แล้วคุณจะไม่ทำทั้ง 7 ข้อเลย
แต่คุณจะทำการ commit และ push ไปยัง master branch ตรงๆ เลย
ไม่เชื่อก็ลองทำตามดูนะครับ สัก 2-3 เดือน !!
Pairing programming กันเลยแบบเต็มๆ ไงล่ะ
ทำงานเป็นคู่ด้วยกันตลอด
เปลี่ยนจากการใช้ Version control แบบ feature branch มาเป็นแบบไม่ใช้หรือ trunk base ไปเลย
จะพบว่าระบบมันจะถูก break ตลอดเวลาในช่วงแรกๆ
เพราะว่า ทุกๆ คนจะทำงานอยู่ที่ master branch เหมือนกันทั้งหมด
แต่ลองทำดูไปซักพักสิ คุณจะรู้ว่าต้องทำอะไรอย่างไร
และ ทีมจะต้องทำอะไรต่อไป
ตลอดจนจะไม่มีคนมา review code คุณแล้วนะ
เพราะว่า code อยู่ที่เดียว (Single Point of Truth)
ดังนั้น ทุกๆ คนในทีมพัฒนา จะเห็น code อยู่ตลอด
และแต่ละคู่จะทำงานด้วยกันตลอด
ดังนั้น จะเกิดการ review code อยู่ตลอดเวลา
และมั่นใจด้วยว่า code มันยังสามารถทำงานได้
ประโยชน์ไม่คาดคิด จะเกิดขึ้น …
โดยปกติถ้ามาทำงานแบบคู่ สิ่งที่ต้องถามหรือคิดขึ้นมาก็คือ
เรื่อง cost และ benefit ว่าต้องใช้ค่าใช้จ่ายเท่าไร และได้ประยชน์อะไรบ้าง ?
แน่นอนว่า ถ้ามองกันตรงๆ แล้วการทำงานแบบคู่มันไม่คุ้มเลยว่าไหมล่ะ
ค่าใช้จ่ายก็เยอะขึ้น เมื่อเทียบกับแบบเดิม !!
ประโยชน์ที่ได้รับ คือ จำนวนงานก็น้อยลงสิ !!
แต่เดี๋ยวก่อน คุณลองทำดูหรือยัง หรือ แค่คิด !!
ถ้ายังไม่ทำ ให้ลงมือทำ 2-3 เดือน แล้วค่อยกลับมาประเมินนะครับ
ซึ่งเมื่อทำไปแล้วผมกลับเจอประโยชน์ที่ไม่คาดคิดดังนี้
เกิดการแบ่งปันความรู้ซึ่งกันและกัน
จะเกิดขึ้นได้สมาชิกแต่ละคนในทีม
ต้องมีความเคารพซึ่งกันและกัน
เชื่อเถอะว่าไม่มีใครเก่งกว่าใครหรอก
มีเพียงคนที่รู้ กับ ไม่รู้เท่านั้นล่ะ
แล้วจะเกิดการแบ่งปันความรู้กัน ไม่ใช่แค่ความสามารถทางด้าน code เท่านั้นนะ
ยังรวมไปถึงพวก soft skill อื่นๆ ด้วย
รวมทั้งความสามารถในการสื่อสารกับคนอื่นๆ ให้รู้เรื่อง
ซึ่งมันเป็นปัญหาหลักๆ ของ developer กันเลยทีเดียว
มีความรับผิดชอบ และ สามัญสำนึก
แน่นอนว่าเมื่อคุณทำงานแบบคู่
ต้องได้รับแรงกดดันมากมาย จากหลายทาง
เพื่อทำให้คุณหาทางลัด เพื่อทำให้งานนั้นๆ มันจบๆ ไป !!
ซึ่งนั่นมันไม่ใช่เหตุผลที่ทำให้คุณลืม หรือ โยน ความรับผิดชอบ หรือ สามัญสำนึก
ว่าจะไม่เขียน test ไม่ refactor code ที่มันแย่ๆ ก่อนจะเพิ่ม code เข้าไปใหม่
ดังนั้นคุณห้ามละทิ้งมันเด็ดขาด ไม่ว่าจะเกิดอะไรขึ้นก็ตาม
แล้วมันจะทำให้คุณ และ ทีม รู้ว่าสิ่งที่คุณทำนั้นมันดีอย่างไร
จะเกิดอะไรขึ้นถ้าคุณไม่เขียน test ?
จะเกิดอะไรขึ้นถ้าคุณไม่ทำการ refactor code ที่แย่ๆ ก่อนเพิ่ม code ใหม่เข้าไป ?
ผลที่ตามมาคือ code ที่คุณได้ มันห่างไกลจากคำว่า เรียบง่าย และ เข้าใจง่าย และ ดูแลรักษาง่ายใช่ไหมล่ะ ?
ช่วยลด overhead ลงไป !!
เมื่อคุณลองทำวิธีการใหม่ๆ ที่แตกต่างจากเดิมแล้ว
คุณก็มักจะได้รู้ว่า ผลมันเป็นอย่างไร แน่นอนว่าผลมันต้องไม่เหมือนเดิมสิ
และเมื่อกลับไปเทียบกับแบบเดิม
คุณอาจจะพบว่ามันดีขึ้น หรือ แย่ลง …
สิ่งที่ผมได้รับจากการไม่ต้องสร้าง branch และ pull request คือ
จำนวน overhead ในการสร้าง branch และ pull request ลดลงไป
คำถามคือ ลดไปอย่างไรล่ะ ?
อย่างแรกเข้าใจว่า สิ่งที่เคยทำอยู่มันมี overhead อย่างไร ?
ทั้งเวลาการ merge และ เวลารอคนมา approve pull request
เวลาที่ทำ และ เวลาที่รอ มันคือ ค่าใช้จ่ายทั้งนั้น !!
ไม่พอ ไหนจะต้องมาสร้าง branch
ไม่พอ ไหนจะต้องมาเขียน pull request ให่มันสวยๆ เข้าใจง่าย
ไม่พอ ปัญหาคอขวดไปตกอยู่ที่คน review code อีก
ไม่พอ หลังจากที่คุณส่ง pull request ไปแล้ว มักจะเกิดการพูดคุยในภายหลังใช่ไหม
ไม่พอ มันจะ interupt คุณไหม นั่นคือปัญหาเรื่อง context switching ไหม
แต่สิ่งที่ผมทำคือ การทำงานแบบคู่
ทำการเขียน code ทำการทดสอบ
ทำการ commit/push ขึ้น master branch
ระบบ Continuous Integration ทำงาน
ผลคือ การทำงานผ่าน หรือมันเขียน เราก็ทำงานกันต่อไป …
ข้อดีของ Pair programming เยอะนะ แต่ข้อเสียมันก็ไม่น้อยนะ !!
คุณจะเหนื่อยขึ้นกว่าเดิม
เนื่องจากไม่ทุกคนหรอกนะ ที่จะคิดว่าการทำงานแบบคู่มันดี
ดังนั้น ต้องพยายามทำให้หนักขึ้น
แค่ลองเอาหูฟังออกจากหู แล้วรับฟังผู้อื่น ก็เป็นงานที่ยากล่ะ !!
แค่ช่วยกันทำงานหนึ่งด้วยกัน ก็ยากล่ะ !!
แค่อธิบายให้คนอื่นเข้าใจ ในสิ่งที่เรากำลังทำ ก็ยากล่ะ !!
แค่ทำให้มันเสร็จ ก็ยากล่ะ !!
No pain no Gain
ดังนั้นใช้ช่วยแรกๆ จะเจ็บปวดหน่อย
เพราะว่า มันคือการเปลี่ยนวิธีการทำงานไปเลย
แต่ต้องให้มองว่า สิ่งที่จะได้รับกลับมาแบบ long term มันดีเพียงใด
วันนี้คุณทำ Pair programming แล้วหรือยังครับ ?
