Danh mục Kiểm tra Nền tảng Kỹ thuật (Engineering Fundamentals Checklist)

Bản danh mục kiểm tra này giúp đảm bảo mọi dự án đều đáp ứng nghiêm ngặt các Nền tảng Kỹ thuật chuẩn mực của chúng tôi.

1. Quản lý Mã nguồn (Source Control)

Nhánh đích mặc định (main / trunk) được khóa và bảo vệ (branch protection).
Mọi việc hợp nhất mã nguồn (merges) đều bắt buộc thông qua Pull Request (PR).
Các PR đều được liên kết với hạng mục công việc (Work Items/Issues) tương ứng.
Lịch sử commit nhất quán và nội dung thông điệp commit rõ ràng, mang tính thông tin cao (làm gì, tại sao).
Quy ước đặt tên nhánh đồng nhất.
Cấu trúc thư mục của kho lưu trữ được ghi chép tài liệu rõ ràng.
Không có bất kỳ thông tin bí mật (secrets, API keys, credentials) nào lọt vào lịch sử commit hay công khai ra ngoài (xem Quét thông tin xác thực).
Các kho lưu trữ công khai tuân thủ đầy đủ hướng dẫn mã nguồn mở OSS.

Xem thêm chi tiết tại Quản lý Mã nguồn.

Tất cả các hạng mục công việc đều được theo dõi tập trung trên Azure DevOps, GitHub Projects hoặc Jira.
Bảng Kanban được tổ chức khoa học (làn bơi - swim lanes, thẻ tính năng, thẻ công nghệ).

Xem thêm chi tiết tại Quản lý Backlog.

Kiểm thử đơn vị (Unit Tests) bao phủ phần lớn các thành phần (>90% nếu có thể).
Kiểm thử tích hợp (Integration Tests) chạy định kỳ để kiểm thử toàn diện giải pháp đầu-cuối (E2E).

Xem thêm chi tiết tại Kiểm thử Tự động.

Dự án chạy pipeline CI tự động build và chạy test trên mỗi PR.
Dự án sử dụng CD để tự động triển khai lên môi trường thử nghiệm (replica/staging) trước khi PR được merge.
Nhánh chính (main) luôn ở trạng thái sẵn sàng xuất xưởng (continuously shippable).

Xem thêm chi tiết tại Tích hợp Liên tục (CI) và Bàn giao Liên tục (CD).

Quyền truy cập chỉ được cấp phát theo nguyên tắc đặc quyền tối thiểu (Least Privilege).
Toàn bộ thông tin bí mật (secrets) được lưu trữ an toàn trong Key Vault/Secrets Manager, tuyệt đối không hardcode trong mã nguồn.
Dữ liệu được mã hóa trong quá trình truyền tải (in transit) và khi lưu trữ (at rest); mật khẩu bắt buộc phải được băm (hashed).
Hệ thống được phân tách thành các phân vùng logic với nguyên tắc phân chia trách nhiệm (separation of concerns), giúp khoanh vùng lỗ hổng bảo mật.

Xem thêm chi tiết tại Bảo mật.

Các sự kiện nghiệp vụ và chức năng trọng yếu được theo dõi và thu thập số liệu đo kiểm (metrics).
Toàn bộ lỗi và ngoại lệ của ứng dụng được ghi log đầy đủ.
Trạng thái sức khỏe (health checks) của hệ thống được giám sát liên tục.
Dữ liệu giám sát phía Client và Server được phân định rõ ràng.
Cấu hình ghi log có thể thay đổi linh hoạt mà không cần sửa code (ví dụ: bật chế độ verbose).
Ngữ cảnh truy vết (Tracing context / Correlation ID) được lan truyền xuyên suốt các dịch vụ để phục vụ gỡ lỗi trên môi trường production.
Tuân thủ quy định bảo vệ dữ liệu cá nhân (PII / GDPR).

Xem thêm chi tiết tại Khả năng Quan sát.

Process Lead (cố định hoặc luân phiên) điều phối buổi họp Daily Standup hàng ngày.
Quy trình Agile được toàn đội thống nhất rõ ràng.
Dev Lead cùng Product Owner chịu trách nhiệm làm mịn và quản lý Backlog.
Thỏa thuận làm việc (Working Agreement) được thiết lập chặt chẽ giữa các thành viên và khách hàng.

Xem thêm chi tiết tại Phát triển Agile.

Quy trình đánh giá thiết kế được đưa vào Thỏa thuận Làm việc.
Các đợt đánh giá thiết kế cho từng thành phần chính của giải pháp được thực hiện và lưu trữ tài liệu đầy đủ, bao gồm cả các phương án kiến trúc thay thế.
Các Story hoặc PR đều dẫn liên kết tới tài liệu thiết kế liên quan.
Mỗi User Story mặc định có một task dành riêng cho việc đánh giá thiết kế.
Các chuyên gia cố vấn của dự án được mời tham gia hoặc lấy ý kiến phản hồi về các quyết định thiết kế.
Nắm bắt rõ ràng các yêu cầu phi chức năng (xem Hướng dẫn Yêu cầu Phi chức năng).
Nhận diện và theo dõi rủi ro và cơ hội (xem Quản lý Rủi ro & Cơ hội).

Xem thêm chi tiết tại Đánh giá Thiết kế.

Toàn đội thống nhất rõ ràng về vai trò và mục đích của việc Code Review.
Nhóm có một danh mục kiểm tra code review (checklist) hoặc quy trình chuẩn mực.
Chính sách bắt buộc tối thiểu số lượng người phê duyệt (thường là 2 reviewers) trước khi merge PR.
Thiết lập công cụ phân tích tĩnh (Linters/Analyzers), unit tests và build thành công trước khi merge.
Có quy trình đảm bảo tốc độ phản hồi review nhanh chóng (tránh để PR bị ngâm lâu).

Xem thêm chi tiết tại Đánh giá Mã nguồn.

Buổi họp cải tiến được tổ chức đều đặn mỗi tuần hoặc vào cuối mỗi Sprint.
Nhóm xác định từ 1 đến 3 thử nghiệm cải tiến cụ thể để áp dụng trong tuần/sprint tiếp theo.
Các thử nghiệm có người phụ trách rõ ràng và được đưa vào backlog dự án.
Tổ chức các buổi retrospective chuyên sâu sau mỗi Cột mốc (Milestone) hoặc khi kết thúc dự án.

Xem thêm chi tiết tại Nghi thức Cải tiến.

Toàn đội kịp thời gửi phản hồi về các điểm nghẽn nghiệp vụ và kỹ thuật cản trở thành công của dự án.
Các đề xuất cải tiến được tích hợp trực tiếp vào giải pháp.
Phản hồi mang tính chi tiết, cụ thể và có thể tái hiện được.

Xem thêm chi tiết tại Phản hồi Kỹ thuật.

Các lập trình viên trong nhóm có thể:

Build và biên dịch mã nguồn dễ dàng để xác thực không có lỗi cú pháp.
Chạy mượt mà toàn bộ các bài kiểm thử tự động (unit test, e2e,...).
Khởi chạy ứng dụng đầu-cuối trên máy cục bộ mô phỏng sát với môi trường production.
Gắn debugger vào ứng dụng hoặc test case, đặt điểm dừng (breakpoints), chạy từng dòng lệnh và xem giá trị biến.
Tự động cài đặt đầy đủ các dependency chỉ bằng một phím bấm (như F5 trong IDE) hoặc cấu hình Dev Container.
Sử dụng các biến cấu hình môi trường cục bộ riêng biệt (như .env, appsettings.development.json).

Xem thêm chi tiết tại Trải nghiệm Lập trình viên.

Cập nhật cuối cùng: 11 tháng 11, 2026