Checklist đánh giá bài thực hành

Catalog và cart đã hiện trong shell, nút thêm giỏ cũng chạy. Nhưng nếu đổi catalog vẫn phải rebuild shell, logout vẫn để lộ cart của user trước, hoặc remote lỗi làm trắng toàn bộ trang, thì một demo chạy được chưa đủ để kết luận kiến trúc đạt yêu cầu.

Trang này giúp bạn đánh giá hành vi ở boundary, không chỉ nhìn cấu trúc thư mục. Mỗi dấu tick cần có cách tái hiện và bằng chứng: public contract, test result, artifact digest, browser trace hoặc telemetry đã redact. Mình ưu tiên những bằng chứng này hơn số ứng dụng hay số repository bạn tạo.

Mục lụcCopy Anchor Link

• Chốt phạm vi đánh giá
• Cách dùng checklist
• Các gate bắt buộc
• Coupling và ownership
  • Checklist coupling
  • Cách kiểm chứng ranh giới
• Deploy độc lập và tương thích
  • Checklist release
  • Bằng chứng release và rollback
• Kiểm thử theo rủi ro
  • Checklist kiểm thử
  • Ma trận test tối thiểu
• UX routing auth và khả năng phục hồi
  • Checklist trải nghiệm
  • Kịch bản nghiệm thu bằng browser
• Observability và chẩn đoán
  • Checklist observability
  • Bài kiểm tra từ lỗi đến artifact
• Chấm điểm và kết luận
• Mẫu biên bản đánh giá
• Ưu tiên sửa sau buổi review
• Đọc tiếp

Chốt phạm vi đánh giáCopy Anchor Link

Trước khi chạy test, ghi rõ bạn đang đánh giá bài nào, commit nào và implementation nào. Các lab trong nhóm minh họa những vấn đề khác nhau, không phải các bước nối tiếp tạo thành một codebase hoàn chỉnh.

Không yêu cầu apiVersion của cart controller React xuất hiện trong mount API của lab ESM. Tương tự, test reload giỏ in-memory không được đòi giữ hàng như giỏ từ backend. Đánh giá một implementation theo contract đã công bố, không theo kỳ vọng ngầm của người review.

Nếu chỉ nghiệm thu lab ghép shop, các mục session và release có thể là N/A — không áp dụng. Nhưng kết luận phải là “đạt lab ghép shop”, không phải “đạt deploy độc lập”. Nếu nghiệm thu bài tổng hợp đủ năm nhóm, không được loại cả nhóm deploy hay observability để tăng điểm.

Trong bài tổng hợp có auth, controller sống suốt document chưa đủ an toàn: bạn cần reset hoặc tạo lại state giỏ theo session scope khi đổi user. Đây là yêu cầu bổ sung khi ghép hai bài, không phải tính năng sẵn có của controller in-memory ở lab đầu tiên.

Cách dùng checklistCopy Anchor Link

Chốt phạm vi trước rồi mới chạy checklist, vì sau khi thấy lỗi rất dễ đổi một mục thành “không cần”. Quy trình có thể giữ đơn giản:

direction: right
n0: "Chốt phạm vi"
n1: "Chạy kịch bản"
n2: "Lưu bằng chứng"
n3: "Kiểm tra gate và kết luận"
n0 -> n1 -> n2 -> n3

1. Ghi commit/build, danh sách release, config revision, môi trường và những mục N/A kèm lý do.
2. Chạy happy path trước để xác nhận fixture và app sẵn sàng. Sau đó chủ động tạo lỗi ở từng boundary.
3. Với mỗi mã tiêu chí, lưu trạng thái, bằng chứng, lỗi còn tồn tại và owner sửa.
4. Kiểm tra gate trước khi tính điểm. Gate chưa có bằng chứng được coi là chưa đạt.
5. Sau khi sửa, chạy lại kịch bản lỗi và một journey liên quan; không chỉ kiểm tra dòng code đã đổi.

Checkbox dưới đây là bản nghiệm thu tĩnh, không phải dữ liệu lưu trạng thái trong site. Sao chép danh sách vào biên bản của bạn; chỉ đổi thành [x] khi tiêu chí đạt đầy đủ. Mục đạt một phần vẫn để trống và ghi rõ trong biên bản.

Một ảnh chụp UI đẹp chứng minh được trạng thái tại thời điểm chụp. Nó không tự chứng minh cleanup, khả năng rollback hay response đến muộn không làm sai state.

Các gate bắt buộcCopy Anchor Link

Gate là điều kiện không được bù bằng điểm ở nhóm khác. Các gate dưới đây áp dụng theo phạm vi đã chốt; mỗi gate cần bằng chứng trực tiếp, không chỉ dựa trên điểm của checklist.

Nếu một remote cung cấp dependency thiết yếu như cart controller và không tải được, bạn có thể phải khóa thao tác thêm giỏ. G4 không yêu cầu giả vờ chức năng đó vẫn hoạt động; nó yêu cầu shell giải thích đúng tình trạng và giữ các chức năng không phụ thuộc còn dùng được. Với lab ESM không có navigation của shop React, kiểm tra phần shell và sibling remote còn khả dụng theo contract của lab đó.

Coupling và ownershipCopy Anchor Link

Coupling đáng lo không phải là “các app có gọi nhau không”. Shell luôn phải nối các domain. Vấn đề là shell hoặc remote có phụ thuộc vào chi tiết nội bộ mà owner có thể đổi mà không báo hay không.

Checklist couplingCopy Anchor Link

• C1 — Ranh giới domain: shell sở hữu composition, navigation cấp ứng dụng và wiring; catalog sở hữu UI sản phẩm; cart sở hữu mutation và snapshot giỏ. Có bảng owner cho public boundary.
• C2 — Chỉ dùng public contract: không import source, reducer, private store hay đường dẫn nội bộ của app khác. Shared package không chứa mutable domain store mà mọi app cùng sửa.
• C3 — Một nguồn state: badge và cart đọc cùng snapshot/controller trong cùng session scope. Shell không tự cộng badge sau click rồi đồng bộ ngược với cart.
• C4 — Kết quả command rõ ràng: caller phân biệt thành công và thất bại; dữ liệu đi qua boundary theo contract. Trong lab React, onAddToCart gửi SKU và quantity, không gửi giá để shell tự tính tiền.
• C5 — Lifecycle có cleanup: subscription được hủy khi consumer unmount; route change không vô tình tạo lại controller. Với mount API, unmount() dọn listener và không sửa DOM ngoài container đã nhận.
• C6 — Remote kiểm thử được riêng: entry standalone hoặc harness dùng cùng public component/module với integrated mode; adapter/fixture có shape rõ ràng, không cần chạy source của mọi app để test logic domain.

Cách kiểm chứng ranh giớiCopy Anchor Link

Đọc import graph trước, rồi quan sát runtime. Không có cross-import chưa đủ để kết luận ít coupling: một global event với payload lấy từ reducer nội bộ vẫn có thể buộc hai app đổi cùng nhau.

Mặc định mình giữ shared package ở mức public types/schema hoặc utility không có domain state. Monorepo giúp phối hợp source, nhưng không tự tạo release coupling; multi-repo cũng không ngăn một global store trở thành điểm nối cứng. Xem state ownership và hợp đồng giao tiếp khi một boundary chưa rõ owner.

Deploy độc lập và tương thíchCopy Anchor Link

Chạy được ba dev server không chứng minh deploy độc lập. Bạn cần một thay đổi được phục vụ cho document mới trong khi artifact của consumer hiện tại giữ nguyên, cùng bằng chứng rằng tổ hợp đó vẫn chạy đúng.

Checklist releaseCopy Anchor Link

• D1 — Định danh artifact: shell, catalog, cart có release ID và URL/digest tương ứng; config revision được ghi riêng, không nhầm với version code.
• D2 — Không rebuild consumer: publish và promote catalog mới không rebuild/redeploy shell, cart hoặc HTML bootstrap của shell. Có log pipeline và checksum đầy đủ trước/sau.
• D3 — Tương thích có kiểm chứng: candidate được test với shell/cart đang phục vụ; breaking contract bị chặn trước promotion, dù build candidate thành công.
• D4 — Đủ asset graph: entry và lazy chunks của mỗi release được publish đầy đủ; bytes tại URL release không bị overwrite; thiếu asset trả lỗi thật, không trả HTML app dưới status 200.
• D5 — Rollback chỉ đổi selection cần thiết: revision mới chọn lại catalog tương thích; không phục hồi mù toàn bộ config cũ hoặc làm lùi release cart không liên quan. Document mới và tab đang sống được kiểm tra riêng.
• D6 — Config và cache có policy: selection được validate và pin theo document như contract; cache headers phù hợp; stale candidate bị từ chối; artifact cũ được giữ trong cửa sổ hỗ trợ đã công bố.

Bằng chứng release và rollbackCopy Anchor Link

Nếu dùng lab deploy độc lập, bộ evidence tối thiểu có thể lấy ngay từ các bước của bài đó:

Trong independent-deploy-lab, sau khi đã ghi digest và promotion theo bài lab, kiểm tra hai file evidence:

diff -u evidence/before.sha256 evidence/after.sha256

Kết quả đạt là không có output và exit code 0. So sánh này chỉ chứng minh tập artifact đã đưa vào manifest không đổi. Bạn vẫn cần log để chứng minh pipeline không chạy lại bước rebuild/redeploy consumer: cùng bytes không có nghĩa không build lại.

Đừng chỉ hash file JavaScript chính. HTML bootstrap, CSS và các chunk thuộc shell/cart cũng nằm trong boundary deployment. Với app tự mở rộng, tạo manifest toàn bộ output tương ứng thay vì dùng đường dẫn của lab ESM một cách máy móc.

Giữ cả tab mới lẫn tab cũ khi rollback. Config đổi trên server không thay module đã chạy trong document; chỉ chuyển route không bảo đảm bootstrap lại. Nếu app của bạn hỗ trợ hot switch, phải có contract và test riêng cho cleanup, state migration và recovery — không mặc định runtime loader đã giải quyết chúng.

Kiểm thử theo rủi roCopy Anchor Link

Một test chỉ render catalog không kiểm tra được command sang cart. Một E2E chỉ chạy tất cả app ở HEAD cũng không chứng minh consumer cũ chịu được provider mới. Chọn test theo boundary có thể hỏng, rồi đo coverage như công cụ tìm khoảng trống.

Checklist kiểm thửCopy Anchor Link

• T1 — Unit test logic owner: mutation, quantity không hợp lệ, SKU không tồn tại, snapshot identity và no-op được assert theo contract của controller.
• T2 — Component test trạng thái UI: pending, thành công, lỗi, empty state và cleanup có assertion; không chỉ kiểm tra component mount không throw.
• T3 — Contract test hai phía: test shape/schema và semantics của callback, snapshot hoặc mount API; breaking payload và sai major bị phát hiện ở boundary.
• T4 — Integration trên artifact: chạy tổ hợp release/config thực tế trước promotion, gồm lazy module và lifecycle; không chỉ import source local cùng version.
• T5 — Browser E2E journey và failure: có happy path, deep link/reload nếu có routing, remote load failure, render failure và session race nếu có auth.
• T6 — Kết quả chạy lại được: lệnh test, fixture, setup và artifact IDs được ghi; test độc lập state, có điều khiển timing; failure làm CI/gate thất bại, không bị bỏ qua bằng retry vô hạn.

Ma trận test tối thiểuCopy Anchor Link

Với lab cart đã tạo test file, chạy từ root shop-workspace:

node --test tests/cart-controller.test.mjs
npm run build

Đây chỉ là bằng chứng unit test của controller và build. Bạn vẫn phải thực hiện test browser và boundary còn thiếu; npm run build không thay E2E.

Không đặt một con số coverage chung rồi coi đó là điều kiện đủ. Nếu team dùng coverage threshold, ghi rõ statement/branch coverage của phần nào và những ca rủi ro bắt buộc. Một test bỏ qua race logout có thể để lộ dữ liệu dù coverage tổng nhìn rất cao.

Test timing nên dùng deferred response, chờ request thực sự bắt đầu hoặc chờ trạng thái có ý nghĩa. Tăng sleep chỉ làm test lâu hơn, không bảo đảm bạn đã đi qua đúng race. Khi một test fail rồi pass ở lần retry, giữ evidence lần fail và điều tra; không tự gọi đó là đã đạt.

UX routing auth và khả năng phục hồiCopy Anchor Link

Một micro-frontend có fallback nhưng người dùng không biết thao tác đã thành công hay chưa vẫn là UX lỗi. Đánh giá cả màn hình đang chờ, lúc boundary hỏng và sau khi người dùng thử lại.

Checklist trải nghiệmCopy Anchor Link

• U1 — Journey mua sắm nhất quán: thêm, tăng/giảm, xóa và empty state đúng contract; badge là tổng quantity; chuyển route không mất giỏ ngoài policy đã công bố.
• U2 — URL có một owner: integrated mode không tạo router/root ngoài contract; direct link, reload, Back/Forward và not-found đồng bộ UI/URL, không làm mất query/fragment.
• U3 — Loading và failure đúng nghĩa: pending khóa thao tác có thể gây trùng; thành công chỉ hiện sau acknowledgement; fallback phân biệt lỗi remote với auth failure và có lối đi tiếp.
• U4 — Phục hồi có giới hạn: load/render failure được xử lý riêng; retry có giới hạn và policy rõ; retry không tự gửi lại mutation có thể đã được thực thi. Chunk lỗi đã cache reject không bị “retry” bằng cách chỉ render lại cùng loader.
• U5 — Session isolation: private UI không mount khi session còn checking; logout khóa dữ liệu ngay; response cũ không hồi sinh phiên trước; 403 không thành login loop, network/5xx không thành anonymous; backend enforce quyền.
• U6 — Accessibility và không phá sibling: navigation/nút dùng được bằng keyboard, focus hợp lý khi đổi màn hình hoặc lỗi, status được thông báo; CSS remote không làm đổi control của app khác; không layout shift lớn do thiếu vùng loading đã dự trù.

Kịch bản nghiệm thu bằng browserCopy Anchor Link

Các hàng dưới đây có phạm vi riêng. Không chạy dữ liệu fixture của lab React vào lab ESM, và không coi dấu tick ở một implementation là bằng chứng cho implementation khác.

Để B7 có ý nghĩa, chặn request từ trước khi tải module, thường bằng browser context mới và request interception. Chặn entry sau khi module đã nằm trong module cache không kích hoạt load failure. Dừng dev server cũng có thể chưa làm remote hỏng nếu artifact cần thiết đã được tải.

Render failure cần fixture chủ động throw trong vùng muốn kiểm tra. Error Boundary của React không tự bắt lỗi của callback async hoặc Promise rejection; những đường đó cần xử lý tại command/loader boundary. Xem resilience để tách cơ chế xử lý, thay vì dùng một fallback cho mọi nguyên nhân.

Khi kiểm tra retry mutation, phân biệt “server chắc chắn chưa nhận” với “chưa biết kết quả”. Timeout không có nghĩa mutation chưa chạy. Nếu chưa có idempotency/reconciliation contract, đừng tự động gửi lại yêu cầu thêm hàng như cách retry một read.

Observability và chẩn đoánCopy Anchor Link

Mục tiêu của nhóm này là reviewer trả lời được: boundary nào hỏng, tổ hợp release nào đang chạy và user bị ảnh hưởng thế nào? Console có stack trace nhưng thiếu release context thường không đủ để nối lỗi với artifact.

Checklist observabilityCopy Anchor Link

• O1 — Context có định danh: event ghi app báo lỗi, target remote, phase, release thực chạy nếu đã biết, shell release và config revision. Khi module chưa tải, candidate release được phân biệt với release đã thực thi.
• O2 — Có outcome và duration: quan sát load/ready/failure theo contract; ghi success lẫn failure để tính tỷ lệ; retry attempt không bị đếm thành nhiều journey độc lập.
• O3 — Theo được operation: command/API có correlation ID; nếu dùng tracing, kiểm chứng propagation và spans backend thực sự nối được, không chỉ thấy header trong DevTools.
• O4 — Error attribution đúng: mỗi lỗi có report owner để tránh capture trùng; stack/source map khớp đúng build, không gán release deploy gần nhất cho mọi tab.
• O5 — Telemetry không phá app: sink throw/reject hoặc endpoint bị chặn không đổi kết quả nghiệp vụ, không tạo unhandled rejection hay queue tăng vô hạn; không bootstrap global SDK trùng trong cùng runtime.
• O6 — Privacy và hành động rõ: payload được allowlist/redact; không log credential, raw query hoặc toàn bộ cart; dữ liệu quan sát có owner, cách query và hành động xử lý khi regression.

Bài kiểm tra từ lỗi đến artifactCopy Anchor Link

Tạo một lỗi có chủ đích trong preview hoặc môi trường local, rồi nhờ reviewer điều tra chỉ từ evidence. Không tạo lỗi trên traffic production để nghiệm thu bài học.

1. Tải một tổ hợp shell/catalog/cart đã ghi release và config revision.
2. Tạo load failure hoặc render failure; xác nhận fault đã thực sự xảy ra bằng Network/fixture.
3. Tìm event và xác định đúng phase, target, artifact đã chọn và artifact thực chạy nếu có.
4. Đối chiếu event với manifest/config, mở stack đã symbolicate nếu là lỗi code; kiểm tra URL/status/cache nếu là lỗi tải.
5. Giải thích ảnh hưởng lên journey và chọn hành động: retry an toàn, kiểm tra hosting hoặc pause/rollback đúng release.
6. Chặn telemetry transport rồi lặp lại thao tác; xác nhận xử lý lỗi UI không phụ thuộc việc gửi event thành công.

Trong lab local, một structured event sink ghi JSON vào file hoặc Console có thể đủ để kiểm tra context/outcome. Nó không chứng minh ingestion production, dashboard hay alert đã hoạt động. Nếu chưa có source map/tracing, ghi phần đó chưa đạt hoặc N/A theo scope đã chốt, không dùng một dòng Console để tick toàn bộ O3/O4.

Ở bài tổng hợp, chỉ số khởi đầu nên là load outcome, journey outcome và thời gian từ navigation đến ready theo định nghĩa rõ ràng. Đừng tự chọn ngưỡng performance rồi gọi đó là chuẩn micro-frontend; ghi budget do bạn/team đặt và môi trường đo. Nếu có field measurement, tách nó khỏi số đo trên máy local.

Telemetry browser là best effort. Không nhận event không chứng minh không có lỗi; kiểm tra sức khỏe ingestion và dùng synthetic/browser tests bổ sung. Xem observability để thiết kế denominator, cancellation, sampling và metric labels trước khi tính SLI.

Chấm điểm và kết luậnCopy Anchor Link

Nếu chỉ cần nghiệm thu pass/fail, dùng gate và checkbox là đủ. Bảng điểm sau giúp so sánh tiến bộ qua các lần review; đây là rubric đề xuất cho bài học, không phải chuẩn chứng nhận kiến trúc.

Với mỗi tiêu chí áp dụng trong C1–C6, D1–D6, T1–T6, U1–U6 và O1–O6:

Mỗi nhóm quy đổi tối đa 10 điểm:

Điểm nhóm = 10 × tổng điểm tiêu chí áp dụng / (2 × số tiêu chí áp dụng)
Điểm tổng = tổng điểm của các nhóm có tiêu chí áp dụng

Giữ kết quả đến một chữ số thập phân để báo cáo, nhưng dùng giá trị chưa làm tròn khi xét ngưỡng. Nhóm không có tiêu chí áp dụng ghi N/A, không tự nhận 10 điểm. Báo cả số tiêu chí áp dụng, chẳng hạn “10/12 trên 6 tiêu chí”, để người đọc biết độ bao phủ scope.

Ví dụ minh họa: coupling có sáu tiêu chí với điểm 2, 2, 2, 1, 1, 2, tổng 10/12, nên điểm nhóm là khoảng 8,3/10. Đây không phải kết quả của repository hay một lab đã chạy trong trang này.

Với bài tổng hợp đủ năm nhóm, đề xuất kết luận như sau:

Với một lab hẹp, áp dụng ngưỡng theo nhóm còn trong scope và ghi kết luận đúng tên lab; không quy đổi một nhóm đã làm thành “42/50 tương đương”. Điểm nhóm cao cũng không có nghĩa mọi checkbox đạt — những tiêu chí còn thiếu vẫn phải xuất hiện trong phần hạn chế.

Một số sai lệch cần tránh khi review:

• “Có ba repo nên độc lập”: chưa có bằng chứng release.
• “Build pass nên tương thích”: chưa test runtime contract và semantics.
• “Có fallback nên resilient”: chưa test lỗi thực, recovery và retry limits.
• “Coverage cao nên an toàn”: chưa kiểm tra ownership, session race và artifact cũ/mới.
• “Có Console log nên observability đạt”: chưa biết attribution, release context hay privacy.

Mẫu biên bản đánh giáCopy Anchor Link

Sao chép mẫu vào nơi lưu evidence của workspace lab, không cần tạo file trong site docs. Dùng link tới test report hoặc artifact đã redact thay cho mô tả “đã test OK”.

**Đánh giá bài thực hành**

- Phạm vi: [lab ghép shop / routing-auth / deploy / bài tổng hợp]
- Ngày review:
- Reviewer:
- Commit/build:
- Môi trường và browser:
- Implementation: [React + Federation / native ESM / khác]
- Release set: shell=..., catalog=..., cart=...
- Config revision: ... hoặc N/A
- Policy state/session/cache:
- Mục N/A và lý do đã chấp thuận:

## Gate

| Gate | Trạng thái | Evidence |
| --- | --- | --- |
| G1 | Chưa kiểm tra | |
| G2 | Chưa kiểm tra | |
| G3 | Chưa kiểm tra | |
| G4 | Chưa kiểm tra | |
| G5 | Chưa kiểm tra | |

## Tiêu chí

Ghi từng mã áp dụng C1–O6, không gộp cả nhóm thành một dấu tick.

| Mã | Điểm | Evidence / bước tái hiện | Hạn chế | Owner |
| --- | --- | --- | --- | --- |
| C1 | | | | |
| D2 | | | | |
| T5 | | | | |
| U5 | | | | |
| O1 | | | | |

## Evidence chính

- Setup, fixture và lệnh chạy lại:
- Unit/component/contract report:
- Browser journey và failure trace đã redact:
- Digest before/after và pipeline log:
- Config trước promotion / sau promotion / rollback:
- Kết quả tab mới và tab cũ:
- Telemetry event/query và fault đã tạo:

## Kết luận

- Gate còn chặn nghiệm thu:
- Điểm từng nhóm và số tiêu chí áp dụng:
- Kết luận trong phạm vi đã chốt:
- Hạn chế chưa triển khai:
- Việc cần sửa, owner, điều kiện retest:

Không đưa record giả vào evidence để lấp ô trống. Nếu chưa chạy được một ca, ghi “chưa kiểm tra” cùng lý do; sự thiếu bằng chứng là thông tin cần dùng khi kết luận.

Ưu tiên sửa sau buổi reviewCopy Anchor Link

Sửa theo mức ảnh hưởng trước, không theo mục nào dễ tăng điểm nhất. Thứ tự khởi đầu hợp lý là lỗi gate về dữ liệu/session, lỗi làm mất shell hoặc sai kết quả command, coupling buộc release chung, rồi khoảng trống test và chẩn đoán.

Nếu badge và cart lệch nhau, sửa ownership thay vì thêm một event đồng bộ nữa. Nếu shell checksum đổi khi release catalog, tìm bước pipeline hoặc cấu hình URL tạo coupling. Nếu response Alice xuất hiện sau khi Bob login, sửa session scope và lifecycle trước khi thêm loading spinner.

Mỗi việc sửa nên gắn một mã tiêu chí và điều kiện retest cụ thể, ví dụ: “U5/G2 — resolve request Alice sau khi Bob đã mount; DOM chỉ chứa dữ liệu Bob”. Thêm regression test đúng boundary, chạy lại journey liên quan và cập nhật evidence của lần review mới.

Bắt đầu buổi đánh giá với một happy path, một remote load failure và một thay đổi release. Nếu có auth, thêm race logout. Những ca này nhanh chóng cho thấy boundary nào cần làm rõ trước khi bạn mở rộng bộ test.

Đọc tiếpCopy Anchor Link