ฉันเขียนโค้ดอย่างมืออาชีพมาเป็นเวลาห้าปีแล้ว ในช่วงสี่ปีแรก ฉันไม่เคยสนใจว่าคำขอพูลของฉันจะมีขนาดเท่าใด อย่างไรก็ตาม ในปีที่แล้ว ฉันเปลี่ยนจากการส่งคำขอพูลขนาดใหญ่ที่มีการเปลี่ยนแปลงหลายพันบรรทัดเป็นการแยกคำขอพูลออกเป็นคำขอพูลที่เล็กลงและจัดการได้ง่ายขึ้น การเปลี่ยนแปลงนี้มีประโยชน์มากมาย และฉันจะแบ่งปันข้อดีเหล่านี้ในบล็อกนี้
ตาม GitHub คำขอการดึงคือ:
Pull Request คือข้อเสนอในการรวมชุดการเปลี่ยนแปลงจากสาขาหนึ่งไปยังอีกสาขาหนึ่ง ใน Pull Request ผู้ทำงานร่วมกันสามารถตรวจสอบและหารือเกี่ยวกับชุดการเปลี่ยนแปลงที่เสนอได้ก่อนที่จะรวมการเปลี่ยนแปลงเหล่านั้นเข้ากับฐานโค้ดหลัก
โดยพื้นฐานแล้ว Pull Request เป็นวิธีการทำงานร่วมกัน เราควรทำทุกอย่างเท่าที่ทำได้เพื่อปรับปรุงการทำงานร่วมกันนี้ วิธีหนึ่งที่มีประสิทธิผลในการปรับปรุงการทำงานร่วมกันนี้คือการรักษา PR ให้มีขนาดเล็ก
ไม่มีคำจำกัดความสากลที่สามารถแยกความแตกต่างระหว่าง PR ขนาดเล็กและขนาดใหญ่ได้ การพึ่งพาจำนวนบรรทัดที่เปลี่ยนแปลงเพียงอย่างเดียวไม่เพียงพอ เนื่องจากโค้ดและการทดสอบที่สร้างโดยอัตโนมัติอาจทำให้จำนวนบรรทัดเพิ่มขึ้น เมื่อฉันอ้างถึง PR ขนาดเล็กในบทความนี้ ฉันหมายถึงการแบ่ง PR ขนาดใหญ่ออกเป็น PR ขนาดเล็กหลายรายการที่มีความสอดคล้องกันทางตรรกะ PR ขนาดเล็กแต่ละรายการควรเป็นแบบสแตนด์อโลน สามารถรวมเข้าด้วยกันได้ และปรับใช้ได้
ฉันไม่สนับสนุนการแยกแบบเทียม เช่น การแยก PR ออกเป็นสองส่วน โดยส่วนหนึ่งมีโค้ดทั้งหมด และอีกส่วนหนึ่งมีเฉพาะการทดสอบ เนื่องจากแนวทางนี้ไม่สามารถให้ประโยชน์ตามที่ฉันจะแบ่งปันด้านล่างได้
ให้โปรแกรมเมอร์ตรวจสอบโค้ด 10 บรรทัด เขาจะพบปัญหา 10 ประการ ให้โปรแกรมเมอร์ตรวจสอบ 500 บรรทัด เขาจะบอกว่ามันดูดี
แม้ว่าจะดูตลก แต่คำพูดนี้ก็แฝงความจริง ทุกคนต่างก็ยุ่งอยู่กับงานของตัวเอง และเมื่อคุณขอให้ใครสักคนตรวจสอบ PR ก็เท่ากับว่าคุณกำลังขอเวลาจากพวกเขา การตรวจสอบ PR จำเป็นต้องให้ผู้ตรวจสอบเปลี่ยนบริบทจากงานของตนเอง และหากการตรวจสอบใช้เวลานานพอสมควร ก็อาจมีความท้าทายสำหรับพวกเขาที่จะกลับไปทำงานของตน ซึ่งอาจส่งผลต่อแรงจูงใจและความมุ่งมั่นของพวกเขาในการตรวจสอบ
PR ขนาดเล็กซึ่งใช้เวลาตรวจสอบเพียง 20-30 นาทีนั้นจัดการได้ง่ายกว่า PR ที่ใช้เวลา 2-3 ชั่วโมงมาก นอกจากนี้ PR ขนาดใหญ่ยังมักทำให้เกิดข้อผิดพลาดเนื่องจากเรามีสมาธิจดจ่อกับงานได้เพียงจำกัด และการสลับไปมาระหว่างการเปลี่ยนแปลงจำนวนมากใน PR เดียวก็อาจสร้างความสับสนได้ จากประสบการณ์ของฉัน PR ขนาดเล็กมักจะได้รับคำติชมที่ดีกว่าและนำไปสู่การสนทนาเกี่ยวกับการออกแบบที่มีความหมายมากกว่า
ตอนนี้ฉันกำลังคิดที่จะเพิ่ม PR ของฉันลงในพินัยกรรมในกรณีที่ยังอยู่ระหว่างการพิจารณาหลังจากที่ฉันจากไปแล้ว
PR ที่ยาวนานต้องใช้เวลาจากผู้ตรวจสอบเป็นจำนวนมาก ทำให้มีโอกาสได้รับความสนใจน้อยลง โดยเฉพาะอย่างยิ่งหากไม่ได้ผูกติดกับฟีเจอร์ที่ส่งผลกระทบสูง ในทางกลับกัน PR ขนาดเล็กจะได้รับการตรวจสอบอย่างรวดเร็ว เนื่องจากใช้เวลาของผู้ตรวจสอบน้อยกว่าและไม่ค่อยรบกวน
ความเร็วในการตรวจสอบนี้มีความสำคัญอย่างยิ่งต่อการตอบสนองกำหนดเวลาของโครงการ ฉันเคยเห็นโครงการล่าช้าเนื่องจากผู้ตรวจสอบระดับสูงไม่สามารถจัดสรรเวลาให้กับ PR ขนาดใหญ่ได้ (แม้ว่าสิ่งนี้อาจเกิดขึ้นได้กับ PR ขนาดเล็ก แต่ความเสี่ยงนั้นโดยเนื้อแท้จะสูงกว่าในกรณีของ PR ขนาดใหญ่)
การแก้ไข PR ขนาดใหญ่หลังจากมีการเปลี่ยนแปลงการออกแบบก็เหมือนกับการจัดวางเก้าอี้บนเรือใหม่ที่คุณเพิ่งสร้างเสร็จ… จากนั้นก็จมมันลง
เราทุกคนต่างเคยประสบกับสถานการณ์ที่บางคนตระหนักในระหว่างการตรวจสอบ PR ว่าการออกแบบที่แตกต่างกันนั้นจะสามารถบำรุงรักษาได้ดีกว่าและรองรับอนาคตได้ดีกว่า และเราจำเป็นต้องใช้เวลาเพิ่มเติมในการแก้ไข PR ตามการออกแบบใหม่ (ไม่ได้หมายความว่าพวกเขาสนับสนุนการออกแบบที่นำไปใช้งานในตอนแรกอย่างเต็มที่ :p) ซึ่งเป็นเรื่องปกติมากเพราะบางครั้งสิ่งต่างๆ จะชัดเจนขึ้นเมื่อคุณเห็นว่าเขียนไว้ในโค้ด และคุณจะเริ่มสังเกตเห็นด้านต่างๆ ที่คุณอาจมองข้ามไปในระหว่างขั้นตอนการออกแบบ
สำหรับ PR ขนาดใหญ่ ปัญหานี้ถือเป็นเรื่องสำคัญ เพราะคุณต้องแก้ไของค์ประกอบหลายอย่าง แต่สำหรับ PR ขนาดเล็ก การเปลี่ยนแปลงต่างๆ จะง่ายกว่า ที่สำคัญกว่านั้น โอกาสที่ต้องแก้ไขซ้ำมีน้อยกว่า เนื่องจากผู้ตรวจสอบมักจะระบุปัญหาได้ตั้งแต่เนิ่นๆ และแก้ไขใน PR เบื้องต้น ทำให้ PR ในภายหลังสามารถอิงตามการออกแบบใหม่ได้
PR ขนาดเล็กยังเป็นประโยชน์ต่อคุณในฐานะผู้เขียน PR อีกด้วย PR ช่วยในการทดสอบการเปลี่ยนแปลงเล็กๆ น้อยๆ ทีละเล็กทีละน้อย แทนที่จะทดสอบทั้งโครงการในครั้งเดียว การทดสอบการเปลี่ยนแปลงเล็กๆ น้อยๆ ส่งผลให้การทดสอบแต่ละส่วนประกอบของระบบครอบคลุมมากขึ้น ส่งผลให้มีจุดบกพร่องในการผลิตน้อยลง ซึ่งใช้ได้กับทั้งการทดสอบอัตโนมัติและการทดสอบด้วยตนเองที่ดำเนินการโดยคุณหรือวิศวกร QA เฉพาะทาง
ยิ่งไปกว่านั้น PR ขนาดเล็กจะลดโอกาสที่จะพลาดกรณีทดสอบ เนื่องจากคุณสามารถมุ่งเน้นไปที่ขอบเขตที่จำกัด แทนที่จะมุ่งเน้นไปที่ระบบทั้งหมดได้
การเขียนข้อสอบเหรอ? นั่นฟังดูเหมือนปัญหาของฉันในอนาคตเลยนะ
ฉันเคยเห็นนักพัฒนา (รวมถึงตัวฉันเองในอดีต) ลังเลที่จะเขียนการทดสอบอัตโนมัติเนื่องจากรู้สึกว่าต้องใช้เวลาในการลงทุนโดยไม่ได้เห็นคุณค่าของฟีเจอร์/ผลิตภัณฑ์ในทันที PR ขนาดเล็กจะลดความยุ่งยากนี้ลงด้วยการจำกัดจำนวนการทดสอบที่จำเป็นและเวลาที่ใช้ในการเขียน
ไม่ว่าการทดสอบของคุณจะละเอียดถี่ถ้วนเพียงใด ข้อบกพร่องในการผลิตก็อาจเกิดขึ้นได้! การสามารถแก้ไขข้อบกพร่องในการผลิตได้นั้นมีความสำคัญ เนื่องจากข้อบกพร่องในการผลิตส่งผลกระทบโดยตรงต่อผู้ใช้ ธุรกิจ หรือทั้งสองฝ่าย สำหรับ PR ขนาดใหญ่ พื้นที่การเปลี่ยนแปลงที่เกิดขึ้นก็มีขนาดใหญ่เช่นกัน ทำให้ใช้เวลานานและยากต่อการค้นหาสาเหตุหลักของปัญหา ในทางกลับกัน PR ขนาดเล็กจะมีโค้ดน้อยกว่า ดังนั้นจึงทำให้การแก้จุดบกพร่องเร็วขึ้นมาก
การแก้ไขข้อบกพร่องของการเปลี่ยนแปลงเล็กๆ น้อยๆ ก็เหมือนกับการค้นหาข้อผิดพลาดในการพิมพ์ ส่วนการแก้ไขข้อบกพร่องของการเปลี่ยนแปลงครั้งใหญ่ก็เหมือนกับการตรวจทานสารานุกรม
สุดท้ายแต่ไม่ท้ายสุด PR ขนาดเล็กยังมีประโยชน์ต่อผู้จัดการผลิตภัณฑ์และผู้ใช้ของคุณอีกด้วย การใช้ PR ขนาดเล็กช่วยให้คุณสามารถผลักดันส่วนต่างๆ ของระบบไปสู่การผลิตได้อย่างต่อเนื่อง ซึ่งช่วยในการรับคำติชมจากผู้ใช้ในระยะเริ่มต้น และช่วยให้สามารถแก้ไขขั้นตอนต่างๆ ได้ในระยะเริ่มต้นหากจำเป็น
การละเลยการตอบรับในช่วงแรกเปรียบเสมือนการปรุงอาหาร 5 คอร์สโดยไม่ได้ชิมอะไรเลย — คุณแค่หวังว่ามันคงไม่เกิดหายนะเท่านั้น
ข้อดีของ PR ขนาดเล็กนั้นมีมากมาย และประเด็นต่างๆ ที่ระบุไว้ข้างต้นเป็นประเด็นที่มีผลกระทบมากที่สุดที่ฉันเคยพบมา หากคุณพบข้อดีอื่นๆ ของ PR ขนาดเล็ก หรือพบความท้าทายของ PR ขนาดใหญ่ที่ฉันไม่ได้กล่าวถึง โปรดแสดงความคิดเห็นของคุณ
ฉันหวังว่าบทความนี้จะช่วยกระตุ้นให้คุณหันมาใช้ PR ขนาดเล็กมากขึ้น หากคุณเข้าร่วมอยู่แล้ว ฉันหวังว่าบทความนี้จะช่วยเสริมสร้างคุณค่าของแนวทางปฏิบัตินี้
ขอบคุณที่อ่านนะคะ จนกว่าจะพบกันใหม่ ขอให้เขียนโค้ดต่อไปและอย่าหยุดอยากรู้อยากเห็น!