เก็บการเปลี่ยนแปลงของคุณไว้เล็กน้อย
ในฐานะวิศวกรรุ่นเยาว์ ฉันประสบความสำเร็จในการเปลี่ยนแปลงครั้งใหญ่ ฉันเห็นปัญหาแล้วจึงแก้ไขปัญหาตรงหน้า
ซึ่งปกติหมายความว่าฉันจะส่งบทวิจารณ์โค้ดจำนวนมหาศาลออกไป ฉันจะสัมผัสทุกอย่างตั้งแต่ UI ไปจนถึงฐานข้อมูล — ในการเปลี่ยนแปลงเพียงครั้งเดียว
ฉันภูมิใจในความสามารถของฉันที่จะเก็บทั้งระบบไว้ในหัวของฉันแบบนั้น ฉันภูมิใจที่ได้ทำงาน “เร็ว” ฉันภูมิใจในความกล้า ความกล้าหาญ และความสามารถในการรับมือกับปัญหาใหญ่ๆ
วันหนึ่ง วิศวกรอาวุโสคนหนึ่งดึงฉันออกไปและให้ข้อเสนอแนะในการตรวจสอบโค้ดที่ดีที่สุดที่ฉันเคยได้รับในอาชีพของฉัน เขาบอกให้ฉันแบ่งการรีวิวโค้ดขนาดมหึมาของฉันเป็นการเปลี่ยนแปลงเล็กๆ น้อยๆ ทีละน้อย
ปฏิกิริยาโต้ตอบทันทีของฉันคือการรำคาญ ฉันไม่เข้าใจว่าทำไมเขาถึงอยากให้ฉันยกเลิกการเปลี่ยนแปลงของฉัน ฉันภูมิใจมากกับความสามารถในการคิดการใหญ่! ทำไมเขาถึงบอกฉันว่างานฉันแย่! การวางแผนขั้นตอนที่เพิ่มขึ้นมีแต่จะทำให้ฉันช้าลงเท่านั้น!
ฉันยังไม่เข้าใจถึงประโยชน์มากมายของการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่เพิ่มขึ้น ฉันดีใจที่ได้ฟังวิศวกรอาวุโสคนนี้ ฉันดีใจที่ได้เรียนรู้ที่จะทำการเปลี่ยนแปลงเล็กๆ น้อยๆ ทีละน้อย
ตอนนี้มันเป็นพลังพิเศษของฉันแล้ว
ประโยชน์ที่ได้รับจากการเปลี่ยนแปลงแบบค่อยเป็นค่อยไป
มีประโยชน์มากมายในการเปลี่ยนแปลงแบบค่อยเป็นค่อยไป
- ข้อขัดแย้งในการผสานน้อยลง ยิ่งคุณเปลี่ยนแปลงไฟล์มากเท่าใด โอกาสที่บุคคลอื่นจะเปลี่ยนชุดย่อยของไฟล์เหล่านั้นพร้อมกันก็จะยิ่งมากขึ้นเท่านั้น หลีกเลี่ยงข้อขัดแย้งในการผสานโดยทำการเปลี่ยนแปลงเล็กๆ น้อยๆ และเช็คอินอย่างรวดเร็ว
- การตรวจสอบโค้ดเร็วขึ้น ง่ายกว่าสำหรับมนุษย์ในการตรวจสอบไฟล์ห้าไฟล์มากกว่า 50+ การตรวจสอบการเปลี่ยนแปลงที่สามารถอธิบายได้อย่างรวดเร็วนั้นง่ายกว่า ตรงข้ามกับการเปลี่ยนแปลงที่ต้องใช้เวลาพูดคุยแบบตัวต่อตัวเป็นเวลา 10 นาทีก่อนที่ใครก็ตามจะเริ่มดูโค้ดด้วยซ้ำ วิศวกรอาจเกียจคร้านได้ — หากพวกเขาเห็นการตรวจสอบโค้ดจำนวนมาก พวกเขาจะหวังว่าจะมีคนอื่นมาทำงานแทน อาจใช้เวลานานขึ้นในการหาคนที่จะตรวจสอบการเปลี่ยนแปลงโค้ดขนาดใหญ่ของคุณ
- การแก้ไขหลักสูตรก่อนหน้านี้ ผู้ตรวจสอบโค้ดของคุณอาจไม่เห็นด้วยกับทิศทางที่คุณดำเนินการ พวกเขาอาจขอให้คุณทำซ้ำทุกอย่าง นี่ไม่ใช่เรื่องใหญ่หากคุณใช้เวลาเพียงสองสามชั่วโมงในการเปลี่ยนแปลง มันจะเจ็บปวดมากขึ้นเมื่อคุณเสียเวลาสองวันขึ้นไปไปกับสถานการณ์ที่สมบูรณ์แบบตั้งแต่ต้นจนจบ
- การทดสอบที่เร็วขึ้น หากคุณได้สัมผัสทุกอย่างตั้งแต่ UI ไปจนถึงฐานข้อมูล คุณอาจต้องทดสอบผลิตภัณฑ์ทั้งหมดอีกครั้ง หากคุณทำการเปลี่ยนแปลงเล็กๆ น้อยๆ คุณอาจต้องทดสอบเฉพาะส่วนที่คุณกำลังแก้ไขเท่านั้น ประโยชน์นี้จะเด่นชัดเป็นพิเศษหากคุณต้องการจัดการกับคำติชมการตรวจสอบโค้ดจำนวนมาก หรือหากคุณต้องการรวมโค้ดจำนวนมากก่อนที่จะเช็คอิน การทดสอบทุกอย่างอีกครั้งอาจใช้เวลานาน — โดยเฉพาะอย่างยิ่งหากการทดสอบบางอย่างเป็นแบบแมนนวล
- ข้อบกพร่องน้อยลง การเปลี่ยนแปลงเล็กๆ น้อยๆ หมายความว่าคุณไม่จำเป็นต้องเก็บโลกทั้งใบไว้ในหัวพร้อมๆ กัน คุณสามารถมุ่งความสนใจไปที่มุมเล็กๆ ที่คุณกำลังปรับปรุง และทำให้แน่ใจว่าคุณทำได้ดี (ผมเคยเห็นวิศวกรคนหนึ่งที่จมอยู่กับการเปลี่ยนแปลงครั้งใหญ่ของเขาจนเขาติดนิสัยแค่หวังสิ่งที่ดีที่สุด เช็คอิน และแก้ไขข้อบกพร่องในภายหลัง อย่าเป็นคนนั้น แม้ว่าจะไม่มีลูกค้าคนไหนสังเกตเห็นก็ตาม คุณจะรบกวนเพื่อนๆ วิศวกรของคุณ พวกเขาจะเลิกเชื่อถือโค้ดของคุณแล้ว)
- การแก้ปัญหาที่ง่ายขึ้น หากคุณทำบางอย่างเสียหาย การค้นหาสาเหตุที่แท้จริงจะง่ายกว่าหากการเปลี่ยนแปลงเพียงเล็กน้อย
- การใช้งานแบบค่อยเป็นค่อยไป หากคุณสงสัยว่าคุณจะสามารถใช้งานบางอย่างโดยไม่มีการหยุดทำงานได้อย่างไร การเปลี่ยนแปลงที่เพิ่มขึ้นเล็กน้อยน่าจะเป็นคำตอบของคุณ (แต่อาจไม่ใช่เรื่องราวทั้งหมด)
- การคืนค่าการเปลี่ยนแปลงของคุณง่ายกว่า มีข้อบกพร่องเกิดขึ้น ยิ่งการเปลี่ยนแปลงของคุณมีขนาดเล็กเท่าใด การย้อนกลับก็จะยิ่งง่ายขึ้นเท่านั้น หากคุณตรวจสอบการเปลี่ยนแปลงครั้งใหญ่ และมีคนหลายคนเปลี่ยนแปลงไฟล์เดียวกันบางไฟล์ในภายหลัง คุณอาจตกอยู่ในสถานการณ์ที่เจ็บปวดซึ่งคุณต้องเลือกระหว่างการคืนค่าการเปลี่ยนแปลง จำนวนมาก หรือการตรวจสอบอย่างรวดเร็ว แก้ไข (ซึ่งอาจใช้งานไม่ได้จริง) หากสภาพแวดล้อมการผลิตของคุณลุกเป็นไฟ ทุกคนจะเครียดน้อยลงมากหากคุณสามารถคืนการเปลี่ยนแปลงที่ไม่ดีแบบเดิมได้
- การย้อนกลับการปรับใช้ที่ง่ายขึ้น หากการปรับใช้เพียงครั้งเดียวอัปเดตบริการเว็บ และ แนะนำคุณลักษณะ UI ทันทีที่ขึ้นอยู่กับการอัปเดตบริการ คุณจะไม่สามารถคืนค่าการเปลี่ยนแปลงบริการได้หากไม่มี ลบคุณลักษณะ UI ออกก่อน ขึ้นอยู่กับวิธีการปรับใช้ของคุณ การคืนค่าการเปลี่ยนแปลงทั้งสองโดยมีเวลาหยุดทำงานเป็นศูนย์อาจไม่ใช่เรื่องเล็กน้อย จะดีกว่าถ้าเช็คอินและปรับใช้การเปลี่ยนแปลงบริการเว็บด้วยตัวเอง
- ความเสี่ยงต่ำกว่า นี่เป็นผลสืบเนื่องมาจากทั้งหมดที่กล่าวมาข้างต้น
จ่ายมันไปข้างหน้า
ความคิดเห็นเกี่ยวกับการตรวจสอบโค้ดที่ฉันได้รับจากวิศวกรอาวุโสในวันนั้นได้พิสูจน์แล้วว่าเป็นข้อเสนอแนะด้านวิศวกรรมที่ดีที่สุดที่ฉันได้รับตลอดอาชีพการงานของฉันจนถึงตอนนี้
หลายปีต่อมา ฉันได้พบกับวิศวกรอีกคนที่ทำการเปลี่ยนแปลงครั้งใหญ่และครอบคลุมอยู่ตลอดเวลา ฉันแบ่งปันความคิดเห็นเดียวกันกับเขา ดูเหมือนเขาจะรำคาญฉัน และฉันก็เข้าใจว่าทำไม ฉันออกจากงานนั้นก่อนที่จะเห็นว่างานของเขาดีขึ้น ฉันหวังว่าในที่สุดเขาจะได้รับประโยชน์จากการเปลี่ยนแปลงเล็กๆ น้อยๆ สำหรับตัวเขาเองในที่สุด
เขาจะเป็นวิศวกรที่ดีกว่า
