Thư Viện Câu Hỏi Phỏng Vấn

Việc sử dụng 'catch (Exception ex)' mà không có xử lý cụ thể sẽ che giấu các lỗi hệ thống nghiêm trọng (như OutOfMemoryException hoặc StackOverflowException) và làm mất dấu vết (stack trace) của lỗi gốc.

Trong C#, 'String' là kiểu dữ liệu bất biến (immutable). Mỗi khi bạn thay đổi giá trị của một chuỗi, một đối tượng chuỗi mới sẽ được cấp phát trong bộ nhớ, và đối tượng cũ sẽ bị Garbage Collector thu hồi.

Lưu trữ thông tin nhạy cảm trong file 'appsettings.json' có nguy cơ bị lộ thông tin khi mã nguồn được đẩy lên các hệ thống quản lý phiên bản như Git.

LINQ cung cấp cú pháp truy vấn thống nhất cho nhiều nguồn dữ liệu. Cơ chế quan trọng nhất là 'Deferred Execution' (thực thi trì hoãn).

Việc trả về trực tiếp 'Entity' là một rủi ro lớn trong các ứng dụng Enterprise vì các lý do sau:

Nguyên lý Dependency Inversion yêu cầu các module cấp cao không nên phụ thuộc vào các module cấp thấp, cả hai nên phụ thuộc vào abstraction. Để thực hiện điều này:

Việc inject trực tiếp IConfiguration vào Service khiến Service bị phụ thuộc vào cấu trúc file cấu hình (appsettings.json), gây khó khăn cho việc kiểm thử. Thay vào đó, hãy sử dụng Options Pattern:

Constructor Over-injection thường là triệu chứng của việc vi phạm nguyên lý Single Responsibility (SRP). Khi một class cần quá nhiều dependency, nó đang đảm nhận quá nhiều nhiệm vụ.

Trong các ứng dụng Enterprise, đôi khi bạn cần nhiều implementation cho một interface (ví dụ: nhiều loại Payment Gateway). Bạn có thể đăng ký nhiều lần cho cùng một interface:

Sự khác biệt nằm ở quyền kiểm soát vòng đời và thời điểm khởi tạo:

Khi không có tệp package-lock.json, lệnh npm install sẽ dựa vào các quy tắc phiên bản được định nghĩa trong package.json (ví dụ như dấu ^ hoặc ~). Điều này dẫn đến việc npm tự động cài đặt phiên bản mới nhất thỏa mãn điều kiện đó tại thời điểm chạy lệnh. Rủi ro bao gồm: 1. Sự không nhất quán giữa môi trường phát triển và môi trường Production do các phiên bản phụ (minor) hoặc bản vá (patch) khác nhau. 2. Các thay đổi không mong muốn từ thư viện bên thứ ba có thể gây lỗi hệ thống (breaking changes). 3. Khó khăn trong việc tái lập lỗi (reproducibility) khi debug. Giải pháp tối ưu là luôn commit tệp package-lock.json vào hệ thống quản trị mã nguồn và sử dụng lệnh npm ci trong môi trường CI/CD để đảm bảo cài đặt chính xác các phiên bản đã được kiểm thử.

Trong các trình quản lý gói như npm, cơ chế hoisting cố gắng đưa các dependencies về thư mục node_modules gốc để tiết kiệm không gian. Nếu có xung đột, npm sẽ thực hiện 'nested dependency' (lồng ghép) bằng cách đặt phiên bản khác vào thư mục node_modules của chính gói đó. Cách xử lý: 1. Kiểm tra cây phụ thuộc bằng lệnh npm ls [tên-gói]. 2. Sử dụng tính năng overrides (trong npm 8+) hoặc resolutions (trong yarn) trong tệp package.json để ép buộc sử dụng một phiên bản duy nhất cho toàn bộ dự án. 3. Cập nhật các thư viện con lên phiên bản mới nhất để tương thích với cùng một phiên bản của thư viện mẹ. Việc ép buộc phiên bản cần được kiểm tra kỹ lưỡng thông qua Unit Test để tránh lỗi runtime.

Dependencies là danh sách các gói cần thiết để ứng dụng chạy, thường được tải về từ registry (như npmjs.com) khi cài đặt. Ngược lại, bundledDependencies là một mảng các tên gói sẽ được đóng gói trực tiếp vào tệp .tgz khi bạn thực hiện lệnh npm pack. Bạn nên sử dụng bundledDependencies khi: 1. Thư viện của bạn phụ thuộc vào một gói không có sẵn trên registry công cộng. 2. Bạn muốn đảm bảo tính toàn vẹn của các gói phụ thuộc mà không cần kết nối internet khi cài đặt thư viện ở môi trường nội bộ. Lưu ý rằng việc sử dụng bundledDependencies sẽ làm tăng kích thước tệp cài đặt đáng kể, do đó chỉ nên dùng khi thực sự cần thiết.

Để bảo mật chuỗi cung ứng, lập trình viên cần thực hiện các bước sau: 1. Sử dụng lệnh npm audit để quét các lỗ hổng bảo mật đã biết trong cây phụ thuộc. 2. Kiểm tra kỹ tên gói (typosquatting) để tránh cài nhầm các gói có tên gần giống với thư viện nổi tiếng. 3. Sử dụng các công cụ như Snyk hoặc Socket.dev để phân tích hành vi của gói (ví dụ: gói có cố gắng truy cập network hoặc filesystem trái phép không). 4. Hạn chế sử dụng các gói có ít lượt tải hoặc không được cập nhật trong thời gian dài. 5. Luôn ưu tiên sử dụng tệp lockfile để đảm bảo mã nguồn đã được kiểm duyệt không bị thay đổi bởi các bản cập nhật tự động từ registry.

Việc sử dụng các trình quản lý gói khác nhau có thể tạo ra các tệp lockfile không tương thích và gây lỗi build. Để đồng bộ: 1. Sử dụng thuộc tính 'engines' trong tệp package.json để chỉ định phiên bản node và trình quản lý gói tối thiểu. 2. Sử dụng tệp .npmrc hoặc cấu hình 'packageManager' trong package.json (được hỗ trợ bởi Corepack). 3. Thiết lập quy trình kiểm tra tự động trong CI/CD pipeline để từ chối build nếu trình quản lý gói không đúng với cấu hình dự án. Ví dụ cấu hình trong package.json: "engines": { "node": ">=18.0.0", "npm": ">=9.0.0" }. Việc này giúp tránh các lỗi phát sinh do sự khác biệt về thuật toán phân giải dependency giữa các phiên bản.