เหตุผลที่แท้จริงว่าทำไม PR ของคุณถึงใหญ่เกินไป
ผมเคยทำงานในบริษัทหนึ่งที่ส่ง Pull Request (PR) ขนาดมหึมาเป็นเรื่องปกติ PR หนึ่งอาจค้างอยู่เป็นสัปดาห์ การจะรีวิวได้นั้นคุณต้องจำระบบย่อย (subsystem) ทั้งหมดไว้ในหัว บั๊กก็เริ่มสะสม กำหนดส่งงานก็เลื่อน สุดท้ายเราต้องรื้อระบบส่วนใหญ่สร้างใหม่ เพราะไม่มีใครกล้าเข้าไปแก้ไขมันอย่างปลอดภัยอีกต่อไปแล้ว
วิศวกรที่นั่นไม่ใช่คนไม่เก่ง พวกเขาฉลาดและทำงานหนัก แต่ที่ PR มันใหญ่ขึ้นเรื่อยๆ ก็เพราะเหตุผลที่น่าเบื่ออย่างหนึ่ง
ไม่มีใครสอนพวกเขาเลยว่าต้องแบ่งงานออกเป็นส่วนย่อยๆ อย่างไร
บ่อยครั้งที่เรามองว่า PR ขนาดใหญ่เป็นปัญหาเรื่องวินัย เรามักจะพูดว่า "ก็แค่ทำให้ PR มันเล็กลงสิ" เราทำเหมือนกับว่าความมุ่งมั่น (willpower) คือสิ่งเดียวที่แบ่งแยกความแตกต่างระหว่างการเปลี่ยนแปลง 1,500 จุด กับ 150 จุด
แต่มันไม่ใช่เรื่องของความมุ่งมั่น การแบ่งงานใหญ่ให้เป็นชิ้นเล็กๆ ที่เป็นอิสระต่อกันคือทักษะอย่างหนึ่ง ซึ่งคนส่วนใหญ่ไม่เคยถูกสอน เมื่อ Ticket ระบุว่า "add billing" มันจะรู้สึกเหมือนเป็นงานชิ้นเดียว แต่การมองให้ออกว่า PR หนึ่งควรจบตรงไหนและเริ่ม PR ถัดไปตรงไหนต่างหากคือส่วนที่ยากที่สุด
เมื่อก่อนผมก็ส่ง PR ใหญ่ๆ เหมือนกัน ผมเคยคิดว่าคำว่า "done" หมายถึงการแก้ปัญหาทั้งหมดให้จบในคราวเดียวแล้วค่อยส่งไปรีวิว ต้องใช้เวลาหลายปีกว่าที่ผมจะเรียนรู้ว่า "ยิ่งเล็กยิ่งดี"
PR ขนาดเล็กเปลี่ยนทุกอย่างสำหรับผม:
- ผู้รีวิวตรวจพบข้อผิดพลาดได้มากขึ้น มนุษย์สามารถทำความเข้าใจการเปลี่ยนแปลงได้ประมาณ 200 จุด แต่ไม่สามารถทำความเข้าใจ 2,000 จุดได้ พวกเขาจะแค่กวาดสายตาดูผ่านๆ แล้วก็กดอนุมัติ (approve) ไปเลย
- การ Merge เกิดขึ้นเร็วขึ้น PR จะไม่ค้างอยู่ในคิวอีกต่อไป
- ผมไม่รู้สึกว่างานมันล้นมืออีกต่อไป ผมโฟกัสกับงานทีละส่วน
- ผมวางแผนได้ดีขึ้น คุณต้องเข้าใจโครงสร้างของงานก่อนถึงจะแบ่งมันออกมาได้
ผมเริ่มมองระบบเหมือนตัวต่อ Lego มันคือชิ้นส่วนเล็กๆ ที่นำมาประกอบเข้าด้วยกัน เมื่อคุณมองเห็น "ตัวต่อ" เหล่านั้น การแบ่งงานให้เล็กลงก็จะกลายเป็นเรื่องธรรมชาติ
ทีมปัจจุบันของผมส่ง PR ขนาดเล็ก ผลลัพธ์ที่ได้นั้นชัดเจน:
- เวลาเฉลี่ยในการ Merge ของเราคือ 1.5 วัน
- เราพบและแก้ไขบั๊กได้อย่างรวดเร็วเพราะการเปลี่ยนแปลงนั้นอ่านเข้าใจง่าย
- การส่งมอบงานของเรามีความสม่ำเสมอ
การแบ่งงานเป็นทักษะที่คุณต้องสอน (coach) คุณไม่สามารถแก้ปัญหา PR ขนาดใหญ่ได้ด้วยการตั้งกฎ แต่คุณแก้ได้ด้วยการสอนให้คนมองเห็น "ตัวต่อ" เหล่านั้น
AI ยิ่งทำให้ทักษะนี้สำคัญมากขึ้นไปอีก
ในอดีต การเขียนโค้ด 2,000 บรรทัดต้องใช้ความพยายามอย่างมาก แรงเสียดทาน (friction) นั้นช่วยให้ PR มีขนาดเล็กลง แต่ AI ได้กำจัดแรงเสียดทานนั้นออกไป คุณสามารถสร้างการเปลี่ยนแปลงมหาศาลได้ด้วย Prompt เพียงอันเดียว
ความพยายามไม่ได้หายไปไหน แต่มันแค่ย้ายไปอยู่ที่ผู้รีวิวแทน คนเขียนไม่ต้องเสียอะไรเลย แต่ผู้รีวิวต้องเป็นคนแบกรับภาระทั้งหมด
หากขนาดไม่ได้เป็นตัวบ่งบอกถึงปริมาณงานที่ผู้เขียนทำอีกต่อไป ขนาดก็แทบจะบอกอะไรคุณไม่ได้เลยเกี่ยวกับความเสี่ยง คุณต้องตัดสินใจว่าส่วนไหนที่ควรค่าแก่การตรวจสอบอย่างละเอียดถี่ถ้วนที่สุด
สอนให้ทีมของคุณมองเห็น "อิฐ" แต่ละก้อน เพราะนี่คืออุปนิสัยที่สร้างผลลัพธ์ได้คุ้มค่าที่สุดในงานวิศวกรรม
ทีมของคุณมีเกณฑ์ตัดสินอย่างไรว่า PR ไหนต้องรีวิวอย่างละเอียด และ PR ไหนที่สามารถผ่านไปได้อย่างรวดเร็ว?
Source: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Optional learning community: https://t.me/GyaanSetuAi