Xử lý lỗi (bug) trong tính năng

Hãy đóng vai một kỹ sư Flutter cấp cao + chuyên gia hệ thống bản đồ/GIS (SDK tương tự như ArcGIS). ## Ngữ cảnh Tôi là một nhà phát triển không chuyên về kỹ thuật (non-technical developer) đang sử dụng AI để xây dựng một ứng dụng dựa trên bản đồ (Flutter + Map SDK). Tính năng này liên quan đến: - Kết xuất bản đồ (Map rendering) - Tải lớp bản đồ (Layer loading) - Áp dụng thuộc tính động (kiểu dáng / hành vi) Hiện đang có một lỗi (bug), và những lần sửa lỗi trước đó của AI đã làm cho hệ thống trở nên phức tạp hơn. Tôi KHÔNG hiểu rõ: - Cách Map SDK xử lý các lớp (layers) ở bên trong nội bộ - Thời điểm các thuộc tính được áp dụng (trước hay sau khi kết xuất) - Luồng dữ liệu đầy đủ xuyên suốt từ UI → logic → SDK Bạn BẮT BUỘC phải giải thích hệ thống thật rõ rà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: Sự cố Thực tế: Mã nguồn: --- ## Định dạng Đầu ra (NGHIÊM NGẶT) ### 1. Luồng Hệ thống Bản đồ (Trực quan + Đặc thù theo Lớp) #### A. Sơ đồ Luồng (Flow Diagram) Cung cấp một sơ đồ luồng thực tế dựa trên tính năng và mã nguồn đã cho, thể hiện: - Thao tác của người dùng - Lớp giao diện người dùng (UI layer) - Xử lý tại bộ điều khiển / trạng thái (Controller/state handling) - Khởi tạo lớp bản đồ (Layer creation) - Tương tác với SDK - Áp dụng thuộc tính (Property application) - Kết xuất (Rendering) - Cập nhật giao diện (UI update) --- #### B. Giải thích Từng Giai đoạn Giải thích rõ ràng: - Điều gì xảy ra ở từng bước - Dữ liệu nào được truyền giữa các lớp - Nhiều khả năng SDK đang làm gì ở bên trong nội bộ --- #### C. Các Mốc Thời gian Quan trọng (QUAN TRỌNG) Xác định: - Thời điểm lớp bản đồ được tạo ra - Thời điểm dữ liệu được tải xong từ nguồn - Thời điểm các thuộc tính LẼ RA NÊN được áp dụng tương ứng với vòng đời (lifecycle) của SDK --- ### 2. Hành vi Kỳ vọng (Đặc thù cho Bản đồ) Xác định hành vi kỳ vọng dựa trên thông tin đầu vào: - Tải lớp bản đồ thành công - Áp dụng thuộc tính chính xác - Các kịch bản lỗi (đầu vào không hợp lệ, thiếu dữ liệu, lỗi từ phía SDK) 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. --- ### 3. Hành vi Hiện tại Giải thích những gì thực sự đang diễn ra bằng cách sử dụng: - Mô tả sự cố được cung cấp - Đoạn mã nguồn đã cho --- ### 4. Điểm Lệch pha (Quan trọng) Xác định chính xác: - Điểm nào hành vi kỳ vọng khác biệt so với hành vi thực tế - Bước nào trong luồng đang bị lỗi --- ### 5. Nguyên nhân Gốc rễ (Chính xác) Xác định lý do chính xác gây ra lỗi: - Vấn đề về thời điểm thực thi (Timing issue) - Tham chiếu sai lớp bản đồ (Incorrect layer reference) - Trạng thái (State) không được cập nhật - Vấn đề xử lý bất đồng bộ (Async handling issue) Chỉ rõ hàm, khối lệnh hoặc giai đoạn vòng đời cụ thể trong mã nguồn. Nếu không chắc chắn, hãy nêu rõ các giả định của bạn. --- ### 6. Bản Sửa lỗi Tối thiểu (NGHIÊM NGẶT) - Đưa ra thay đổi nhỏ nhất có thể - KHÔNG viết lại toàn bộ hệ thống - CHỈ cung cấp đoạn mã nguồn đã được sửa đổi Tập trung vào: - Sửa lại thời điểm thực thi (timing) - Hiệu chỉnh luồng dữ liệu - Sửa việc cập nhật trạng thái --- ### 7. Tại sao Bản Sửa lỗi Hoạt động Giải thích cách bản sửa lỗi giải quyết được vấn đề: - Liên kết nó với luồng hệ thống - Liên kết nó với hành vi của SDK - Liên kết nó với thời điểm thực thi / vòng đời --- ### 8. Rủi ro Đặc thù của Bản đồ (QUAN TRỌNG) Phân tích: - Tác động đến các lớp bản đồ khác - Hệ quả về mặt hiệu năng - Các vấn đề kết xuất lại (re-render) có thể phát sinh --- ### 9. Phòng ngừa (Kiến trúc Bản đồ) Đề xuất các cải tiến: - Xử lý vòng đời lớp bản đồ tốt hơn - Đặt logic thuộc tính vào đúng vị trí: - Lớp cấu hình (Config layer) - Bộ kết xuất (Renderer) - Bộ điều khiển (Controller) --- ## Ràng buộc - KHÔNG tự giả định hành vi của SDK 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 thời điểm thực thi và luồng 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 và chờ người dùng làm rõ --- ## Tự Kiểm tra (Self-Check) Trước khi trả lời: - Tôi đã ánh xạ lỗi vào một bước cụ thể trong luồng chưa? - Tôi đã xác định được vấn đề về thời điểm thực thi (timing) nếu có chưa? - Bản sửa lỗi đã tối thiểu và giới hạn đúng phạm vi chưa? - Tôi đã tránh được việc thiết kế phức tạp hóa quá mức (over-engineering) chưa?