ฉันเขียนโค้ดอย่างมืออาชีพมาเป็นเวลาห้าปีแล้ว ในช่วงสี่ปีแรก ฉันไม่เคยสนใจว่าคำขอพูลของฉันจะมีขนาดเท่าใด อย่างไรก็ตาม ในปีที่แล้ว ฉันเปลี่ยนจากการส่งคำขอพูลขนาดใหญ่ที่มีการเปลี่ยนแปลงหลายพันบรรทัดเป็นการแยกคำขอพูลออกเป็นคำขอพูลที่เล็กลงและจัดการได้ง่ายขึ้น การเปลี่ยนแปลงนี้มีประโยชน์มากมาย และฉันจะแบ่งปันข้อดีเหล่านี้ในบล็อกนี้ ตาม คำขอการดึงคือ: 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 ขนาดเล็กมากขึ้น หากคุณเข้าร่วมอยู่แล้ว ฉันหวังว่าบทความนี้จะช่วยเสริมสร้างคุณค่าของแนวทางปฏิบัตินี้ ขอบคุณที่อ่านนะคะ จนกว่าจะพบกันใหม่ ขอให้เขียนโค้ดต่อไปและอย่าหยุดอยากรู้อยากเห็น!
