Hai checklist đầu chặn cửa mỗi lần ra bản: một cái rà trước khi code rời branch, một cái lên kế hoạch trước khi thay đổi đến tay người dùng. Các checklist còn lại lo phần việc trước đó: đọc ticket, lên kế hoạch cho module và hỏi những câu làm lộ ra rủi ro còn ẩn.
Kiểm tra trước khi release
Danh sách giúp quyết định một thay đổi đã đủ an toàn để rời branch hay chưa. Dùng trước khi merge, gắn tag hoặc chuẩn bị đưa lên production.
Cổng chất lượng
Xác nhận thay đổi đúng, có test và đủ rõ để rà soát.
- Xác nhận phạm vi PR khớp với ticket và không giấu việc dọn dẹp ngoài yêu cầu.
- Chạy typecheck, test, lint và lệnh build phù hợp.
- Kiểm tra thủ công route hoặc workflow quan trọng.
- Đính kèm ảnh chụp cho thay đổi UI hoặc nói rõ vì sao không cần.
Risk gate
Bảo đảm release có observability và rollback rõ ràng.
- Xác nhận migration và thay đổi dữ liệu vẫn tương thích ngược.
- Dùng feature flag hoặc rollout theo giai đoạn khi phạm vi ảnh hưởng lớn.
- Xác nhận event PostHog vẫn được gửi và event mới có tên nhất quán.
- Viết rõ các bước rollback và người có quyền quyết định.
Bàn giao
Để lại đủ ngữ cảnh cho người review và người vận hành.
- Phần tóm tắt PR nêu hành vi thay đổi và route bị ảnh hưởng.
- Danh sách kiểm chứng ghi rõ lệnh cần chạy và bước kiểm tra thủ công.
- Nêu rõ tác động tới SEO, locale, analytics, nội dung và deployment.
- Chốt rõ thời gian theo dõi và tín hiệu thành công.
Kế hoạch rollout
Danh sách đưa code đã merge lên production theo từng bước, có điểm dừng và cách quay lại rõ ràng. Dùng cho release theo giai đoạn, feature flag, nhóm người dùng, migration hoặc thay đổi UI có tác động lớn.
Trước rollout
Chuẩn bị môi trường, nhóm người dùng và phương án dự phòng.
- Xác định nhóm rollout: nội bộ, beta, theo tỷ lệ, tenant hoặc khu vực.
- Xác nhận giá trị mặc định của flag/config và người phụ trách kill switch.
- Ghi số liệu gốc về chuyển đổi, tỷ lệ lỗi và phản hồi hỗ trợ.
- Chuẩn bị release note, ghi chú cho hỗ trợ và đường báo động tới người phụ trách.
Trong rollout
Đi theo từng bước nhỏ và theo dõi những tín hiệu xuất hiện sớm.
- Rollout theo từng giai đoạn.
- Người dùng nội bộ hoặc nhóm dogfood.
- Một nhóm beta nhỏ.
- Mở 10%, 25%, 50%, rồi 100% nếu các tín hiệu vẫn khỏe.
- Chỉ mở cho tenant cụ thể khi đội hỗ trợ đã sẵn sàng.
- Theo dõi lỗi, độ trễ, chuyển đổi, event PostHog và ticket hỗ trợ.
- Tạm dừng rollout khi chạm điều kiện rollback.
- Ghi mỗi lần đổi giai đoạn cùng thời điểm, người phụ trách và lý do.
Sau rollout
Khép lại đầy đủ thay vì dừng ngay sau khi đưa code lên.
- So sánh số liệu sau rollout với mốc ban đầu.
- Gỡ flag cũ, code tạm và những cách xử lý tạm mà đội hỗ trợ đang dùng.
- Ghi lại điều khiến cả đội bất ngờ.
- Tạo ticket theo dõi cho technical debt, tài liệu và phần analytics còn thiếu.
Từ ticket đến commit đầu tiên
Danh sách giúp biến một ticket thành phạm vi rõ ràng, kế hoạch vừa đủ và bước sửa đầu tiên có thể kiểm chứng. Dùng trước khi bắt tay vào một việc đến từ sản phẩm, hỗ trợ, thiết kế hoặc đồng đội kỹ thuật.
Hiểu yêu cầu
Xác nhận đây là vấn đề cần giải quyết, không chỉ là yêu cầu đổi giao diện hoặc sửa code.
- Đọc ticket rồi diễn đạt lại mục tiêu bằng một câu.
- Xác định người dùng, route, quy trình hoặc ranh giới hệ thống bị ảnh hưởng.
- Tách rõ tiêu chí nghiệm thu và đánh dấu phần còn thiếu.
- Kiểm tra tác động tới sản phẩm, SEO, analytics, locale, accessibility và quyền riêng tư.
Chuẩn bị trước khi làm
Làm rõ phần chưa biết trước khi đọc thêm nhiều file.
- Tìm pattern, test, helper và ranh giới trách nhiệm gần nhất trong codebase.
- Tách phần bắt buộc khỏi việc dọn dẹp chỉ nên làm thêm.
- Chọn lệnh, ảnh chụp hoặc bước kiểm tra thủ công để chứng minh thay đổi đã đúng.
- Ghi lại giả định rủi ro nhất trước khi triển khai.
Bắt đầu thực hiện
Giữ thay đổi đầu tiên nhỏ, rõ và dễ review.
- Bắt đầu bằng thay đổi nhỏ nhất có thể rà soát.
- Thêm hoặc sửa test tại đúng ranh giới có hành vi thay đổi.
- Cập nhật PostHog khi thêm điều hướng, CTA, bộ lọc, form, tùy chọn hoặc route mới.
- Dừng lại cập nhật tình hình nếu phạm vi hoặc mức rủi ro thay đổi.
Danh sách kiểm tra khi giao phần mềm
Tám giai đoạn từ lúc nhận việc đến khi theo dõi và rút kinh nghiệm sau rollout. Dùng khi thay đổi có thể ảnh hưởng kiến trúc, dữ liệu, lưu lượng, người dùng, vận hành production hoặc việc bàn giao.
Giai đoạn 1: Tiếp nhận
Hiểu đúng vấn đề trước khi chọn giải pháp kỹ thuật.
- Nêu vấn đề kinh doanh hoặc vấn đề của người dùng cùng chỉ số thành công.
- Làm rõ phạm vi, phần không làm, thời hạn, mức ưu tiên và nhóm người dùng bị ảnh hưởng.
- Kiểm tra dependency, bảo mật, quyền riêng tư, pháp lý, migration dữ liệu, tương thích ngược và tác động tới lưu lượng production.
- Nhờ AI đặt câu hỏi làm rõ về kinh doanh, sản phẩm, dữ liệu, API, bảo mật, độ tin cậy, rollout và observability.
Giai đoạn 2: Khảo sát
Vẽ lại hệ thống hiện tại trước khi thay đổi.
- Xác định service, route, job, API, sự kiện, kho dữ liệu, người phụ trách và pattern hiện có.
- Kiểm tra sự cố, điểm nghẽn, dashboard, log và ràng buộc hệ thống cũ có liên quan.
- Nhờ AI lập bản đồ dependency, thành phần bị ảnh hưởng, điểm tích hợp, rủi ro và thông tin còn thiếu.
Giai đoạn 3: Thiết kế
So sánh các phương án và chọn thiết kế đơn giản nhất xử lý đúng rủi ro.
- Tạo ADR khi quyết định ảnh hưởng kiến trúc, dữ liệu, dependency hoặc rollout.
- So sánh ít nhất ba phương án về độ phức tạp, khả năng mở rộng, tính nhất quán, chi phí, migration, rollback và khả năng bảo trì.
- Chốt đồng bộ hay bất đồng bộ, CRUD/CQRS/Event Sourcing, index, ranh giới transaction, cache, idempotency, retry, Circuit Breaker và mô hình bảo mật.
Giai đoạn 4: Kế hoạch triển khai
Chia thiết kế thành các PR nhỏ, rõ và dễ rà soát.
- Chia việc theo backend, database, API contract, test, observability, rollout và tài liệu.
- Lập kế hoạch migration, feature flag, API tương thích ngược, theo dõi, rollback và người rà soát.
- Xác định các kiểm tra unit, integration, contract, E2E, tải, bảo mật, migration và rollback.
Giai đoạn 5: Viết code và rà soát
Giữ phần triển khai đúng ranh giới và đúng hành vi trên production.
- Kiểm tra ranh giới kiến trúc, transaction, validation, xử lý lỗi và trách nhiệm sở hữu.
- Đảm bảo retry không tạo tác dụng phụ trùng lặp và dữ liệu nhạy cảm không bị ghi log.
- Nhờ AI review như một Principal Engineer về tính đúng đắn, race condition, tính nhất quán, bảo mật, observability, hiệu năng, khả năng bảo trì và rủi ro rollback.
Giai đoạn 6: Kiểm chứng trước rollout
Chứng minh tính năng chạy đúng cả luồng bình thường lẫn tình huống lỗi.
- Chạy unit, integration, contract, E2E, load, security, migration dry-run và kiểm tra tương thích ngược khi cần.
- Chuẩn bị dashboard, alert, runbook, rollback path và cách kiểm tra tác động tới khách hàng.
- Nhờ AI tạo danh sách sẵn sàng cho production gồm tình huống lỗi, theo dõi, điều kiện dừng, rollback và kiểm tra dữ liệu.
Giai đoạn 7: Rollout
Release theo từng bước nhỏ và theo dõi tác động tới người dùng.
- Nếu có thể, deploy ở trạng thái chưa mở cho người dùng rồi bật nội bộ trước khi canary.
- Theo dõi metric thành công, tỷ lệ lỗi, độ trễ, tải DB, query plan, độ trễ queue, tỷ lệ cache hit/miss và phản hồi hỗ trợ.
- Định nghĩa điều kiện thành công, điều kiện dừng, người quyết định rollback, kế hoạch thông báo và kill switch.
Giai đoạn 8: Sau rollout
Biến kết quả bàn giao thành bài học và tri thức chung của đội ngũ.
- So sánh số liệu kỳ vọng với kết quả thực tế, regression, sự cố, lần suýt lỗi và cảnh báo nhiễu.
- Cập nhật tài liệu, ADR, runbook, checklist Studio và ticket theo dõi.
- Nhờ AI review sau rollout, gồm kết quả, metric, vấn đề, tác động tới người dùng, technical debt, việc cần làm và bài học.
Tạo module mới
Danh sách kiểm tra khi thêm route, module tính năng, module dịch vụ hoặc component dùng chung mà vẫn giữ trách nhiệm rõ ràng. Dùng khi thêm một phần tính năng hoặc module mới có thể tái sử dụng.
Định nghĩa ranh giới
Một module nên có một lý do chính để thay đổi.
- Nêu rõ module chịu trách nhiệm phần nào và phụ thuộc vào đâu.
- Định nghĩa đầu vào, đầu ra và trạng thái không hợp lệ.
- Đặt file theo pattern đang có thay vì tự tạo một kiểu thư mục mới.
- Chỉ mở API công khai vừa đủ và giữ chi tiết bên trong ở chế độ riêng tư.
Kiểm tra frontend
Giữ UI ổn định, dễ tiếp cận và đo lường được.
- Bao phủ đầy đủ các trạng thái của UI.
- Trạng thái đang tải hoặc đang chờ.
- Trạng thái chưa có dữ liệu.
- Trạng thái lỗi hoặc thiếu quyền.
- Hành vi trên mobile và màn hình hẹp.
- Dùng token, icon, khoảng cách và quy tắc card đang có.
- Thêm event cho trang, CTA, bộ lọc, tìm kiếm, tùy chọn hoặc liên kết ra ngoài khi cần.
- Kiểm tra nhãn, thứ tự focus, thao tác bàn phím và độ tương phản.
Kiểm tra backend
Làm rõ contract trước khi chi tiết triển khai lan sang nhiều nơi.
- Ghi rõ contract API/job và quy tắc validation.
- Kiểm tra authorization, quyền sở hữu và nhu cầu audit.
- Lập kế hoạch schema, index, migration, backfill và thời gian lưu dữ liệu.
- Thêm log, metric, cảnh báo và sự kiện kinh doanh nếu hành vi người dùng thay đổi.
Kiểm chứng
Module chưa hoàn tất nếu lần thay đổi sau vẫn không thể thực hiện an toàn.
- Viết unit test cho logic thuần và các trường hợp biên của module.
- Viết integration test cho contract, persistence và điểm nối giữa các thành phần.
- Kiểm tra thủ công luồng chính và ít nhất một tình huống lỗi.
- Cập nhật tài liệu, ghi chú PR và ảnh chụp khi thay đổi xuất hiện trước người dùng.
Những câu hỏi của Senior Engineer
Bộ câu hỏi gọn cho mọi tính năng, từ nhu cầu kinh doanh và domain đến API, dữ liệu, tính nhất quán, bảo mật, observability và rollout. Dùng trước khi triển khai một việc tưởng đơn giản nhưng có thể ẩn rủi ro với production, dữ liệu hoặc người dùng.
Kinh doanh, sản phẩm và domain
Nối phần triển khai với kết quả thật cần tạo ra.
- Metric kinh doanh, nhóm người dùng và thời hạn nào quan trọng trong việc này?
- Luồng chính, trường hợp biên, cách hoàn tác, trạng thái chờ/lỗi và nhu cầu audit là gì?
- Entity chính, ranh giới aggregate, chuyển trạng thái, invariant và domain event là gì?
API, dữ liệu và tính nhất quán
Làm rõ contract và cách trạng thái thay đổi.
- API đồng bộ hay bất đồng bộ; đã có idempotency, version, phân trang và tương thích ngược chưa?
- Schema, migration, index, quy mô truy vấn, thời gian lưu và rủi ro PII là gì?
- Cần strong consistency hay eventual consistency; có race condition hoặc sự kiện trùng không?
Khả năng chống lỗi và bảo mật
Giả định dependency và người dùng có thể hành xử ngoài dự đoán.
- Dependency nào có thể lỗi, phản hồi chậm hoặc chỉ hoàn tất một phần?
- Đã có timeout, retry, Circuit Breaker, fallback, rate limit và idempotency chưa?
- Ai được phép dùng, authorization ra sao, đầu vào nào cần kiểm tra và dữ liệu nào không được ghi log?
Observability và rollout
Chọn tín hiệu để hệ thống tự chứng minh đang khỏe hay có vấn đề.
- Metric kinh doanh, metric kỹ thuật, trace, log, correlation ID, dashboard và alert nào chứng minh tính năng đang chạy đúng?
- Đã có feature flag, canary, điều kiện dừng, đường rollback, cách hoàn tác migration và người theo dõi chưa?
- Sau rollout cần lưu lại điều gì để công việc sau có điểm bắt đầu tốt hơn?
Quy trình làm tính năng có AI hỗ trợ
Quy trình đầy đủ từ ý tưởng, đặc tả và triển khai đến rà soát, rollout rồi lưu lại kiến thức. Dùng cho thay đổi sản phẩm hoặc kỹ thuật đáng kể, khi nhiều công cụ AI cùng hỗ trợ nhưng người làm vẫn giữ trách nhiệm cuối cùng.
Định hình công việc
Dùng AI để làm rõ bài toán trước khi giao phần triển khai.
- Nhờ GPT soạn mô tả vấn đề, user story, tiêu chí nghiệm thu, phần không làm, rủi ro, rollout và kế hoạch test.
- Nhờ Claude phản biện kiến trúc, giả định, tình huống lỗi và phạm vi nhỏ nhất đủ giá trị.
- Chia thành các phần việc nhỏ cho Codex hoặc Antigravity, mỗi phần có thể review độc lập.
Thực hiện
Dùng đúng agent cho đúng loại công việc.
- Dùng Codex cho việc trong repo cần test, diff sạch, refactor, migration và kết quả sẵn sàng mở PR.
- Dùng Antigravity cho prototype nặng về UI, kiểm tra trình duyệt, ảnh chụp và sản phẩm xuyên suốt.
- Sau mỗi phần việc nhỏ, dừng lại kiểm tra trước khi mở rộng phạm vi.
Rà soát và release
Tách người thực hiện khỏi bước rà soát và quyết định release.
- Dùng Claude hoặc GPT rà soát diff về tính đúng đắn, bảo mật, trường hợp biên, phần test còn thiếu và rủi ro migration.
- Người phụ trách xem lại các đánh đổi và đưa ra quyết định merge cuối cùng.
- Dùng GPT để soạn release note, cập nhật cho bên liên quan và checklist rollout.
- Lưu PRD, RFC, quyết định, bằng chứng test và ghi chú postmortem vào NotebookLM.