Cách xác minh bằng chứng về một vấn đề

Xác định chính xác vấn đề cần xác minh

Trước tiên cần chuyển “vấn đề” thành một mệnh đề có thể kiểm tra. Ví dụ, thay vì ghi “callback bị lỗi”, nên xác định rõ điều cần chứng minh là callback có được gọi hay không, được gọi ở thời điểm nào và điều kiện nào khiến nó không được gọi.

Một claim tốt nên xác định được:

·         Đối tượng nào đang được kiểm tra

·         Hiện tượng nào được cho là xảy ra

·         Điều kiện nào áp dụng

·         Dữ liệu nào có thể chứng minh hoặc bác bỏ

·         Kết luận sẽ thay đổi thế nào nếu dữ liệu trái ngược

Cách đặt vấn đề này giúp tránh nhầm giữa quan sát và giải thích. Một log, một giá trị runtime hoặc một đoạn mã cho thấy hiện tượng xảy ra chưa nhất thiết chứng minh nguyên nhân của hiện tượng đó.

Kiểm tra nguồn dữ liệu trước khi chấp nhận bằng chứng

Không phải dữ liệu nào cũng có giá trị chứng minh như nhau. Evidence cần được chọn theo câu hỏi mà nó phải trả lời. Các loại thường được sử dụng gồm bằng chứng khoa học, thực nghiệm, thống kê, kỹ thuật, quy định, so sánh, case evidence và ví dụ thực tế.

Có thể kiểm tra nguồn theo ba lớp:

1.    Nguồn gốc: Dữ liệu đến trực tiếp từ hệ thống, tài liệu kỹ thuật, tiêu chuẩn, nghiên cứu hoặc quan sát thực tế nào

2.    Độ phù hợp: Nguồn đó có thực sự chứng minh claim đang xét hay chỉ nói về một vấn đề gần giống

3.    Khả năng kiểm chứng: Người khác có thể kiểm tra lại dữ liệu, điều kiện đo hoặc phương pháp tạo ra bằng chứng hay không

Nguồn có thẩm quyền cũng phải gắn với claim cụ thể. Một authority chỉ được xem là hữu ích khi nó hỗ trợ việc chứng minh, giải thích cơ chế, xác lập tiêu chuẩn, benchmark hoặc giới hạn của kết luận.

Đối chiếu nhiều bằng chứng để kiểm tra tính nhất quán

Một vấn đề đáng tin cậy hơn khi các bằng chứng độc lập cùng chỉ về một kết luận. Tuy nhiên, “nhiều nguồn nói giống nhau” chưa đủ nếu tất cả đều lấy dữ liệu từ cùng một nguồn ban đầu.

Nên đối chiếu theo quan hệ:

Dữ liệu gốc → Quan sát → Giải thích → Kết luận

Nếu hai nguồn mâu thuẫn, không nên chọn ngay nguồn phù hợp với giả thuyết ban đầu. Cần tìm nguyên nhân khác biệt, chẳng hạn:

·         Khác phiên bản dữ liệu hoặc phần mềm

·         Khác điều kiện thực nghiệm

·         Khác thời điểm đo

·         Khác cách định nghĩa biến hoặc chỉ số

·         Một nguồn mô tả hiện tượng, nguồn kia mô tả nguyên nhân

·         Một kết luận chỉ đúng trong một điều kiện nhất định

Tính nhất quán vì thế không có nghĩa mọi nguồn phải giống hệt nhau. Điều cần kiểm tra là các nguồn có mâu thuẫn về cùng một mệnh đề trong cùng điều kiện hay không.

Phân biệt bằng chứng trực tiếp với suy luận

Đây là bước quan trọng nhất khi xác minh vấn đề kỹ thuật. Một chuỗi suy luận có thể hợp lý nhưng vẫn chưa phải bằng chứng trực tiếp.

Chẳng hạn, nếu một hàm có một nhánh NULL check, có thể suy ra rằng chương trình xử lý trường hợp con trỏ rỗng. Nhưng muốn xác minh một callback thực sự có chạy hay không, cần kiểm tra đường thực thi tương ứng thay vì chỉ suy luận từ mã nguồn hoặc tên hàm.

Trong tài liệu kỹ thuật được cung cấp, việc xác minh callback được đặt theo hướng disassembly và trace runtime thay vì suy luận, bao gồm kiểm tra đích branch, trạng thái runtime, prototype, layout object và vị trí delegate được tạo.

Nguyên tắc tổng quát là:

Nếu claim nói về hành vi thực tế, bằng chứng nên quan sát được hành vi thực tế.

Nếu claim nói về cấu trúc, có thể dùng cấu trúc mã hoặc tài liệu kỹ thuật. Nếu claim nói về runtime behavior, cần thêm bằng chứng runtime phù hợp. Không nên dùng bằng chứng ở một lớp để khẳng định chắc chắn một thuộc tính chỉ có thể quan sát ở lớp khác.

Kiểm tra điều kiện và giới hạn của kết luận

Một kết luận đúng trong điều kiện A chưa chắc đúng trong điều kiện B. Vì vậy xác minh không chỉ hỏi “có bằng chứng không?” mà còn phải hỏi:

·         Bằng chứng được tạo trong điều kiện nào

·         Điều kiện đó có giống tình huống đang xét không

·         Có ngoại lệ nào không

·         Kết luận có áp dụng cho toàn bộ trường hợp hay chỉ một phạm vi hẹp

·         Mức độ chắc chắn của bằng chứng là đến đâu

Một kết luận quan trọng cần có cả WHY, PROOF và BOUNDARY: tại sao nó đúng, bằng chứng nào hỗ trợ và khi nào kết luận không còn đúng. Đây cũng là yêu cầu được đặt ra trong khung xác thực claim của quy trình nội dung.

Nếu chưa xác định được boundary, nên dùng ngôn ngữ phản ánh đúng mức độ chắc chắn thay vì biến một quan sát có điều kiện thành kết luận tuyệt đối.

Xác minh vấn đề theo chuỗi bằng chứng hoàn chỉnh

Một quy trình thực tế có thể đi theo sáu bước:

1.    Định nghĩa claim: Viết chính xác điều cần chứng minh hoặc bác bỏ

2.    Xác định dữ liệu cần thiết: Xác định quan sát nào có thể phân biệt giữa các giả thuyết

3.    Kiểm tra nguồn: Đánh giá nguồn gốc, độ tin cậy và mức phù hợp của dữ liệu

4.    Đối chiếu: So sánh với bằng chứng độc lập hoặc bằng chứng ở lớp khác

5.    Kiểm tra điều kiện: Xác định phạm vi, ngoại lệ và điều kiện làm thay đổi kết luận

6.    Kết luận theo mức bằng chứng: Chỉ khẳng định ở mức mà dữ liệu thực sự hỗ trợ

Nếu bằng chứng chưa đủ, kết luận phù hợp không phải là “vấn đề đã được xác minh”, mà là chưa đủ bằng chứng để xác minh. Kiến trúc bằng chứng cũng yêu cầu mỗi Core Answer có Evidence tương ứng và các Evidence phải được phân bổ theo vai trò chứng minh, giải thích cơ chế hoặc xác lập boundary.

Tóm lại, xác minh vấn đề không phải là tìm một nguồn xác nhận giả thuyết có sẵn. Đó là quá trình nối claim → dữ liệu → nguồn → đối chiếu → điều kiện → kết luận sao cho mỗi bước đều có cơ sở kiểm tra được. Khi hành vi cần xác minh là hành vi runtime hoặc hành vi kỹ thuật cụ thể, bằng chứng quan sát trực tiếp thường có giá trị hơn suy luận chỉ dựa trên cấu trúc hoặc tên gọi.