การรีแฟกเตอร์คอมโพเนนต์ React อย่างปลอดภัยด้วย Claude Code

ทำไมการรีแฟกเตอร์ React จึงเสี่ยงในโค้ดจริง

การรีแฟกเตอร์ React รู้สึกเสี่ยงเพราะคอมโพเนนต์ส่วนใหญ่ไม่ใช่บล็อกเล็กๆ ที่สะอาด พวกมันเป็นกองของ UI, state, effects และการแก้ด้วย "props อีกตัวเดียว" เมื่อคุณเปลี่ยนโครงสร้าง คุณมักจะเปลี่ยนเวลา, identity หรือการไหลของข้อมูลโดยไม่ได้ตั้งใจ

การรีแฟกเตอร์มักเปลี่ยนพฤติกรรมเมื่อมันเผลอ:\n\n- รีเซ็ตสเตตเพราะขอบเขตคอมโพเนนต์ย้ายหรือ key เปลี่ยน\n- เปลี่ยนเวลาที่เอฟเฟกต์ทำงานเพราะ dependencies เปลี่ยนหรือ mount/unmount เปลี่ยน\n- ทำให้ memoization พัง ทำให้ handler และค่าที่ได้ถูกคำนวณใหม่ทุกเรนเดอร์\n- เลื่อนไปยังการจัดการเหตุการณ์ (focus, blur, keyboard, pointer) โดยเฉพาะหลังจากห่อหรืแยก markup\n- ทำให้การดึงข้อมูลหรือการ subscribe ถูกทำซ้ำเพราะตรรกะถูกคัดลอกแทนที่จะรวมศูนย์

การรีแฟกเตอร์ก็จะกลายเป็นการเขียนใหม่เมื่อการ “ทำความสะอาด” ผสมกับ “การปรับปรุง” คุณเริ่มจากการสกัดคอมโพเนนต์ แล้วเปลี่ยนชื่อหลายอย่าง แล้ว “แก้” รูปร่างของสเตต แล้วแทนที่ฮุก ไม่นานคุณจะเปลี่ยนตรรกะพร้อมกับเปลี่ยนเลย์เอาต์ หากไม่มีราวป้องกัน จะยากที่จะรู้ว่าการเปลี่ยนใดทำให้เกิดบั๊ก

การรีแฟกเตอร์ที่ปลอดภัยมีคำสัญญาง่ายๆ หนึ่งข้อ: ผู้ใช้จะได้พฤติกรรมเดิม และโค้ดจะชัดเจนขึ้น Props, events, สถานะการโหลด, สถานะข้อผิดพลาด และเคสมุมควรทำงานเหมือนเดิม หากพฤติกรรมเปลี่ยน มันควรเป็นการเปลี่ยนที่ตั้งใจเล็กๆ และชัดเจน

ถ้าคุณกำลังรีแฟกเตอร์คอมโพเนนต์ React ด้วย Claude Code (หรือผู้ช่วยเขียนโค้ดใดๆ) ให้ปฏิบัติต่อมันเหมือนเพื่อนร่วมคู่โปรแกรมเมอร์ที่ทำงานเร็ว ไม่ใช่ออโตไพลอต ให้ขอมันอธิบายความเสี่ยงก่อนแก้โค้ด เสนอแผนทีละเล็กน้อย และอธิบายว่ามันตรวจสอบอย่างไรว่า พฤติกรรมยังคงเหมือนเดิม จากนั้นให้คุณยืนยันด้วยตัวเอง: รันแอป คลิกเส้นทางที่แปลกๆ และพึ่งพาการทดสอบที่จับสิ่งที่คอมโพเนนต์ทำวันนี้ ไม่ใช่สิ่งที่คุณอยากให้มันทำ

เลือกเป้าหมายและตั้งวัตถุประสงค์การรีแฟกเตอร์ให้ชัด

เลือกคอมโพเนนต์เดียวที่กินเวลาคุณจริงๆ ไม่ใช่ทั้งหน้า ไม่ใช่ “เลเยอร์ UI” และไม่ใช่คำว่า “ทำความสะอาด” แบบคลุมเครือ เลือกคอมโพเนนต์เดียวที่อ่านยาก แก้ยาก หรือเต็มไปด้วยสเตตและผลข้างเคียงที่เปราะบาง เป้าหมายที่ตึงจะทำให้คำแนะนำของผู้ช่วยตรวจสอบได้ง่ายขึ้น

เขียนเป้าหมายที่คุณตรวจได้ภายในห้านาที เป้าหมายที่ดีเกี่ยวกับโครงสร้าง ไม่ใช่ผลลัพธ์: “แยกเป็นคอมโพเนนต์ย่อย”, “ทำให้สเตตตามได้ง่ายขึ้น”, หรือ “ทำให้ทดสอบได้โดยไม่ต้องม็อกครึ่งแอป” หลีกเลี่ยงเป้าหมายเช่น “ทำให้ดีขึ้น” หรือ “ปรับปรุงประสิทธิภาพ” เว้นแต่คุณจะมีเมตริกและคอขวดที่รู้ชัด

ตั้งขอบเขตก่อนเปิด editor รีแฟกเตอร์ที่ปลอดภัยที่สุดมักจะน่าเบื่อ:\n\n- ไม่มีการเปลี่ยนแปลงภาพ (เลย์เอาต์เดียวกัน ข้อความเดียวกัน ระยะห่างเหมือนเดิม)\n- ไม่มีฟีเจอร์ใหม่ (แม้แต่ “ในโอกาสนี้ เพิ่มการจัดเรียง”)\n- พฤติกรรมภายนอกเหมือนเดิม (props เข้า, UI และ callbacks ออก)\n- ทำทีละคอมโพเนนต์ (ทำให้เสร็จหนึ่งตัวก่อนเริ่มตัวถัดไป)\n\nจากนั้นจงระบุพึ่งพาที่อาจทำให้พฤติกรรมเงียบๆ แตกเมื่อคุณย้ายโค้ด: การเรียก API, context providers, routing params, feature flags, analytics events, และสเตตระดับ global ที่แชร์

ตัวอย่างที่จับต้องได้: คุณมี OrdersTable ยาว 600 บรรทัดที่ดึงข้อมูล, กรอง, จัดการการเลือก, และแสดง drawer สำหรับรายละเอียด เป้าหมายที่ชัดเจนอาจเป็น: “สกัดการเรนเดอร์แถวและ UI ของ drawer ออกเป็นคอมโพเนนต์ และย้ายสเตตการเลือกเข้า reducer เดียว โดยไม่เปลี่ยน UI” เป้าหมายนี้บอกว่าจบคืออะไรและอะไรอยู่นอกขอบเขต

แช่แข็งพฤติกรรมก่อนแตะโค้ด

ก่อนรีแฟกเตอร์ ให้ถือคอมโพเนนต์เป็นกล่องดำ งานของคุณคือต้องจับสิ่งที่มันทำวันนี้ ไม่ใช่สิ่งที่คุณอยากให้มันทำ วิธีนี้ช่วยป้องกันไม่ให้รีแฟกเตอร์กลายเป็นการออกแบบใหม่

เริ่มเขียนพฤติกรรมปัจจุบันเป็นภาษาธรรมดา: เมื่อได้รับอินพุตเหล่านี้ UI แสดงผลลัพธ์นั้น รวม props, พารามิเตอร์ URL, feature flags และข้อมูลใดๆ ที่มาจาก context หรือ store หากคุณใช้ Claude Code ให้วางสคริปต์เล็กๆ ที่เน้นเฉพาะส่วนและขอให้มันสังเขปพฤติกรรมเป็นประโยคเฉพาะที่คุณตรวจได้ทีหลัง

ครอบคลุมสถานะ UI ที่ผู้คนเห็นจริง คอมโพเนนต์อาจดูปกติบนเส้นทางที่ดี แต่พังเมื่อเข้าสู่สถานะ loading, empty หรือ error

นอกจากนี้บันทึกกฎแฝงที่ง่ายจะพลาดและมักทำให้รีแฟกเตอร์พัง:\n\n- ตัวเลือกเริ่มต้น (แท็บที่เลือก คอลัมน์เรียงลำดับเริ่มต้น ค่าฟิลเตอร์เริ่มต้น)\n- กฎการฟอร์แมต (วันที่ สกุลเงิน การตัดทอน ตัวอักษรตัวใหญ่เล็ก)\n- กฎการเรียง (การเรียงที่เสถียร การจัดกลุ่ม รายการปักหมุด)\n- กฎการโต้ตอบ (อะไรรีเซ็ตเมื่อเปลี่ยนฟิลเตอร์ อะไรคงโฟกัสไว้)\n- เคสขอบที่ผู้ใช้พึ่งพา (สตริงว่าง vs null, ค่า zero, ข้อมูลบางส่วน)

ตัวอย่าง: คุณมีตารางผู้ใช้ที่โหลดผล รองรับการค้นหา และเรียงตาม “Last active” เขียนลงไปว่าจะเกิดอะไรขึ้นเมื่อการค้นหาเป็นค่าว่าง เมื่อ API คืนลิสต์ว่าง เมื่อ API ขัดข้อง และเมื่อผู้ใช้สองคนมีเวลา “Last active” เท่ากัน ระบุรายละเอียดเล็กๆ เช่น การเรียงไม่แยกตัวพิมพ์ใหญ่/เล็กไหม และตารางเก็บหน้าปัจจุบันเมื่อฟิลเตอร์เปลี่ยนหรือไม่

เมื่อบันทึกของคุณเริ่มน่าเบื่อและเฉพาะเจาะจง แปลว่าคุณพร้อมแล้ว

เพิ่ม characterization tests ที่ล็อกพฤติกรรมปัจจุบัน

Characterization tests คือการทดสอบแบบ “นี่คือสิ่งที่มันทำวันนี้” พวกมันอธิบายพฤติกรรมปัจจุบัน แม้มันจะแปลกหรือไม่ตรงกับที่คุณอยากให้เป็น ฟังดูย้อนแย้ง แต่ช่วยไม่ให้รีแฟกเตอร์กลายเป็นการเขียนใหม่

เมื่อรีแฟกเตอร์คอมโพเนนต์ React ด้วย Claude Code การทดสอบพวกนี้คือราวป้องกัน เครื่องมืออาจช่วยปรับโค้ด แต่คุณเป็นคนตัดสินว่าสิ่งใดห้ามเปลี่ยน

โฟกัสที่สิ่งที่ผู้ใช้ (และโค้ดอื่น) พึ่งพา:\n\n- การเรนเดอร์: สิ่งที่ปรากฏสำหรับสถานะสำคัญ (empty, loading, error, normal)\n- การโต้ตอบ: คลิก, พิมพ์, คีย์บอร์ดนำทาง, การเลือก, การแบ่งหน้า\n- ค่าที่ได้มาจากการคำนวณ: ยอดรวม, จำนวนที่กรองแล้ว, กฎการฟอร์แมต, สถานะปิดใช้งาน\n- ผลข้างเคียง: การเรียก analytics, บันทึกฉบับร่าง, การอัปเดต URL, การจัดการโฟกัส\n- การจัดการข้อผิดพลาด: เกิดอะไรขึ้นเมื่อการกระทำล้มเหลว

เพื่อให้เทสคงตัว ให้ assert ผลลัพธ์ ไม่ใช่การทำงานภายใน ตัวอย่างเช่น ให้ใช้ “ปุ่ม Save ถูกปิดและมีข้อความปรากฏ” ดีกว่า “setState ถูกเรียก” หรือ “ฮุกนี้วิ่ง” หากเทสล้มเพราะคุณเปลี่ยนชื่อคอมโพเนนต์หรือเรียงฮุกใหม่ แปลว่าเทสไม่ได้ปกป้องพฤติกรรม

พฤติกรรมแบบ async เป็นที่ที่รีแฟกเตอร์มักเปลี่ยนเวลา ระบุให้ชัด: รอให้ UI ตั้งค่าเสร็จ แล้วค่อย assert ถ้ามีตัวจับเวลา (debounced search, toast ดีเลย์) ให้ใช้ fake timers และเลื่อนเวลา หากมีการเรียกเครือข่าย ให้ม็อก fetch และ assert สิ่งที่ผู้ใช้เห็นหลังสำเร็จและหลังล้ม สำหรับ flow แบบ Suspense ให้ทดสอบทั้ง fallback และมุมมองหลัง resolve

ตัวอย่าง: ตาราง “Users” แสดง “No results” เฉพาะหลังการค้นหาสำเร็จ Characterization test ควรล็อกลำดับนั้นไว้: ตัวบอกสถานะ loading ก่อน แล้วตามด้วย rows หรือข้อความว่าง โดยไม่สนใจว่าคุณจะแยกคอมโพเนนต์อย่างไรในภายหลัง

วิธีปฏิบัติทีละขั้นกับ Claude Code

ชัยชนะไม่ใช่ "เปลี่ยนใหญ่เร็วขึ้น" แต่คือการเห็นภาพชัดว่าคอมโพเนนต์ทำอะไร แล้วเปลี่ยนทีละเล็กน้อยในขณะที่คงพฤติกรรมไว้

เริ่มจากวางคอมโพเนนต์และขอให้สรุปความรับผิดชอบเป็นภาษาอังกฤษเรียบง่าย (หรือภาษาที่คุณใช้งาน) บังคับให้ระบุ: มันแสดงข้อมูลอะไร การกระทำของผู้ใช้ใดที่มันจัดการ และผลข้างเคียงใดที่มันกระตุ้น (fetching, timers, subscriptions, analytics) นี่มักเผยงานที่ซ่อนอยู่ซึ่งทำให้รีแฟกเตอร์เสี่ยง

ถัดไป ขอแผนที่พึ่งพา (dependency map) คุณต้องการรายการ input และ output ทุกอย่าง: props, การอ่าน context, custom hooks, สเตตท้องถิ่น, ค่าที่คำนวณได้, effects, และ helper บนระดับโมดูล แผนที่ที่ดีจะบอกว่าส่วนใดย้ายได้ปลอดภัย (การคำนวณเพียวๆ) และส่วนใดที่ “เหนียว” (เวลา, DOM, เครือข่าย)

จากนั้นขอให้มันเสนอผู้สมัครสำหรับการสกัด พร้อมกฎเข้มงวดหนึ่งข้อ: แยกชิ้นมุมมองเพียวๆ ออกจากชิ้นคอนโทรลของสเตต JSX หนักที่ต้องการแค่ props เหมาะสำหรับการสกัดครั้งแรก ส่วนที่ผสม event handlers, async calls และการอัปเดตสเตตมักไม่ควรถูกสกัดทันที

เวิร์กโฟลว์ที่ยืนได้ในโค้ดจริง:\n\n- ยืนยันว่าสรุปความรับผิดชอบและแผนที่พึ่งพาตรงกับสิ่งที่คุณเห็น\n- เลือกผู้สมัครสกัดที่เป็น presentation เป็นหลัก และย้ายแค่ส่วนนั้น\n- รัน characterization tests ใหม่และทำการคลิกผ่านด้วยตา\n- จัดการปมสเตต/เอฟเฟกต์ทีละปม (ไม่ใช่ทั้งหมด) แล้วทดสอบอีกครั้ง\n- ทำซ้ำจนคอมโพเนนต์ต้นทางอ่านเหมือนคู่อำนวยการเล็กๆ

Checkpoint สำคัญ ขอให้ Claude Code ทำแผนเล็กที่แต่ละขั้นสามารถคอมมิตและย้อนกลับได้ จุดเช็คพอยต์ปฏิบัติอาจเป็น: “สกัด \u003cTableHeader\u003e โดยไม่เปลี่ยน logic” ก่อนแตะการเรียง

ตัวอย่างจริง: ถ้าคอมโพเนนต์เรนเดอร์ customer table ควบคุมฟิลเตอร์ และดึงข้อมูล ให้สกัด markup ของตารางก่อน (headers, rows, empty state) เป็นคอมโพเนนต์เพียวๆ ก่อนจะย้ายสเตตฟิลเตอร์หรือเอฟเฟกต์การดึง ข้อตอนนี้ช่วยกันไม่ให้บั๊กเดินทางมากับ JSX

สกัดคอมโพเนนต์โดยไม่ย้ายบั๊กไปด้วย

เมื่อคุณแยกคอมโพเนนต์ ความเสี่ยงไม่ใช่การย้าย JSX แต่คือการเผลอเปลี่ยนการไหลของข้อมูล เวลา หรือการต่อสายเหตุการณ์ ปฏิบัติการสกัดเหมือนการคัดลอกแล้วเชื่อมต่อก่อน แล้วค่อยทำความสะอาดทีหลัง

เริ่มจากมองหาขอบเขตที่มีอยู่แล้วใน UI ไม่ใช่โครงไฟล์ มองหาส่วนที่คุณอธิบายได้ว่าเป็น “สิ่งหนึ่ง” ในประโยค: header พร้อม actions, แถบฟิลเตอร์, รายการผลลัพธ์, footer กับ pagination

การเคลื่อนที่ที่ปลอดภัยครั้งแรกคือสกัดคอมโพเนนต์นำเสนอเพียวๆ: props เข้า, JSX ออก ทำให้จงใจน่าเบื่อ ห้ามมีสเตตใหม่ ห้ามมีเอฟเฟกต์ ห้ามเรียก API ถ้าคอมโพเนนต์เดิมมี handler ที่ทำสามอย่าง ให้เก็บ handler ไว้ที่พาเรนต์แล้วส่งลงไป

ขอบเขตที่ปลอดภัยได้แก่ header, list และ row item, ฟิลเตอร์ (เฉพาะอินพุต), คอนโทรล footer (pagination, totals, bulk actions), และไดอะล็อก (เปิด/ปิดและ callbacks ที่ส่งเข้า) เป็นต้น

การตั้งชื่อสำคัญเกินคาด เลือกชื่อเฉพาะเช่น UsersTableHeader หรือ InvoiceRowActions หลีกเลี่ยงชื่อรวมๆ เช่น “Utils” หรือ “HelperComponent” เพราะซ่อนความรับผิดชอบและชักนำให้ผสมความรับผิดชอบ

แนะนำให้สร้าง container component ก็ต่อเมื่อมีความจำเป็นจริงๆ: ชิ้น UI ที่ต้องถือสเตตหรือเอฟเฟกต์เพื่อให้คงความสอดคล้อง แม้กระนั้นให้แคบไว้ Container ที่ดีรับผิดชอบเป้าหมายเดียว (เช่น “state ฟิลเตอร์”) และส่งทุกอย่างเป็น props

แก้ปมสเตตและเอฟเฟกต์เป็นก้าวเล็กๆ และปลอดภัย

คอมโพเนนต์ที่ยุ่งมักผสมข้อมูลสามแบบ: สเตต UI จริง (สิ่งที่ผู้ใช้แก้), ข้อมูลอนุพันธ์ (ที่คำนวณได้), และสเตตจากเซิร์ฟเวอร์ (ข้อมูลจากเครือข่าย) หากคุณปฏิบัติต่อทั้งหมดเป็นสเตตท้องถิ่น รีแฟกเตอร์จะเสี่ยงเพราะคุณอาจเผลอเปลี่ยนเวลาที่ของการอัปเดต

เริ่มจากติดป้ายแต่ละชิ้นของข้อมูล ถามว่า: ผู้ใช้แก้ไขไหม หรือคำนวณจาก props, state และข้อมูลดึงมาหรือไม่ นอกจากนี้ถามด้วย: ค่านี้เป็นเจ้าของที่นี่หรือแค่ส่งผ่าน

แยกสเตตออกจากค่าที่คำนวณได้

ค่าที่คำนวณได้ไม่ควรอยู่ใน useState ย้ายมันไปฟังก์ชันเล็กๆ หรือ selector ที่ memoized เมื่อมันแพง การทำเช่นนี้ลดการอัปเดตสเตตและทำให้พฤติกรรมเดาได้ง่ายขึ้น

รูปแบบที่ปลอดภัย:\n\n- เก็บเฉพาะค่าที่ผู้ใช้แก้ใน useState\n- คำนวณค่าที่ดูได้จากอินพุตเหล่านั้น\n- ส่งค่าที่คำนวณลงไป ไม่ส่ง setters เว้นแต่ลูกจริงๆ จะแก้มัน\n- ถ้าประสิทธิภาพสำคัญ ใช้ useMemo ห่อการคำนวณหนัก

ทำให้เอฟเฟกต์น่าเบื่อและเฉพาะเจาะจง

เอฟเฟกต์จะทำให้พฤติกรรมพังเมื่อตัวมันทำมากเกินไปหรือตอบสนองต่อ dependencies ผิด เป้าหมายคือเอฟเฟกต์หนึ่งตัวต่อจุดประสงค์หนึ่ง: หนึ่งตัวสำหรับ sync ไปที่ localStorage, หนึ่งตัวสำหรับการดึงข้อมูล, หนึ่งตัวสำหรับ subscription หากเอฟเฟกต์อ่านค่าหลายตัว มันมักซ่อนความรับผิดชอบเพิ่ม

ถ้าคุณใช้ Claude Code ให้ขอการเปลี่ยนแปลงเล็กๆ: แยกเอฟเฟกต์หนึ่งตัวเป็นสองตัว หรือย้ายความรับผิดชอบหนึ่งอย่างไป helper แล้วรัน characterization tests หลังแต่ละการเคลื่อนไหว

ระวังการ prop drilling การแทนที่ด้วย context ช่วยได้เมื่อมันลดการเดินสายซ้ำและทำให้ ownership ชัดสัญลักษณ์ที่ดีคือ context อ่านได้เหมือนแนวคิดระดับแอป (current user, theme, feature flags) ไม่ใช่ทางแก้สำหรับต้นไม้คอมโพเนนต์เดียว

ตัวอย่าง: คอมโพเนนต์ตารางอาจเก็บทั้ง rows และ filteredRows ใน state เก็บ rows เป็นสเตต คำนวณ filteredRows จาก rows บวก query และเก็บโค้ดการกรองในฟังก์ชันเพียวๆ เพื่อให้ทดสอบง่ายและยากที่จะทำพัง

ใช้จุดเช็คพอยต์เพื่อย้อนกลับอย่างรวดเร็ว

รีแฟกเตอร์มักพังเมื่อคุณเปลี่ยนมากเกินไปก่อนจะสังเกต การแก้คือ: ทำงานเป็นจุดเช็คพอยต์เล็กๆ และปฏิบัติต่อแต่ละจุดเหมือนการรีลีสย่อย ถึงแม้คุณทำงานในสาขาเดียว ให้เก็บการเปลี่ยนแปลงให้เป็นขนาด PR เพื่อให้คุณเห็นว่าพังตรงไหนและทำไม

หลังการเคลื่อนไหวที่มีนัยสำคัญทุกครั้ง (สกัดคอมโพเนนต์, เปลี่ยนการไหลของสเตต) หยุดและยืนยันว่าคุณไม่ได้เปลี่ยนพฤติกรรม หลักฐานนี้อาจเป็นอัตโนมัติ (เทส) และด้วยตา (เช็กเร็วในเบราว์เซอร์) เป้าหมายไม่ใช่ความสมบูรณ์ แต่มันคือการตรวจจับเร็ว

ลูปเช็คพอยต์ที่ปฏิบัติได้:\n\n- ทำการเปลี่ยนเล็กๆ หนึ่งอย่าง (การสกัดหนึ่งชิ้น, การย้ายสเตตหนึ่งอย่าง, การทำความสะอาด effect หนึ่งอย่าง)\n- รันเทสชุดทั้งหมด หรืออย่างน้อย characterization tests ในพื้นที่นั้น\n- ตรวจเช็กด้วยตาเส้นทางผู้ใช้หลักที่คุณสนใจ\n- บันทึกจุดย้อนกลับ (git commit หรือ snapshot ของแพลตฟอร์ม)

ถ้าคุณใช้แพลตฟอร์มอย่าง Koder.ai สแนปช็อตและการย้อนกลับทำหน้าที่เหมือนราวป้องกันขณะคุณทำซ้ำ คุณยังต้องการ commit ปกติ แต่สแนปช็อตช่วยเมื่อคุณต้องการเปรียบเทียบเวอร์ชัน “ที่รู้ว่าดี” กับเวอร์ชันปัจจุบัน หรือเมื่อการทดลองผิดพลาด

เก็บบันทึกพฤติกรรมง่ายๆ ขณะทำงาน มันเป็นเพียงบันทึกสั้นๆ เกี่ยวกับสิ่งที่คุณยืนยันแล้ว และมันป้องกันไม่ให้คุณตรวจซ้ำสิ่งเดิมๆ

ตัวอย่าง:\n\n- การเรียงตาราง: ยังคงเรียงตามคอลัมน์เดิมและไอคอนลูกศรยังแสดงสถานะ\n- การเลือกแถว: จำนวนที่เลือกอัปเดต, bulk actions เปิดใช้ถูกต้อง\n- สถานะโหลดและข้อผิดพลาด: spinner และปุ่ม retry ปรากฏในกรณีเดียวกัน

เมื่อบางอย่างพัง ledger จะบอกว่าคุณต้องเช็กอะไรอีก และจุดเช็คพอยต์ทำให้ย้อนกลับถูกและเร็ว

กับดักทั่วไปที่ทำให้พฤติกรรมพังระหว่างรีแฟกเตอร์

รีแฟกเตอร์ส่วนใหญ่ล้มในเรื่องเล็กๆ น่าเบื่อ UI ยังคงทำงาน แต่กฎระยะหายไป, handler ถูกเรียกสองครั้ง, หรือลิสต์เริ่มสูญเสียโฟกัสขณะพิมพ์ ผู้ช่วยอาจทำให้เรื่องแย่ขึ้นเพราะโค้ดดูสะอาดขึ้นแม้ว่าพฤติกรรมจะไหลออก

สาเหตุทั่วไปคือการเปลี่ยนโครงสร้าง คุณสกัดคอมโพเนนต์แล้วห่อด้วย \u003cdiv\u003e เพิ่ม หรือเปลี่ยน \u003cbutton\u003e เป็น \u003cdiv\u003e ที่คลิกได้ ตัวเลือก CSS, เลย์เอาต์, การนำทางคีย์บอร์ด และ query ในเทสสามารถเปลี่ยนไปโดยที่ไม่มีใครสังเกต

กับดักที่ทำให้พฤติกรรมพังบ่อยที่สุด:\n\n- DOM ที่เปลี่ยนดูเหมือนไม่เป็นไร: wrapper เพิ่มขึ้น, ประเภท element เปลี่ยน, หรือตำแหน่ง attribute ย้าย สามารถทำให้ CSS และเทสพัง เก็บ tag และ data attributes เดิมจนกว่าจะตั้งใจเปลี่ยน\n- ทำลาย referential equality โดยไม่ตั้งใจ: สร้างอ็อบเจ็กต์/ฟังก์ชันใหม่แบบ inline ({} หรือ () => {}) อาจกระตุ้นการเรนเดอร์ซ้ำและรีเซ็ตสเตตลูก ตรวจดู props ที่เคยเสถียร\n- พลาด dependencies ของฮุก: ย้ายตรรกะเข้า useEffect, useMemo, หรือ useCallback อาจทำให้ค่าล้าหรือ loop ถ้า dependencies ผิด หากเอฟเฟกต์เคยทำงาน "on click" อย่าเปลี่ยนให้มันทำงาน "เมื่อไหร่ก็ตามที่มีการเปลี่ยนแปลงใดๆ"\n- ยกระดับพฤติกรรมโดยไม่ได้รับอนุญาต: “แก้” เคสขอบ, เปลี่ยนกฎการเรียง, หรือปรับปรุงการตรวจสอบเป็นการเปลี่ยนโปรดักต์ จงจับพฤติกรรมเดิมไว้ก่อน แม้มันจะแปลก

ตัวอย่าง: แยกคอมโพเนนต์ตารางแล้วเปลี่ยน row keys จาก ID เป็น index ของอาร์เรย์อาจดูปกติ แต่จะทำให้การเลือกพังเมื่อแถวเรียงใหม่ ถือว่า “สะอาด” เป็นโบนัส แต่ “พฤติกรรมเดิม” เป็นข้อบังคับ

เช็คลิสต์ด่วนก่อนเรียกว่าจบ

ก่อนผสาน คุณต้องมีหลักฐานว่าการรีแฟกเตอร์ยังคงพฤติกรรมเดิม สัญญาณที่ง่ายคือ: ทุกอย่างยังทำงานโดยที่คุณไม่ต้อง “แก้” เทส

รันการตรวจสอบด่วนหลังการเปลี่ยนแปลงสุดท้าย:\n\n- เทสเก่าผ่านโดยไม่แก้ใดๆ และ characterization tests ใหม่ผ่านด้วย (ไม่มี snapshot ที่ต้องอัปเดต ไม่มี assertion เปลี่ยน)\n- UI ยังคงมีสถานะที่มองเห็นได้เดิม: loading, empty, error, success และปรากฏในเงื่อนไขเดิม\n- props สาธารณะและสัญญา callbacks คงที่: ชื่อเดิม รูปร่างของอาร์กิวเมนต์เดิม เวลาเรียกเดียวกัน (เช่น onChange ยังคงยิงเมื่อผู้ใช้ป้อน ไม่ใช่ตอน mount)\n- พฤติกรรมโฟกัสและคีย์บอร์ดยังคงรู้สึกเหมือนเดิม: ลำดับ tab, การกด Enter และ Escape, และตำแหน่งโฟกัสหลังการกระทำอย่างบันทึก ปิด หรือแบ่งหน้า\n- analytics และผลข้างเคียงยังเกิดครั้งเดียว ในช่วงเวลาเดียวกันกับก่อน (เช่น หนึ่ง event “Viewed” ต่อการโหลดหน้าหนึ่งครั้ง ไม่ใช่ต่อการเรนเดอร์ซ้ำ)

เช็คลิสต์เร็ว: เปิดคอมโพเนนต์และทำ flow แปลกๆ หนึ่งรอบ เช่น ทำให้เกิดข้อผิดพลาด, retry, แล้วเคลียร์ฟิลเตอร์ รีแฟกเตอร์มักทำพังช่วงเปลี่ยนสถานะแม้เส้นทางหลักจะทำงาน

ถ้ามีรายการใดไม่ผ่าน ให้ย้อนการเปลี่ยนแปลงล่าสุดแล้วทำใหม่เป็นขั้นย่อย นั่นมักเร็วกว่าดีบัก diff ใหญ่

ตัวอย่างสมจริง: แยกคอมโพเนนต์ตารางที่ยุ่ง

นึกภาพคอมโพเนนต์ ProductTable ที่ทำทุกอย่าง: ดึงข้อมูล, จัดการฟิลเตอร์, ควบคุมการแบ่งหน้า, เปิดไดอะล็อกยืนยันการลบ, และจัดการ action แถวอย่าง edit, duplicate, archive มันเริ่มเล็ก แล้วโตเป็นไฟล์ 900 บรรทัด

อาการคุ้นเคย: สเตตกระจัดกระจายอยู่ใน useState หลายตัว, มี useEffect สองสามตัวที่วิ่งในลำดับเฉพาะ และการเปลี่ยน “ดูไม่มีพิษมีภัย” ทำให้การแบ่งหน้าเสียเฉพาะเมื่อฟิลเตอร์ active คนหยุดแตะมันเพราะมันรู้สึกไม่คาดเดาได้

ก่อนเปลี่ยนโครงสร้าง ให้ล็อกพฤติกรรมด้วย characterization tests สองสามตัว โฟกัสที่สิ่งผู้ใช้ทำ ไม่ใช้สเตตภายใน:\n\n- การใช้ฟิลเตอร์จะอัปเดตแถวที่มองเห็นและรีเซ็ตเป็นหน้า 1\n- การแบ่งหน้ารักษาฟิลเตอร์และแสดงจำนวนหน้าถูกต้อง\n- คลิก “Archive” จะปิดใช้งานแถวขณะคำขออยู่ระหว่างการยิง\n- สถานะว่างปรากฏเมื่อไม่มีผลลัพธ์ตรงกับฟิลเตอร์\n- สถานะโหลดไม่กระพริบเป็น “No results”\n ตอนนี้คุณสามารถรีแฟกเตอร์เป็นคอมมิตเล็กๆ แผนการสกัดที่สะอาดอาจเป็น: FilterBar เรนเดอร์คอนโทรลและส่งการเปลี่ยนฟิลเตอร์; TableView เรนเดอร์แถวและ pagination; RowActions เป็นเจ้าของเมนู action และ UI ของไดอะล็อกยืนยัน; และฮุก useProductTable เป็นเจ้าของตรรกะยุ่ง (query params, ข้อมูลอนุพันธ์, และผลข้างเคียง)

ลำดับสำคัญ สกัด UI เพียวๆ ก่อน (TableView, FilterBar) โดยส่ง props ผ่านโดยไม่เปลี่ยนแปลง เก็บส่วนเสี่ยงไว้ทีหลัง: การย้ายสเตตและเอฟเฟกต์เข้า useProductTable เมื่อทำให้รักษาชื่อ prop และรูปแบบ event เดิมเพื่อให้เทสผ่าน ถ้าเทสล้ม แปลว่าคุณเจอการเปลี่ยนพฤติกรรม ไม่ใช่ปัญหาสไตล์

ขั้นตอนถัดไป: ทำให้วิธีนี้ทำซ้ำได้

ถ้าคุณอยากให้การรีแฟกเตอร์คอมโพเนนต์ React ด้วย Claude Code รู้สึกปลอดภัยทุกครั้ง ให้เปลี่ยนสิ่งที่เพิ่งทำเป็นเทมเพลตสั้นๆ ที่ใช้ซ้ำได้ เป้าหมายไม่ใช่กระบวนการเพิ่ม แต่เพื่อลดความประหลาดใจ

เก็บเทมเพลตรำลัดการรีแฟกเตอร์

เขียน playbook สั้นๆ ที่ทำตามได้ในคอมโพเนนต์ใดก็ได้ แม้คุณจะง่วงหรือรีบ:\n\n- ระบุเป้าหมายในประโยคเดียว (อะไรดีขึ้น อะไรห้ามเปลี่ยน)\n- จับพฤติกรรมปัจจุบันด้วย characterization tests (รวมเคสขอบที่แปลก)\n- ทำการเปลี่ยนเล็กๆ หนึ่งอย่าง (สกัด, เปลี่ยนชื่อ, ย้ายสเตต, แยกเอฟเฟกต์)\n- รันเทสและตรวจเช็กด้วยตาใน UI แบบเร็วๆ\n- บันทึกจุดเช็คพอยต์ที่ย้อนกลับได้ถ้าต้องการ

เก็บเป็นสนิปเพ็ตในโน้ตหรือรีโปเพื่อเริ่มรีแฟกเตอร์ถัดไปด้วยราวป้องกันเดียวกัน

ตัดสินใจทำอะไรต่อเมื่อพฤติกรรมถูกล็อก

เมื่อคอมโพเนนต์เสถียรและอ่านง่ายขึ้น ให้เลือกรอบถัดไปตามผลกระทบต่อผู้ใช้ ลำดับทั่วไปคือ: accessibility ก่อน (labels, focus, keyboard), ตามด้วย performance (memoization, การเรนเดอร์หนัก), แล้ว cleanup (types, การตั้งชื่อ, โค้ดตาย) อย่าผสมทั้งสามใน PR เดียว

ถ้าคุณใช้วิธีการ vibe-coding อย่าง Koder.ai (koder.ai), โหมดวางแผนช่วยร่างขั้นตอนก่อนแตะโค้ด และสแนปช็อตกับการย้อนกลับทำหน้าที่เป็นจุดเช็คขณะทดลอง เมื่อเสร็จ การส่งออกซอร์สช่วยให้ง่ายต่อการตรวจทาน diff สุดท้ายและรักษาประวัติให้สะอาด

รู้ว่าเมื่อไหร่ควรหยุดและปล่อย

หยุดรีแฟกเตอร์เมื่อเทสครอบคลุมพฤติกรรมที่คุณกลัวจะทำพัง การหยุดที่ดีคือ:

• เทสครอบคลุมเส้นทางที่คุณกลัวจะทำพัง\n- การเปลี่ยนถัดไปจะเป็นฟีเจอร์หรือการแก้ตัดสินใจเชิงโปรดักต์\n- คุณอยากปรับชื่อ, types, และสถาปัตยกรรมทั้งหมดใน PR เดียว

ปล่อยรีแฟกเตอร์แล้วบันทึกไอเดียที่เหลือเป็น backlog สั้นๆ สำหรับต่อยอดภายหลัง