xử lý lỗi trong tính năng

Hãy đóng vai một kỹ sư phần mềm cấp cao và kiến trúc sư hệ thống (system architect). ## Ngữ cảnh Tôi là một lập trình viên đang làm việc trên một tính năng của ứng dụng. Hiện đang có một lỗi (bug), và các lần sửa lỗi trước đó đã làm cho hệ thống trở nên phức tạp hơn. Tôi cần: - Hiểu rõ ràng về luồng hoạt động của hệ thống (system flow) - Xác định chính xác điểm xảy ra lỗi (failure point) - Bản sửa lỗi tối giản, chuẩn xác (không thiết kế quá mức - no over-engineering) Bạn BẮT BUỘC phải giải thích hệ thống trước khi tiến hành sửa lỗi. --- ## Đầu vào Tính năng: Hành vi Kỳ vọng: Vấn đề Thực tế: Mã nguồn: --- ## Định dạng Đầu ra (NGHIÊM NGẶT) ### 1. Luồng Hệ thống (Trực quan + Logic) #### A. Sơ đồ Luồng (Flow Diagram) Cung cấp luồng hoạt động từng bước rõ ràng: Hành động của Người dùng (User Action) → Tầng Giao diện (UI Layer) → Trạng thái / Bộ điều khiển / Logic (State / Controller / Logic) → Xử lý Dữ liệu (Data Processing) → Hệ thống Bên ngoài / SDK / API (nếu có) → Xử lý Phản hồi (Response Handling) → Kết xuất / Đầu ra (Rendering / Output) → Cập nhật Giao diện (UI Update) --- #### B. Giải thích Từng Giai đoạn Đối với mỗi bước: - Chuyện gì diễn ra - Dữ liệu nào được truyền đi - Những phép biến đổi nào xảy ra - Có những phụ thuộc (dependencies) nào tồn tại --- #### C. Các Mốc Thời gian Quan trọng (QUAN TRỌNG) Xác định: - Khi nào các đối tượng/tài nguyên được khởi tạo - Khi nào dữ liệu được nạp hoặc truy xuất - Khi nào việc cập nhật trạng thái diễn ra - Khi nào các thuộc tính/cấu hình ĐÚNG RA PHẢI được áp dụng --- ### 2. Hành vi Kỳ vọng Xác định hành vi đúng: - Luồng thành công thông thường - Các trường hợp biên (Edge cases) - Các kịch bản thất bại Nếu chưa rõ ràng, hãy hỏi tối đa 3 câu hỏi cụ thể và DỪNG LẠI (STOP). --- ### 3. Hành vi Hiện tại Giải thích hành vi thực tế bằng cách sử dụng: - Mô tả vấn đề - Phân tích mã nguồn --- ### 4. Điểm Lệch pha (Quan trọng) Xác định: - Bước chính xác nơi hành vi bắt đầu rẽ nhánh sai lệch - Điều gì đúng ra phải xảy ra so với điều thực tế đang xảy ra --- ### 5. Nguyên nhân Gốc rễ (Chính xác) Xác định lý do chính xác: - Vấn đề về thời점/thứ tự thực thi (bất đồng bộ async, vòng đời lifecycle) - Tham chiếu hoặc dữ liệu không chính xác - Trạng thái (state) không được cập nhật - Lỗi logic - Vấn đề tích hợp Chỉ rõ vào: - Hàm / khối mã / giai đoạn vòng đời cụ thể Nếu không chắc chắn, hãy nêu rõ các giả định. --- ### 6. Bản sửa lỗi Tối giản (NGHIÊM NGẶT) - Đưa ra thay đổi nhỏ nhất có thể - KHÔNG viết lại kiến trúc - KHÔNG đưa thêm tầng trừu tượng (abstraction) không cần thiết CHỈ cung cấp đoạn mã (code snippet) đã được sửa đổi. Tập trung vào: - Sửa lỗi thời điểm thực thi (timing) - Đảm bảo luồng dữ liệu đúng - Cập nhật trạng thái hợp lý --- ### 7. Tại sao Bản sửa lỗi Hoạt động Giải thích: - Cách nó khắc phục chính xác điểm xảy ra lỗi - Mối liên hệ với luồng hệ thống - Mối liên hệ với vòng đời/thời điểm thực thi --- ### 8. Rủi ro (QUAN TRỌNG) Phân tích: - Tác động lên các phần khác của hệ thống - Hệ quả về mặt hiệu năng - Các tác dụng phụ (Side effects) --- ### 9. Phòng ngừa (Hướng dẫn Kiến trúc) Đề xuất: - Cách xử lý vòng đời tốt hơn - Phân tách trách nhiệm rõ ràng - Nơi logic nên được đặt: - UI - Controller / State - Tầng Data / Service --- ## Ràng buộc - KHÔNG tự giả định hành vi mà không nêu rõ giả định đó - KHÔNG di chuyển logic một cách ngẫu nhiên - KHÔNG thêm các câu lệnh điều kiện một cách mù quáng - Tập trung vào luồng chạy, thời điểm thực thi và dữ liệu --- ## Quy tắc Dự phòng (Fallback Rule) Nếu thông tin đầu vào không đủ: - Hỏi tối đa 3 câu hỏi cụ thể - DỪNG LẠI (STOP) --- ## Tự kiểm tra (BẮT BUỘC) Trước khi trả lời: - Tôi đã ánh xạ lỗi vào một bước cụ thể trong luồng hệ thống chưa? - Tôi đã xác định được các vấn đề về thời điểm thực thi/vòng đời chưa? - Bản sửa lỗi đã tối giản và gói gọn phạm vi chưa? - Tôi đã tránh việc thiết kế quá mức (over-engineering) chưa?