𝗙𝗿𝗼𝗺 𝗤𝗔 𝘁𝗼 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁

Các trình soạn thảo mã nguồn AI hiện nay có thể xử lý hầu hết các đoạn mã mẫu (boilerplate). Điều này tạo ra một lầm tưởng nguy hiểm. Các đội ngũ nghĩ rằng nếu AI viết mã và nó biên dịch được, thì nó sẽ hoạt động.

Tư duy này có thể hiệu quả với các tính năng nhỏ, nhưng sẽ thất bại đối với các hệ thống thiết kế (design systems).

Một thành phần trong hệ thống thiết kế không phải là một tính năng dùng một lần. Nó là cơ sở hạ tầng. Một nút bấm hay một trường nhập liệu sẽ phục vụ hàng triệu người dùng trên hàng trăm sản phẩm khác nhau.

Lợi thế thực sự không nằm ở việc bạn viết mã nhanh đến mức nào, mà là ở khả năng bạn dự đoán các lỗi có thể xảy ra tốt đến đâu.

Bạn phải chuyển từ tư duy của một người xây dựng (builder) sang tư duy của một người phá vỡ (breaker). Bạn cần áp dụng kiểm thử thông qua TDD, BDD và Phát triển dựa trên đặc tả (Spec-Driven Development).

Hầu hết các đội ngũ đều xây dựng dựa trên "Happy Path" (kịch bản lý tưởng). Họ chỉ cần khớp với tệp Figma là dừng lại. Nhưng các thành phần phải tồn tại được trong sự hỗn loạn của thế giới thực.

Một đội ngũ mạnh mẽ sẽ đặt ra những câu hỏi hóc búa trước khi viết mã:

• Designer: Điều gì sẽ xảy ra nếu một chuỗi văn bản dài tới 400 ký tự? Giao diện (UI) có bị vỡ không?
• Engineer: Điều gì sẽ xảy ra nếu người dùng nhấn vào một nút gạt mười lần mỗi giây? Trạng thái (state) có bị lỗi không?
• Khả năng tiếp cận (Accessibility): Trình đọc màn hình sẽ xử lý menu thả xuống này như thế nào nếu chỉ sử dụng bàn phím?

Các công cụ AI giỏi viết mã nhưng lại kém trong việc đưa ra các giả định. Chúng tạo ra các thành phần dễ vỡ (brittle).

Hãy sử dụng quy trình làm việc này để bảo vệ thành quả của bạn:

1. Xác định đặc tả (Tokens, Accessibility, API).
2. Viết các bài kiểm thử (tests) và câu chuyện (stories) trước để thiết lập các ranh giới.
3. Sử dụng AI để tạo mã trong phạm vi các ranh giới đó.

TDD đảo ngược quy trình này. Thay vì sửa lỗi sau đó, bạn xác định các ranh giới ngay từ đầu. Sau đó, AI sẽ viết mã để đáp ứng các bài kiểm thử đó.

Phát triển hướng hành vi (BDD) cũng giúp ích rất nhiều. Nó sử dụng ngôn ngữ tự nhiên để thu hẹp khoảng cách giữa thiết kế và kỹ thuật.

Ví dụ:

• Giả sử người dùng có kết nối mạng chậm,
• Khi họ nhấn nút gửi (submit),
• Thì nút bấm phải hiển thị trạng thái đang tải (loading state) và vô hiệu hóa các lần nhấp chuột.

Một số nhà lãnh đạo lo ngại rằng việc kiểm thử sẽ làm chậm tốc độ. Đây là một sai lầm.

Việc viết mã ban đầu chỉ chiếm 5% chi phí của một thành phần. 95% còn lại dành cho việc bảo trì và sửa lỗi.

Tư duy kiểm thử mang lại cho bạn:

• Ít lỗi hồi quy (regressions) hơn khi bạn tái cấu trúc mã (refactor).
• Một hệ thống tự phục vụ cho các nhà phát triển khác.
• Sự tin tưởng trong tổ chức.

Trong thế giới AI, tốc độ viết mã là điều phổ biến. Tư duy hệ thống mới là điều hiếm có.

Đừng cố gắng xây dựng nhanh hơn. Hãy bắt đầu xây dựng để sẵn sàng đối mặt với sự cố.

Đội ngũ của bạn cân bằng giữa tốc độ và khả năng chống chịu (resilience) như thế nào? Hãy cho tôi biết ở phần bình luận nhé.

Từ QA đến Kiến trúc sư Thành phần: Tại sao việc phá vỡ mã nguồn lại là bí quyết để tạo ra các hệ thống thiết kế đẳng cấp thế giới

Tôi đã dành nhiều năm làm kỹ sư QA (Đảm bảo Chất lượng), và nếu có một điều tôi học được, thì đó là: cách tốt nhất để xây dựng một thứ gì đó bền vững là cố gắng phá hủy nó.

Khi chuyển từ vai trò QA sang Kiến trúc sư Thành phần (Component Architect), tôi nhận ra rằng tư duy "phá vỡ" này không chỉ là một kỹ năng kiểm thử, mà còn là một siêu năng lực trong việc thiết kế các hệ thống thiết kế (design systems) đẳng cấp thế giới.

Tư duy QA: Nghệ thuật của sự phá hủy

Công việc của một QA là tìm ra những điểm yếu, những lỗ hổng và những kịch bản mà lập trình viên có thể đã bỏ qua. Chúng tôi không hỏi "Nó hoạt động như thế nào?", chúng tôi hỏi "Nó sẽ hỏng như thế nào?".

Khi bạn áp dụng tư duy này vào việc xây dựng các thành phần (components), bạn không còn chỉ xây dựng những gì "đúng" nữa. Bạn bắt đầu xây dựng những gì "không thể sai".

Trường hợp biên (Edge Cases): Sân chơi của Kiến trúc sư

Một kiến trúc sư thành phần giỏi không chỉ tập trung vào "happy path" (luồng hoạt động lý tưởng). Họ dành phần lớn thời gian để suy nghĩ về các trường hợp biên (edge cases):

• Điều gì xảy ra nếu prop này bị null?
• Điều gì xảy ra nếu dữ liệu trả về từ API không đúng định dạng?
• Điều gì xảy ra nếu người dùng nhấn nút liên tục 10 lần trong một giây?
• Điều gì xảy ra nếu thành phần này được render trong một container có kích thước bằng 0?

Bằng cách dự đoán những kịch bản này ngay từ giai đoạn thiết kế, bạn có thể tạo ra các thành phần có khả năng phục hồi (resilient) và không làm sập toàn bộ ứng dụng.

Xây dựng sự bền vững (Resilience) thay vì chỉ là tính năng

Trong thiết kế hệ thống, sự khác biệt giữa một hệ thống trung bình và một hệ thống đẳng cấp thế giới nằm ở khả năng chịu lỗi (fault tolerance).

Một hệ thống thiết kế tốt không chỉ cung cấp các nút bấm đẹp mắt; nó cung cấp các thành phần có khả năng xử lý lỗi một cách thanh lịch. Thay vì để ứng dụng bị "crash" trắng màn hình, một thành phần được thiết kế tốt sẽ hiển thị một trạng thái lỗi (error state) hoặc một giá trị mặc định (fallback) một cách mượt mà.

Từ Phản ứng sang Chủ động

Sự chuyển đổi từ QA sang Kiến trúc sư Thành phần thực chất là sự chuyển đổi từ việc phản ứng với lỗi sang việc chủ động ngăn chặn lỗi.

Thay vì đợi đến khi lỗi xảy ra trong môi trường production để sửa chữa, bạn sử dụng tư duy phá vỡ để xây dựng các rào chắn (guardrails) ngay trong mã nguồn. Điều này bao gồm:

• Sử dụng TypeScript để kiểm soát chặt chẽ kiểu dữ liệu.
• Thiết lập các PropTypes hoặc schema validation.
• Xây dựng các thành phần bao bọc (wrapper components) để xử lý các lỗi không mong muốn.

Kết luận

Đừng sợ việc phá vỡ mã nguồn của mình. Hãy coi đó là một phần của quá trình sáng tạo. Khi bạn học cách phá vỡ những thứ bạn xây dựng, bạn sẽ học được cách xây dựng chúng một cách vững chắc hơn, linh hoạt hơn và chuyên nghiệp hơn.

Đó chính là bí quyết để chuyển từ một người chỉ biết viết code sang một kiến trúc sư thực thụ.