Lỗ hổng & Sự an toàn: Type Soundness vs Completeness

Một trong những câu hỏi thường gặp nhất của các lập trình viên Senior khi chuyển từ Haskell hoặc Rust sang TypeScript là: "Tại sao compiler lại để lỗi này lọt qua?". Để trả lời, bạn cần hiểu hai khái niệm: Soundness (Độ tin cậy) và Completeness (Tính đầy đủ).

1. Soundness là gì?

Một hệ thống kiểu được gọi là Sound (Tin cậy) nếu nó đảm bảo rằng chương trình sẽ không bao giờ rơi vào trạng thái không hợp lệ tại thời điểm runtime (ví dụ: gọi một hàm không tồn tại).

Hầu hết các ngôn ngữ học thuật (như Haskell) ưu tiên Soundness tuyệt đối. TypeScript thì không.

Triết lý của TS: "Cung cấp sự cân bằng giữa tính hữu dụng và tính đúng đắn."

Ví dụ về sự "Không an toàn" (Unsoundness) có chủ đích:

Trong TS, bạn có thể gán một array con cho một array cha (Covariance), dù điều này có thể dẫn đến lỗi runtime nếu bạn modify array đó.

### Lab: Thử nghiệm Unsoundness
Hãy chạy mã dưới đây để thấy cách TS cho phép một lỗi logic tiềm ẩn để giữ cho việc lập trình trở nên linh hoạt hơn.

```typescript-sandbox:Lab: Subtle Unsoundness
interface Animal { name: string; }
interface Dog extends Animal { bark(): void; }

const dogs: Dog[] = [{ name: "Rex", bark: () => console.log("Gâu!") }];
const animals: Animal[] = dogs; // TS cho phép! (Unsound)

// animals.push({ name: "Cat" }); 
// Nếu uncomment dòng trên, dogs[1].bark() sẽ crash vì dogs thực tế chứa một con mèo!

console.log("Dogs count:", dogs.length);

2. Tại sao TS không chọn "Soundness" tuyệt đối?

Để đạt được Soundness tuyệt đối, TypeScript sẽ phải:

1. Cấm sử dụng any.
2. Bắt buộc kiểm tra null/undefined ở khắp mọi nơi (thời điểm ban đầu).
3. Cấm các kỹ thuật ép kiểu (Type Assertions).

Điều này sẽ làm cho việc di chuyển từ JavaScript thuần sang TypeScript trở nên cực kỳ đau đớn và gần như bất khả thi đối với các dự án lớn.

3. Completeness (Tính đầy đủ)

Một hệ thống kiểu được coi là Complete nếu nó có thể biểu thị được tất cả các chương trình đúng.

Vì JavaScript quá linh hoạt (Dynamic), không có một hệ thống kiểu tĩnh nào có thể bao phủ 100% các pattern của JS mà không trở nên cực kỳ phức tạp. TS chấp nhận bỏ qua một số lỗi (giảm Soundness) để tăng tính linh hoạt và dễ dùng.

4. Bảng so sánh triết lý

5. Senior Mindset: Quản lý rủi ro

Là một Senior, bạn không nên tin tưởng compiler 100%. Bạn cần biết nơi nào TS "buông tay":

1. Type Assertions (as T): Bạn đang nói với compiler "Tôi biết rõ hơn bạn". Đây là nơi Soundness biến mất hoàn toàn.
2. Function Parameter Bivariance: TS cho phép gán các hàm có tham số không hoàn toàn khớp nhau để hỗ trợ các pattern Event Handling phổ biến.
3. Array Access: Truy cập arr[100] khi mảng chỉ có 2 phần tử sẽ trả về undefined, nhưng TS mặc định coi nó là kiểu phần tử của mảng (trừ khi bật noUncheckedIndexedAccess).

// Bật strict mode trong tsconfig.json là cách tốt nhất để 
// đẩy TS về phía Soundness nhiều hơn.
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

Tình huống thực tế & Phỏng vấn

Scenario: Xử lý dữ liệu từ API không tin cậy

Bối cảnh: Bạn gọi API lấy thông tin Profile. API trả về any (hoặc bạn gán nó là any). Bạn truy cập profile.is_verified nhưng runtime thực tế API trả về isVerified.

Vấn đề: Do TS không có Soundness tuyệt đối khi làm việc với dữ liệu bên ngoài, compiler không báo lỗi nhưng ứng dụng bị crash hoặc hiển thị sai logic ở người dùng.

Giải pháp Senior: Sử dụng Type Guards hoặc thư viện Zod để runtime validation ngay tại cửa ngõ API.

import { z } from 'zod';
const ProfileSchema = z.object({ isVerified: z.boolean() });
// parse sẽ quăng lỗi ngay lập tức nếu dữ liệu không khớp, thay vì để lỗi lọt sâu vào UI
const profile = ProfileSchema.parse(apiResponse);

Interview Question: Senior Level

Q: Tại sao TypeScript lại cho phép gán một string cho biến kiểu any, nhưng lại không trực tiếp cho phép gán kiểu unknown cho string mà không kiểm tra? Điều này liên quan gì đến tính toán rủi ro trong Soundness?

Tổng kết

TypeScript không cố gắng trở thành một ngôn ngữ toán học hoàn hảo. Nó cố gắng trở thành một công cụ kỹ thuật hiệu quả nhất để giảm thiểu lỗi trong thế giới hỗn loạn của JavaScript. Hiểu được sự thỏa hiệp này giúp bạn viết code thực tế hơn và biết khi nào cần thêm các kiểm tra runtime thủ công.