Refactor code React Native bằng Claude Code

Trả lời nhanh: Dọn code React Native bằng agent hiệu quả khi bạn chia thành nhiều bước nhỏ có thể kiểm chứng, thay vì giao một lần dọn toàn bộ màn hình. Bốn kiểu cho giá trị cao nhất: tách widget quá dài, gom logic gọi dữ liệu ra khỏi phần hiển thị, bỏ trạng thái thừa, và sửa các chỗ tạo lại hàm không cần thiết gây vẽ lại. Điều kiện bắt buộc: có bộ kiểm thử hoặc ít nhất một luồng thử tay cố định để biết mình không làm hỏng gì.

Dự án React Native chạy được vài năm thường có vài màn hình mà không ai muốn động vào: một file dài hai nghìn dòng, trạng thái rải rác, và không ai nhớ vì sao có đoạn kiểm tra kỳ lạ ở giữa. Agent giúp dọn được, nhưng chỉ khi bạn chia việc đúng cách. Bài này nói cách chia đó.

Chuẩn bị lưới an toàn trước

Dọn code mà không có cách biết mình vừa làm hỏng gì là công thức của một tuần khó chịu. Ba mức lưới, có mức nào cũng tốt hơn không có:

• Bộ kiểm thử tự động cho phần logic. Nếu chưa có, hãy để agent viết trước khi dọn, đây là bước đáng bỏ thời gian.
• Kiểm thử giao diện cho các luồng chính, chạy trên máy giả lập theo bài về emulator.
• Luồng thử tay cố định, viết ra thành danh sách bước. Kém nhất trong ba nhưng vẫn hơn nhiều so với thử ngẫu nhiên.

Và tất nhiên là commit sạch trước khi bắt đầu, theo bài về quay lui.

Bốn kiểu refactor cho giá trị cao nhất

Tách widget quá dài. Một file hai nghìn dòng chia thành nhiều thành phần nhỏ theo ranh giới hiển thị. Đây là kiểu an toàn nhất vì không đổi logic, và cũng dễ kiểm chứng nhất.

Gom logic gọi dữ liệu ra khỏi phần hiển thị. Chuyển các lượt gọi mạng và xử lý dữ liệu vào một lớp riêng. Sau bước này, phần hiển thị chỉ nhận dữ liệu và vẽ, nên viết kiểm thử cũng dễ hơn nhiều.

Bỏ trạng thái thừa. Rất nhiều màn hình giữ trạng thái mà thực ra tính được từ trạng thái khác. Mỗi trạng thái thừa là một nguồn lỗi đồng bộ.

Sửa các chỗ gây vẽ lại không cần thiết. Hàm và đối tượng tạo mới ở mỗi lần vẽ khiến thành phần con vẽ lại theo. Trên máy cấu hình thấp, đây là nguyên nhân phổ biến nhất của cảm giác giật khi cuộn.

Chia việc cho agent

Cách giao kém hiệu quả: dọn lại màn hình danh sách đơn hàng cho gọn. Agent sẽ viết lại gần như toàn bộ và bạn không còn cách nào xem lại cho kỹ.

Cách giao tốt hơn, từng bước một:

Bước 1: Tách file screens/Orders.tsx thành các widget con theo ranh giớihiển thị. Không đổi logic, không đổi tên hàm công khai.Sau khi tách, chạy npm test và báo kết quả. Bước 2: Chuyển toàn bộ lượt gọi mạng trong file đó sangservices/orderService.ts theo mẫu của services/userService.ts.Widget chỉ nhận dữ liệu qua props. Bước 3: Liệt kê các state có thể tính từ state khác, chưa sửa gì cả.Tôi sẽ chọn cái nào nên bỏ.

Bước ba đáng chú ý: bắt agent liệt kê trước rồi bạn chọn. Việc bỏ trạng thái là nơi dễ đổi hành vi nhất, nên đừng để nó tự quyết.

Đo hiệu năng cho đúng

Refactor vì hiệu năng mà không đo thì bạn không biết mình có cải thiện gì không. Ba nguyên tắc:

• Đo trên máy cấu hình thấp, vì đó là nơi vấn đề lộ ra. Trên máy mạnh mọi thứ đều mượt và bạn không thấy gì.
• Đo cùng một thao tác trước và sau, ví dụ cuộn một danh sách hai trăm phần tử.
• Chú ý số lần vẽ lại chứ không chỉ cảm giác. Công cụ theo dõi của nền tảng cho biết thành phần nào vẽ lại bao nhiêu lần.

Về danh sách dài, nguyên tắc quan trọng nhất không phải refactor mà là dùng đúng thành phần danh sách có tái sử dụng ô hiển thị. Rất nhiều màn hình giật vì hiển thị hai trăm phần tử cùng lúc trong một khung cuộn thường.

Những gì nên giữ nguyên

Không phải code cũ nào cũng đáng dọn. Ba trường hợp nên để yên:

• Code chạy ổn định và không ai phải sửa. Dọn nó là rủi ro không đổi lấy gì.
• Đoạn xử lý đặc thù có vẻ kỳ lạ nhưng có lý do. Trước khi sửa, hãy tìm xem có ghi chú hay lịch sử commit nào giải thích không. Rất nhiều đoạn code kỳ lạ là cách xử lý một lỗi của một dòng máy cụ thể.
• Phần sắp bị thay thế bởi một tính năng đang làm.

Nguyên tắc chọn: dọn những chỗ bạn sắp phải sửa tiếp. Refactor có giá trị khi nó làm việc tiếp theo dễ hơn, không phải khi nó chỉ làm code trông đẹp hơn.

Ghi lại lý do của những đoạn kỳ lạ mà bạn vừa hiểu ra vào tài liệu trong repo, theo bài về memory. Người sau, kể cả chính bạn, sẽ khỏi phải điều tra lại.

Thứ tự an toàn khi dọn mã của ứng dụng di động

Đảo thứ tự này là nguồn gốc của phần lớn lần dọn mã hỏng. Chuẩn hóa trạng thái khi chưa có lưới kiểm thử là cách nhanh nhất để tạo ra lỗi mà không ai biết xuất hiện lúc nào.

Ba chỗ riêng của ứng dụng di động cần cẩn thận

• Vòng đời màn hình: mã dọn dẹp khi màn hình bị hủy rất dễ bị bỏ sót lúc tách hàm. Rò rỉ bộ nhớ chỉ lộ ra sau khi người dùng chuyển màn hình vài chục lần.
• Mã riêng cho từng hệ điều hành: nhánh xử lý riêng thường nằm rải rác. Gom lại thì tốt, nhưng phải chạy thử trên cả hai nền chứ không chỉ nền bạn đang mở.
• Danh sách dài: phần vẽ danh sách thường được tối ưu bằng những đoạn mã trông thừa. Xóa chúng đi làm ứng dụng giật trên máy yếu, mà máy phát triển thì không lộ ra.

Cách bắt lỗi trước khi lên bản phát hành

# Truoc khi don ma: ghi lai trang thai hien taigit checkout -b don-ma-thang-9git log --oneline -1   # ghi lai ma bam nay de con quay ve # Sau moi buoc don: chay day du chu khong chi chay thu mot man hinhnpm testnpx tsc --noEmit        # neu du an co chu thich kieu # Chay tren MAY THAT, khong chi may ao:#  - mot may cau hinh thap#  - mot may moi# Nhieu loi hieu nang chi lo ra tren may yeu # Truoc khi gop nhanh: xem lai toan bo thay doi mot luotgit diff main --stat

Khi nào nên dừng lại

Nếu một lần dọn mã đã chạm quá hai chục tệp mà chưa gộp được nhánh, hãy dừng và gộp phần đang chạy ổn trước. Nhánh dọn mã sống lâu là nhánh sẽ xung đột với mọi thay đổi khác trong đội. Chia thành nhiều lần nhỏ chậm hơn về cảm giác nhưng nhanh hơn về tổng thời gian.