ทีมหนึ่งได้รับมอบหมายให้ดูแลโมดูลการเรียกเก็บเงินที่ไม่มีใครเข้าใจอย่างถ่องแท้ โมดูลนี้ไม่มีการทดสอบใดๆ ที่จะปกป้องพฤติกรรมเดิม จึงมีการเสนอให้จัดสปรินต์เพื่อ "ปรับปรุงแก้ไข" โดยวางแผนที่จะเขียนโค้ดหลักใหม่ในโครงสร้างใหม่ แต่ไม่มีใครบอกได้ว่าจะรู้ได้อย่างไรว่าเวอร์ชันใหม่ยังคงเรียกเก็บเงินจากลูกค้าได้อย่างถูกต้อง
นี่เป็นเพียงสถานการณ์จำลอง ไม่ใช่เหตุการณ์ที่เกิดขึ้นจริง มันอธิบายถึงช่องว่างที่โครงการฝึกอบรมการปรับปรุงโค้ดต้องเติมเต็ม: วิศวกรที่มองเห็นว่าโค้ดนั้นยุ่งเหยิง แต่ยังไม่สามารถวางแผนการปรับปรุงที่เป็นรูปธรรมและแสดงให้เห็นว่าพฤติกรรมเดิมยังคงอยู่
คู่มือนี้จัดทำขึ้นสำหรับหัวหน้าทีมพัฒนาศักยภาพด้านวิศวกรรมและผู้จัดการฝ่ายวิศวกรรม ครอบคลุมวิธีการอธิบายปัญหาด้านประสิทธิภาพ การวินิจฉัยช่องว่าง การออกแบบการเตรียมการและการฝึกฝน การวิเคราะห์กรณีศึกษา และการประเมินว่าทักษะที่ได้รับสามารถนำไปใช้ในงานจริงได้หรือไม่ เนื้อหาเน้นการออกแบบการฝึกอบรม โค้ด การทดสอบ และกฎเกณฑ์ในโปรแกรมของคุณควรได้รับการตรวจสอบโดยวิศวกรอาวุโสในระบบของคุณเอง
โครงการฝึกอบรมการปรับโครงสร้างโค้ดคืออะไร?
โครงการฝึกอบรมการปรับโครงสร้างโค้ด (Refactoring) คือการทำงานอย่างเป็นระบบกับโค้ดเดิม โดยมีวัตถุประสงค์เพื่อสร้างความสามารถและปรับปรุงโค้ด ผู้เรียนวางแผนการเปลี่ยนแปลงเล็กๆ ที่มีขอบเขตจำกัด ป้องกันพฤติกรรมเดิมด้วยการทดสอบ ปรับปรุงการออกแบบทีละเล็กทีละน้อย และแสดงหลักฐานว่าไม่มีอะไรเสียหาย โค้ดจะดีขึ้น และที่สำคัญกว่านั้น วิศวกรจะได้ฝึกฝนการตัดสินใจที่พวกเขาจะต้องใช้ในการจัดการกับหนี้ทางเทคนิคที่เกิดขึ้นจริง
ข้อเท็จจริงด่วน
| คำถาม | ตอบสั้นๆ |
|---|---|
| งานที่ต้องทำคืออะไร? | วางแผนและตรวจสอบความถูกต้องของการปรับปรุงโค้ดเดิมที่มีขอบเขตจำกัด |
| คุณได้คะแนนเท่าไหร่? | การวิเคราะห์ความเสี่ยง และหลักฐานที่แสดงว่าพฤติกรรมเดิมยังคงอยู่ |
| การเขียนใหม่ทั้งหมดถือเป็นโครงการฝึกอบรมที่ดีหรือไม่? | โดยปกติแล้วจะไม่ทำเช่นนั้น เพราะมันจะซ่อนทักษะที่กำลังฝึกฝนอยู่ และทำให้การแสดงพฤติกรรมที่คงไว้เป็นเรื่องยาก |
| แบบทดสอบเกี่ยวกับรูปแบบการปรับโครงสร้างโค้ดเพียงพอหรือไม่? | ไม่ มันเป็นการยืนยันคุณสมบัติเบื้องต้น แต่ไม่ได้ยืนยันว่าวิศวกรสามารถวางแผนและตรวจสอบความถูกต้องของการเปลี่ยนแปลงได้หรือไม่ |
| ใครเป็นผู้ตรวจสอบความถูกต้องของเนื้อหา? | ผู้จัดการฝ่ายวิศวกรรมและวิศวกรอาวุโสที่มีความรู้ความเข้าใจในโค้ดโปรแกรมเป็นอย่างดี |
| การฝึกอบรมแก้ไขอะไรไม่ได้บ้าง? | ขาดอุปกรณ์ทดสอบ แรงดันในการปล่อยตัวไม่ชัดเจน ความเป็นเจ้าของไม่ชัดเจน และไม่มีเวลาสำหรับการบำรุงรักษา |
| คุณรู้ได้อย่างไรว่ามันได้ผล? | กรณีศึกษาโค้ดเก่าที่ไม่เคยพบมาก่อน ซึ่งได้รับการประเมินตามเกณฑ์ที่ตกลงกันไว้ พร้อมติดตามผลในงานจริง |
1. อธิบายปัญหาด้านประสิทธิภาพ
เริ่มต้นด้วยงาน: วางแผนและตรวจสอบความถูกต้องของการปรับปรุงโค้ดเดิมที่มีขอบเขตจำกัด คำว่า “ขอบเขตจำกัด” เป็นคำสำคัญ ผู้เรียนเลือกการเปลี่ยนแปลงที่มีขนาดเล็กพอที่จะทำสำเร็จ และสามารถระบุได้ว่าอะไรอยู่ในขอบเขตและอะไรอยู่นอกขอบเขต
การใช้คำศัพท์ที่แม่นยำช่วยได้ มาร์ติน ฟาวเลอร์ อธิบายการปรับโครงสร้างใหม่ว่า เทคนิคที่มีการควบคุมเพื่อปรับปรุงการออกแบบของฐานรหัสที่มีอยู่ประกอบด้วยการเปลี่ยนแปลงเล็กๆ ที่คงพฤติกรรมเดิมไว้ วลี "คงพฤติกรรมเดิม" คือสิ่งที่แยกการปรับโครงสร้างโค้ดออกจากการเขียนโค้ดใหม่ และเป็นสิ่งที่การฝึกอบรมต้องทำให้เห็นอย่างชัดเจน เช่นเดียวกับคำอุปมาเรื่องหนี้ทางเทคนิค คำนี้ถูกบัญญัติโดย วอร์ด คันนิงแฮมและการอภิปรายของฟาวเลอร์เป็นเครื่องเตือนใจที่มีประโยชน์ว่าหนี้สินสามารถเกิดขึ้นได้โดยเจตนาและอย่างรอบคอบ ดังนั้นโมดูลที่ยุ่งยากทุกโมดูลจึงไม่ใช่ความผิดพลาดที่ต้องแก้ไขเสมอไป
หนังสือของ Michael Feathers เกี่ยวกับโค้ดเก่าก็ใช้แนวทางเดียวกันในการนำไปปฏิบัติ คำอธิบายจากสำนักพิมพ์ระบุว่า หนังสือเล่มนี้สอนนักพัฒนาให้เขียนการทดสอบที่รับประกันได้ว่า... พวกเขาไม่ได้เปลี่ยนแปลงแอปพลิเคชันโดยไม่ได้ตั้งใจและเพื่อควบคุมซอฟต์แวร์ที่มีอยู่โดยไม่ต้องเขียนใหม่ทั้งหมด
เขียนคำอธิบายผลการปฏิบัติงานในประโยคเดียว แล้วให้ผู้จัดการฝ่ายวิศวกรรมตรวจสอบ: “เมื่อมีโมดูลเดิมและเป้าหมายที่กำหนดไว้ วิศวกรเสนอการเปลี่ยนแปลงที่มีขอบเขต เพิ่มการทดสอบที่ระบุพฤติกรรมปัจจุบัน ดำเนินการเปลี่ยนแปลงทีละเล็กทีละน้อย และแสดงให้เห็นว่าพฤติกรรมยังคงเหมือนเดิม”
2. วิเคราะห์ช่องว่างด้านการเรียนรู้และบริบท
ก่อนที่จะเริ่มสร้างอะไรก็ตาม ให้เปรียบเทียบงานที่ต้องการกับสิ่งที่คุณกำลังปฏิบัติและประเมินอยู่ในปัจจุบัน โดยปกติแล้วจะมีสามคำถามที่ช่วยแยกแยะช่องว่างในการฝึกอบรมออกจากสิ่งอื่น ๆ ได้แก่:
- แนวทางปฏิบัติในปัจจุบันใช้โจทย์งานจริงหรือไม่? หากการฝึกอบรมครอบคลุมรูปแบบการปรับโครงสร้างโค้ดในสไลด์ แต่ไม่มีใครเคยแก้ไขโค้ดที่ยังไม่ได้ทดสอบ ก็เท่ากับว่าไม่มีใครได้ฝึกฝนการป้องกันพฤติกรรม หากการประเมินเป็นการทดสอบแบบเลือกตอบเกี่ยวกับข้อบกพร่องของโค้ด ก็เท่ากับเป็นการวัดความสามารถในการจดจำ
- ความต้องการด้านการรับรู้คืออะไร? ในระบบการจำแนกประเภทที่ปรับปรุงใหม่ของบลูม การตัดสินว่าการเปลี่ยนแปลงนั้นปลอดภัยหรือไม่นั้นอยู่ในระดับการวิเคราะห์และการประเมิน ในขณะที่การออกแบบแผนและการทดสอบนั้นอยู่ในระดับการสร้าง การจับคู่กิจกรรมกับระดับเหล่านั้นมีอธิบายไว้ในคู่มือของเราแล้ว การจับคู่กิจกรรมการเรียนรู้กับอนุกรมวิธานของบลูม.
- มีปัจจัยอื่นนอกเหนือจากทักษะที่เป็นอุปสรรคอยู่หรือไม่? ตรวจสอบจำนวนบุคลากร เครื่องมือ และขั้นตอนการทำงาน หากการสร้างใช้เวลาหนึ่งชั่วโมง ก็จะไม่มีใครทำการทดสอบบ่อยๆ หากไม่มีการกำหนดตารางงานบำรุงรักษา วิศวกรก็จะทำการปรับปรุงโค้ดอย่างลับๆ เท่านั้น รายงานสาเหตุที่ไม่เกี่ยวข้องกับการฝึกอบรมให้แก่ผู้ที่สามารถแก้ไขปัญหาได้
3. ออกแบบการเตรียมตัวและการฝึกฝนอย่างมีเป้าหมาย
เมื่อคุณทราบแล้วว่าการฝึกอบรมสามารถช่วยอุดช่องว่างใดได้บ้าง ให้กำหนดหน้าที่ที่ชัดเจนให้กับแต่ละขั้นตอน
การเตรียมการ. ตรวจสอบความรู้พื้นฐานด้วยการวิเคราะห์เบื้องต้น: เฟรมเวิร์กการทดสอบของคุณทำงานอย่างไร การทดสอบลักษณะเฉพาะคืออะไร และทีมของคุณตรวจสอบและรวมโค้ดอย่างไร การศึกษาด้วยตนเองเหมาะสมกับขั้นตอนนี้ การตรวจสอบความจำจะยืนยันเฉพาะความรู้พื้นฐานเท่านั้น
การปฏิบัติ ใช้โปรเจกต์การปรับโครงสร้างโค้ดอย่างเป็นระบบที่มีโครงสร้างชัดเจน เริ่มจากตัวอย่างขนาดเล็กที่ปลอดภัย จากนั้นค่อยขยายไปยังส่วนจริงแต่มีขอบเขตจำกัดของโค้ดเบสของคุณเอง Gilded Rose kata เป็นจุดเริ่มต้นที่รู้จักกันดีสำหรับขั้นตอนแรก README ของมัน ซึ่งดูแลโดย Emily Bache แนะนำให้เขียนโค้ดทดสอบก่อนทำการแก้ไขโค้ด และกำหนดกรอบการทำงานนี้เป็นการฝึกฝนในการก้าวไปทีละเล็กทีละน้อย รันการทดสอบบ่อยๆ และปรับปรุงการออกแบบทีละเล็กทีละน้อย ลำดับขั้นตอนที่เหมาะสมสำหรับแต่ละโครงการคือ: กำหนดเป้าหมายและขอบเขต เขียนการทดสอบที่ครอบคลุมสิ่งที่โค้ดทำในปัจจุบัน เปลี่ยนแปลงทีละอย่าง รันการทดสอบหลังจากทุกขั้นตอน และจดบันทึกสิ่งที่คุณได้เรียนรู้
ฟีดแบ็ก เชื่อมโยงคำติชมกับการตัดสินใจ ไม่ใช่กับคะแนนรวม ตัวอย่างเช่น “คุณแยกตรรกะส่วนลดออกมาได้ แต่การทดสอบของคุณครอบคลุมเฉพาะกรณีที่ไม่มีปัญหา ดังนั้นคุณจึงไม่สามารถสังเกตเห็นการเปลี่ยนแปลงของการปัดเศษได้” มีประโยชน์มากกว่า “3 จาก 5”
การป้อนข้อมูลสดจากผู้สอนหรือการทบทวนแบบไม่พร้อมกัน? การป้อนข้อมูลแบบเรียลไทม์จะเพิ่มคุณค่าสูงสุดเมื่อการตัดสินใจไม่ชัดเจน เช่น ควรหยุดและเพิ่มแบบทดสอบที่ขาดหายไป หรือควรดำเนินการต่อไป การทบทวนแบบไม่พร้อมกันก็เพียงพอแล้วเมื่อผู้เรียนเปรียบเทียบแผนการเรียนและแบบทดสอบของตนเองกับเวอร์ชันที่มีคำอธิบายประกอบจากผู้เชี่ยวชาญ หลายทีมใช้ทั้งสองวิธี: การเตรียมตัวด้วยตนเองก่อน จากนั้นจึงมีช่วงการเรียนรู้แบบมีผู้ช่วยอำนวยความสะดวกในกรณีที่ยาก
4. ลองทำตัวอย่างที่สมจริงดู
เป็นเพียงตัวอย่างเท่านั้น ผู้จัดการฝ่ายวิศวกรรมควรตรวจสอบความถูกต้องของกรณีศึกษาและเกณฑ์การตอบคำถามก่อนนำไปใช้
กรณี. ฟังก์ชันเดิมคำนวณยอดรวมของคำสั่งซื้อ โดยรวมส่วนลด ภาษี และเงื่อนไขการจัดส่งแล้ว แต่ฟังก์ชันนี้ไม่มีการทดสอบ ทีมงานจึงเสนอให้ปรับโครงสร้างโมดูลการเรียกเก็บเงินทั้งหมดใหม่เพื่อให้ "ดูเรียบร้อย" ยิ่งขึ้น
ภารกิจนั้น ผู้เรียนอธิบายสิ่งที่พวกเขาจะทำ อ้างอิงหลักฐานที่พวกเขาจะรวบรวม และบอกว่าพวกเขาต้องการข้อมูลหรือการสนับสนุนเพิ่มเติมอะไรบ้าง
เป็นการลองทำครั้งแรก “ฉันจะแบ่งโมดูลออกเป็นสามส่วนบริการ แล้วย้ายตรรกะไปไว้ส่วนอื่น จากนั้นตรวจสอบตัวเลขในสภาพแวดล้อมทดสอบ” ผู้เรียนเลือกที่จะเปลี่ยนแปลงครั้งใหญ่และตรวจสอบด้วยตนเองในภายหลัง จึงไม่มีทางรู้ได้ว่าเวอร์ชันเก่าและเวอร์ชันใหม่ตรงกันในกรณีพิเศษหรือไม่
ให้ข้อเสนอแนะและลองใหม่อีกครั้ง ผู้ตรวจสอบถามว่าฟังก์ชันนี้ทำงานอย่างไรในปัจจุบันสำหรับตะกร้าสินค้าที่ว่างเปล่า ส่วนลดที่ทำให้ยอดรวมติดลบ และกรณีการปัดเศษ การลองใหม่ขอให้ผู้เรียนจำกัดขอบเขตให้แคบลงเหลือเพียงพฤติกรรมเดียว และบอกว่าพวกเขาจะพิสูจน์ได้อย่างไรว่าพฤติกรรมนั้นไม่ได้เปลี่ยนแปลงไป
ความพยายามที่หนักแน่นกว่าเดิม “ตอนนี้ผมจะปล่อยโครงสร้างโมดูลไว้ก่อน ผมจะบันทึกค่าที่ฟังก์ชันคำนวณยอดรวมคำสั่งซื้อส่งคืนในปัจจุบันสำหรับชุดข้อมูลป้อนเข้าต่างๆ รวมถึงกรณีพิเศษต่างๆ เพื่อใช้เป็นข้อมูลทดสอบ จากนั้นผมจะแยกการคำนวณส่วนลดออกเป็นฟังก์ชันของตัวเอง รันการทดสอบหลังจากขั้นตอนนั้น และหยุด ผมจะจดบันทึกว่ากฎการจัดส่งมีพฤติกรรมที่ผมไม่เข้าใจ และจะถามเพื่อนร่วมงานก่อนที่จะแก้ไขมัน” สังเกตว่าคำตอบนี้จำกัดขอบเขตการเปลี่ยนแปลง ปกป้องพฤติกรรมก่อน และระบุสิ่งที่ยังไม่ทราบ
เหตุใดคำตอบแต่ละข้อจึงสมเหตุสมผลหรือไม่สมบูรณ์ ควรประเมินแต่ละโครงการตามเกณฑ์ที่ได้รับการอนุมัติ ไม่ใช่ตามความชอบส่วนตัวของผู้ประเมิน โครงการแรกอาจเป็นทิศทางที่สมเหตุสมผลในระยะยาว แต่ยังไม่สมบูรณ์ในฐานะแผนงาน เพราะไม่มีหลักฐานแสดงถึงพฤติกรรมที่คงอยู่ โครงการที่แข็งแกร่งกว่านั้นมีขนาดเล็ก ตรวจสอบได้ และซื่อสัตย์เกี่ยวกับความไม่แน่นอน
5. ประเมินศักยภาพและวางแผนการถ่ายโอน
หลักฐานแสดงถึงความสามารถคือผลการปฏิบัติงานในกรณีศึกษาโค้ดเก่าที่ผู้เรียนไม่เคยเห็นมาก่อน ให้คะแนนการวิเคราะห์ความเสี่ยงและหลักฐานที่แสดงว่าพฤติกรรมยังคงอยู่ เกณฑ์การให้คะแนนอย่างง่ายใช้มาตราส่วน 0 ถึง 2 ต่อเกณฑ์:
| เกณฑ์ | หลักฐานที่สังเกตได้ |
|---|---|
| การดำเนินการงาน | วางแผนและตรวจสอบความถูกต้องของการปรับปรุงโค้ดเดิมที่มีขอบเขตจำกัด และบันทึกการดำเนินการและหลักฐานที่เกี่ยวข้อง |
| เหตุผล | อธิบายข้อจำกัด ทางเลือก และความไม่แน่นอน รวมถึงตรวจสอบความเสี่ยงและหลักฐานที่แสดงว่าพฤติกรรมยังคงเหมือนเดิม |
| ขอบเขต | ปฏิบัติตามขั้นตอนที่ได้รับการอนุมัติ และขอความช่วยเหลือเมื่อข้อมูลหรือผู้มีอำนาจไม่เพียงพอ |
เกณฑ์การให้คะแนน: 0 คือ ขาดหายไปหรือไม่ได้รับการสนับสนุน 1 คือ ขาดหายไปบางส่วนแต่มีรายละเอียดที่สำคัญ และ 2 คือ สมบูรณ์และมีเหตุผลรองรับตามเกณฑ์ที่ตกลงกันไว้ กำหนดข้อผิดพลาดที่สำคัญแยกต่างหาก เช่น การเปลี่ยนแปลงพฤติกรรมโดยไม่มีการทดสอบใด ๆ ที่จะตรวจพบได้ ดังนั้นคะแนนโดยรวมจึงไม่สามารถปกปิดข้อผิดพลาดนั้นได้ เกณฑ์การให้คะแนนนี้เป็นเพียงข้อเสนอแนะ ไม่ใช่มาตรฐานความพร้อมที่ได้รับการตรวจสอบแล้ว: โปรดปรับปรุงร่วมกับผู้จัดการฝ่ายวิศวกรรมและทดลองใช้ คู่มือของเราสำหรับ ออกแบบแบบฝึกหัดเชิงโต้ตอบพร้อมข้อเสนอแนะที่เป็นประโยชน์ แสดงวิธีการเขียนข้อเสนอแนะที่เชื่อมโยงกับการตัดสินใจ
วางแผนการถ่ายโอนความรู้ให้รอบคอบ หลังจากเสร็จสิ้นการฝึกอบรม ให้วิศวกรแต่ละคนรับผิดชอบงานจริงชิ้นเล็กๆ เพื่อนำไปแก้ไขร่วมกับผู้ตรวจสอบ หรือทำการทบทวนสั้นๆ เกี่ยวกับการเปลี่ยนแปลงล่าสุดที่ทำให้เกิดปัญหา ตรวจสอบการถ่ายโอนความรู้หลังจากได้รับประสบการณ์การทำงานจริงที่เหมาะสม ไม่ใช่ตรวจสอบทันทีหลังจากเสร็จสิ้นการฝึกอบรม
ในกรณีที่การนำเสนอแบบโต้ตอบมีประโยชน์
รูปแบบอินเทอร์แอคทีฟช่วยให้ทุกคนควรตกลงกันก่อนที่จะเห็นภาพรวม ในเซสชันสด ผู้ดำเนินรายการสามารถแสดงตัวอย่างโค้ดเก่าสั้นๆ ถามวิศวกรแต่ละคนให้ส่งการเปลี่ยนแปลงแรกที่พวกเขาจะทำและวิธีการพิสูจน์ว่าปลอดภัย จากนั้นจึงเปิดเผยผลลัพธ์ก่อนการอภิปราย สามารถใช้ขั้นตอนเดียวกันนี้ในการเรียนรู้ด้วยตนเองเพื่อเตรียมความพร้อมได้เช่นกัน AhaSlides รองรับการเรียนรู้แบบอินเทอร์แอคทีฟและการสลับระหว่างการนำเสนอแบบสดและการเรียนรู้ด้วยตนเอง เป็นเครื่องมือสำหรับการนำเสนอและการเรียนรู้ ไม่ใช่สถานที่สำหรับรันหรือวิเคราะห์โค้ด ดังนั้นควรรันการปรับโครงสร้างโค้ดในสภาพแวดล้อมของคุณเอง ตรวจสอบฟังก์ชันการเขียน การให้ข้อเสนอแนะ หรือการรายงานเฉพาะใดๆ ที่คุณวางแผนจะใช้กับเวิร์กโฟลว์ของคุณเอง สำหรับคำแนะนำในการเลือกรูปแบบ โปรดดูบทความของเราเกี่ยวกับ เมื่อใดควรใช้การเรียนรู้แบบปรับเปลี่ยนได้ การเรียนรู้แบบโต้ตอบ และการเรียนรู้แบบสด.
วัดสิ่งที่เปลี่ยนแปลงไป
กำหนดล่วงหน้าว่าอะไรที่จะแสดงให้เห็นว่าวิศวกรสามารถทำงานนั้นได้ เปรียบเทียบคุณภาพของการวิเคราะห์ความเสี่ยงและหลักฐานของพฤติกรรมที่คงไว้ในกรณีที่ไม่เคยพบมาก่อน กับเกณฑ์พื้นฐาน กำหนดว่าใครบ้างที่รวมอยู่ ตัวหาร และช่วงเวลา หากผลลัพธ์ดีขึ้น ให้ตรวจสอบว่ามีอะไรเปลี่ยนแปลงไปบ้างในช่วงเวลาเดียวกัน เช่น เครื่องมือทดสอบใหม่ การสร้างที่เร็วขึ้น หรือการเปลี่ยนแปลงเจ้าของ ก่อนที่จะให้เครดิตการฝึกอบรม
ข้อจำกัดที่อาจยังคงอยู่
- ถึงเวลาสำหรับการบำรุงรักษาแล้ว หากไม่มีการกำหนดตารางงานสำหรับการแก้ไขปัญหาหนี้สิน วิศวกรที่ได้รับการฝึกฝนมาก็ยังไม่มีที่ที่จะนำทักษะของตนไปใช้ได้
- เครื่องมือทดสอบ หากไม่มีชุดทดสอบที่ใช้งานได้หรือกระบวนการสร้างที่รวดเร็ว การดำเนินการทีละเล็กทีละน้อยและการตรวจสอบบ่อยครั้งจึงทำได้ยาก
- ความคุ้มครองตามคดี กรณีศึกษาในอดีตแสดงให้เห็นถึงความเสี่ยงหลายประเภท คะแนนเพียงอย่างเดียวไม่สามารถอธิบายวิจารณญาณของวิศวกรโดยทั่วไปได้
- การพิจารณาว่าเมื่อใดไม่ควรทำการปรับโครงสร้างโค้ดใหม่ โค้ดบางส่วนควรปล่อยไว้เหมือนเดิม บางส่วนควรเปลี่ยน หรือบางส่วนควรเลิกใช้ และการตัดสินใจนั้นเกี่ยวข้องมากกว่าแค่ทักษะ
- โอน ประสิทธิภาพในการฝึกท่ารำ (kata) ไม่เหมือนกับประสิทธิภาพในการทำงานในโมดูลการผลิตภายใต้แรงกดดันด้านการส่งมอบงาน
แจ้งปัญหาเหล่านี้ให้ผู้สนับสนุนทราบตั้งแต่เนิ่นๆ และวางแผนแก้ไขแยกต่างหาก การฝึกอบรมช่วยเพิ่มความสามารถในการวางแผนและพิสูจน์ของวิศวกร แต่ไม่ได้สร้างเวลาหรือเครื่องมือขึ้นมาใหม่
คำถามที่พบบ่อย
โครงการฝึกอบรมการปรับโครงสร้างโค้ดคืออะไร?
เป็นแนวทางปฏิบัติที่เป็นระบบสำหรับโค้ดเดิม โดยที่วิศวกรวางแผนการเปลี่ยนแปลงเล็กๆ น้อยๆ ป้องกันพฤติกรรมเดิมด้วยการทดสอบ เปลี่ยนแปลงการออกแบบทีละเล็กทีละน้อย และแสดงให้เห็นว่าไม่มีอะไรเสียหาย
การเขียนโค้ดใหม่ทั้งหมดเป็นวิธีที่ดีในการเรียนรู้เกี่ยวกับหนี้ทางเทคนิคหรือไม่?
โดยปกติแล้วไม่ใช่ การเขียนโค้ดใหม่ทั้งหมดนั้นมีขนาดใหญ่ ตรวจสอบความถูกต้องได้ยาก และบดบังทักษะที่คุณต้องการพัฒนา การเปลี่ยนแปลงแบบจำกัดขอบเขตพร้อมการทดสอบที่ครอบคลุมพฤติกรรมปัจจุบันจะทำให้เห็นเหตุผลได้ชัดเจนขึ้น
คุณประเมินอย่างไรว่าวิศวกรสามารถทำการปรับโครงสร้างโค้ดได้อย่างปลอดภัย?
ยกตัวอย่างโค้ดเก่าชุดใหม่ แล้วให้คะแนนการวิเคราะห์ความเสี่ยงและหลักฐานที่แสดงว่าพฤติกรรมยังคงเป็นไปตามเกณฑ์ที่ตกลงกันไว้ แบบทดสอบเกี่ยวกับรูปแบบการปรับโครงสร้างโค้ดจะยืนยันเฉพาะความรู้พื้นฐานเท่านั้น
คุณต้องการโค้ดตัวอย่างสำหรับการฝึกอบรมหรือไม่?
คุณจำเป็นต้องมีพื้นที่ฝึกฝนที่ปลอดภัย ทีมหลายทีมเริ่มต้นด้วยการฝึกแบบสาธารณะ (public kata) ก่อน แล้วค่อยขยายไปยังส่วนที่กำหนดของโค้ดของตนเอง ผู้จัดการฝ่ายวิศวกรรมของคุณควรตรวจสอบว่าโค้ดนั้นเหมาะสมหรือไม่
จะเริ่มที่ไหนดี
เลือกการเปลี่ยนแปลงแบบเดิม ๆ ขนาดเล็กที่เกิดขึ้นซ้ำ ๆ ในโค้ดของคุณ เขียนคำอธิบายประสิทธิภาพ ให้ผู้จัดการฝ่ายวิศวกรรมตรวจสอบกรณีและชุดทดสอบที่จะแสดงให้เห็นถึงพฤติกรรมที่ยังคงอยู่ และร่างเกณฑ์การประเมินสามข้อโดยใช้มาตราส่วน 0 ถึง 2 พร้อมรายการข้อผิดพลาดที่สำคัญ ทดลองใช้กับกลุ่มเล็ก ๆ ก่อนที่จะนำไปใช้งานจริง
หากต้องการเรียนรู้วิธีการดำเนินการฝึกตัดสินใจเกี่ยวกับการปรับโครงสร้างโค้ด (refactoring) กับทีมของคุณโดยตรง และนำไปใช้ซ้ำได้ตามความสะดวกในภายหลัง โปรดสำรวจ AhaSlides
