Top 5 tiện ích mở rộng VS Code dành cho nhà phát triển năm 2026

Tôi đã dùng VS Code từ khi nó còn có tên là "Code - OSS". Hệ sinh thái tiện ích mở rộng là lý do chính khiến tôi gắn bó với nó. Hàng năm, tôi kiểm tra lại các tiện ích đã cài đặt và loại bỏ những cái tôi không thực sự dùng. Năm tiện ích này đã sống sót qua mọi đợt thanh lọc.

1. GitHub Copilot

Cái hiển nhiên nhất. Tôi đã hoài nghi khi nó ra mắt (tôi từng dùng các công cụ tự động hoàn thành và thấy chúng gây xao nhãng hơn là hữu ích). Copilot khác biệt vì nó tạo ra các khối mã, chứ không chỉ các dòng đơn lẻ. Viết một chữ ký hàm và một bình luận, nó sẽ tạo ra phần thân hàm. Một nửa số lần, phần thân hàm đúng và tôi tiếp tục công việc. Nửa còn lại, nó là một điểm khởi đầu nhanh hơn để chỉnh sửa so với việc viết từ đầu.

Bí quyết là coi nó như một lập trình viên cặp đôi gõ nhanh nhưng không biết codebase của bạn. Hãy xem xét kỹ những gì nó tạo ra. Giữ các giao diện của bạn hẹp để nó ít có cơ hội tạo ra những thứ vô nghĩa.

2. ESLint

Tôi không còn nghĩ về ESLint nữa. Nó chỉ ở đó, báo hiệu các biến chưa định nghĩa trước khi chúng trở thành lỗi runtime, thực thi việc import nhất quán, bắt những loại lỗi nhỏ nhặt nhưng khó chịu. Cấu hình duy nhất tôi quan tâm là "source.fixAll.eslint": true khi lưu: nó tự động sửa bất cứ điều gì ESLint có thể sửa mà không cần hỏi.

3. Prettier

Giá trị của Prettier không nằm ở việc nó thực thi kiểu dáng nào. Mà là chỉ có một kiểu dáng duy nhất được thực thi, tự động, mỗi khi tôi lưu. Không có tranh cãi về dấu phẩy cuối dòng hay dấu nháy đơn trong code review. Cuộc tranh cãi đã kết thúc khi chúng tôi đưa "editor.defaultFormatter": "esbenp.prettier-vscode" vào cài đặt của nhóm.

4. GitLens

Tôi dùng GitLens chủ yếu cho các chú thích blame nội tuyến của nó. Di chuột qua một dòng, bạn sẽ thấy ai đã viết nó và khi nào. Nghe có vẻ nhỏ nhặt cho đến khi bạn đang nhìn chằm chằm vào một đoạn mã khó hiểu và cần biết liệu nó được viết bởi một người vẫn còn trong nhóm hay bởi một thực tập sinh ba năm trước. Chế độ xem lịch sử hữu ích khi tìm ra thời điểm một lỗi được đưa vào, nhưng chú thích blame nội tuyến là thứ tôi dùng hàng giờ.

5. Playwright Test

Nếu bạn viết các bài kiểm tra end-to-end, tiện ích mở rộng này giúp vòng lặp phản hồi trở nên dễ chịu. Kết quả kiểm tra hiển thị nội tuyến, bạn có thể gỡ lỗi bằng các điểm dừng bên trong các tệp kiểm tra, và tính năng codegen ghi lại các tương tác trình duyệt thành mã kiểm tra. Tôi dùng nó nhiều hơn để gỡ lỗi các bài kiểm tra không ổn định hơn là viết bài mới, nhưng nó làm được cả hai.

Thêm: Settings.json của tôi

Những điều này sẽ không thay đổi cuộc đời bạn, nhưng chúng giúp tôi tránh được những phiền toái nhỏ:

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.minimap.enabled": false,
  "explorer.confirmDelete": false,
  "typescript.updateImportsOnFileMove.enabled": "always"
}

Cái minimap thì gây tranh cãi. Tôi biết một số người rất thích nó. Tôi thấy nó chiếm không gian mà không cung cấp thông tin hữu ích. Hãy thử tắt nó trong một tuần và xem bạn có nhớ nó không.

Bạn cũng có thể thích

• Tối ưu hóa công cụ tạo sinh (GEO) cho tài liệu kỹ thuật
• Tại Sao Blog Kỹ Thuật Của Bạn Cần Một Hệ Thống Phân Loại Thẻ (Và Cách Xây Dựng Một Hệ Thống Bền Vững)
• Sử dụng Google Search Console: Điều gì thực sự tạo nên sự khác biệt cho một blog phát triển
• Những gì tôi thực sự đã học được về các công việc phụ và thu nhập thụ động cho đến nay

Các câu hỏi thường gặp