DEV Community: Nghề không nhiều chẳng sắc

Environment Variable — Config Management

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:51 +0000

Quản lý config: validate env lúc khởi động, fail fast thay vì sập lúc chạy

Một ứng dụng cần cấu hình khác nhau theo môi trường — URL database, khóa API, cổng, feature flag — và cách chuẩn để truyền chúng vào mà không hard-code là environment variable. Nhưng process.env.X là string | undefined: nếu một biến bắt buộc bị thiếu hay sai định dạng, ứng dụng không biết cho tới khi chạm tới chỗ dùng nó — có thể là giữa một request quan trọng, hàng giờ sau khi deploy. Kỹ thuật cốt lõi là validate toàn bộ config một lần lúc khởi động và refuse to start nếu sai, biến một lỗi runtime mơ hồ thành một lỗi startup rõ ràng.

Cơ chế hoạt động

process.env chứa các biến do môi trường cung cấp; dotenv nạp file .env vào process.env lúc dev. Thay vì rải process.env.X khắp code, gom vào một module config được validate và ép kiểu một lần:

import { z } from 'zod'

const schema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']),
  PORT: z.coerce.number().default(3000),      // env là string -> ép số
  DATABASE_URL: z.string().url(),              // bắt buộc, đúng định dạng URL
  JWT_SECRET: z.string().min(32),              // bắt buộc, đủ dài
})

export const config = schema.parse(process.env) // throw NGAY lúc khởi động nếu thiếu/sai

schema.parse chạy một lần khi process khởi động: nếu DATABASE_URL thiếu hay JWT_SECRET quá ngắn, nó throw với thông báo rõ trước khi server nhận request nào. Phần còn lại của code import config đã được kiểm và đúng kiểu (số là số, không phải chuỗi).

Vấn đề gặp trong production

Failure mode: thiếu env phát hiện muộn. Không validate lúc khởi động, một biến thiếu chỉ lộ khi code chạm tới nó:

// rải khắp nơi, không kiểm trước
const token = jwt.sign(payload, process.env.JWT_SECRET) // undefined -> token rỗng/lỗi giữa request
await db.connect(process.env.DATABASE_URL)              // undefined -> lỗi mơ hồ khi kết nối

App khởi động "thành công", nhận traffic, rồi vỡ ở request đầu tiên chạm tới biến thiếu — hoặc tệ hơn, chạy với giá trị sai âm thầm (ký JWT với secret undefined). Validate lúc khởi động chuyển lỗi này về thời điểm deploy, nơi nó hiển nhiên và an toàn.

Failure mode: env là string, dùng như số/bool gây bug ngầm. process.env.PORT là "3000" (chuỗi), process.env.FEATURE_X là "false" (chuỗi "false" là truthy!):

if (process.env.FEATURE_X) { ... } // "false" là truthy -> luôn chạy, sai hoàn toàn
const timeout = process.env.TIMEOUT * 1000 // "30" * 1000 may work, nhưng "30s" -> NaN

Ép kiểu tường minh trong schema (coerce.number, parse boolean đúng cách) loại bỏ cả lớp bug này.

Failure mode: rò secret. Khóa API, DB password trong env tuyệt đối không được log hay commit. .env phải trong .gitignore; log config lúc khởi động phải che secret; secret production nên lấy từ secret manager (Vault, AWS Secrets Manager, biến môi trường của platform) chứ không phải file .env commit nhầm. Một secret lọt vào git history hay log là sự cố bảo mật thật.

Failure mode: lẫn build-time config với runtime config. Config nhúng lúc build (ví dụ biến VITE_/NEXT_PUBLIC_ của frontend) bị đóng băng vào bundle — đổi nó phải build lại, và nó công khai trong code client (không bao giờ để secret ở đây). Config runtime (đọc process.env lúc chạy ở server) đổi được không cần build lại. Nhầm hai loại dẫn tới "đổi env mà không có tác dụng" (vì đã nhúng lúc build) hoặc lộ secret ra client.

Cách debug và monitor

Nếu app "khởi động ổn rồi vỡ lúc chạy" với lỗi liên quan config, gần như chắc chưa validate env lúc khởi động — thêm một schema parse ở entry point để fail fast. Khi một feature flag boolean "luôn bật", kiểm tra nó có đang so sánh chuỗi "false" truthy không. Log danh sách biến config đã che secret lúc khởi động để xác nhận môi trường nạp đúng cái gì. Với "đổi env không có tác dụng", kiểm tra đó là build-time hay runtime config. Quét git history và log cho secret rò (công cụ như gitleaks); xoay (rotate) ngay secret nào từng lọt ra. Giữ một .env.example (không có giá trị thật) làm tài liệu các biến cần thiết.

Tradeoff

Validate config lúc khởi động tốn chút công viết schema, đổi lại biến mọi lỗi config (thiếu, sai định dạng, sai kiểu) thành một lỗi startup rõ ràng tại thời điểm deploy thay vì một crash mơ hồ giữa production — gần như luôn đáng. Gom config vào một module đã ép kiểu cũng cho phần còn lại của code dùng giá trị đúng kiểu, an toàn. Quy tắc thực tế: validate toàn bộ env một lần lúc khởi động với một schema (zod hoặc tương đương), fail fast nếu sai; ép kiểu tường minh (số/bool) thay vì dùng chuỗi trực tiếp; không bao giờ log/commit secret, dùng secret manager cho production; phân biệt rõ build-time và runtime config; và giữ .env.example làm tài liệu. Chi phí nhỏ trả trước đổi lấy không có sự cố config âm thầm.

Câu hỏi phỏng vấn

Tại sao nên validate env lúc khởi động, và những bẫy nào khi dùng process.env?

Nên validate env lúc khởi động vì process.env.X là string | undefined: không kiểm trước thì một biến bắt buộc bị thiếu hay sai định dạng chỉ lộ khi code chạm tới nó — có thể giữa một request quan trọng hàng giờ sau deploy, hoặc tệ hơn chạy âm thầm với giá trị sai (ký JWT với secret undefined). Validate toàn bộ config một lần bằng một schema (zod) ở entry point biến lỗi đó thành một lỗi startup rõ ràng tại thời điểm deploy — fail fast, an toàn. Các bẫy của process.env: env luôn là string nên if (process.env.FLAG) với "false" vẫn truthy (luôn chạy), và phép tính trên chuỗi ra NaN — phải ép kiểu tường minh; rò secret nếu log/commit (.env phải trong .gitignore, dùng secret manager cho production); và lẫn build-time config (nhúng vào bundle, công khai ở client, đổi phải build lại) với runtime config. Điểm ăn điểm: gom config vào một module đã validate và ép kiểu để phần còn lại dùng giá trị đúng kiểu, giữ .env.example làm tài liệu, và rotate ngay secret từng lọt ra.

Hands-on

Viết một config loader thật dùng zod (hoặc tương đương): khai schema cho NODE_ENV, PORT (ép số, có default), DATABASE_URL (url bắt buộc), JWT_SECRET (độ dài tối thiểu), parse process.env một lần ở entry point và export object đã ép kiểu. Xóa một biến bắt buộc và chạy app để thấy nó fail ngay lúc khởi động với thông báo rõ thay vì vỡ lúc chạy. Tạo một feature flag boolean đọc thẳng process.env với giá trị "false" để tái hiện bug truthy, rồi sửa bằng parse boolean trong schema. Thêm .env vào .gitignore, tạo .env.example, và chạy gitleaks trên repo để xác nhận không có secret nào lọt vào history; cuối cùng phân biệt một biến build-time (frontend) với một biến runtime (server) và quan sát đổi biến build-time không có tác dụng tới khi build lại.

Semantic Versioning — SemVer

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:48 +0000

SemVer: ý nghĩa của ^ và ~, và vì sao một "minor update" vẫn làm vỡ build

Semantic Versioning đặt một hợp đồng lên số phiên bản MAJOR.MINOR.PATCH: tăng MAJOR = có breaking change, MINOR = thêm tính năng tương thích ngược, PATCH = vá lỗi tương thích ngược. Range specifier ^ và ~ trong package.json quyết định npm tự nâng tới đâu trong hợp đồng đó. Hiểu chúng là điều kiện để kiểm soát chuyện "tự dưng build vỡ sau khi cài lại" — vì range cho phép nâng tự động, và SemVer là lời hứa của maintainer, không phải đảm bảo: một bản "minor" hay "patch" vẫn có thể vô tình chứa breaking change.

Cơ chế hoạt động

^ cho phép nâng minor và patch (giữ nguyên major); ~ chỉ cho phép nâng patch:

{
  "express":  "^4.18.0",  // chấp nhận >=4.18.0 và <5.0.0  (minor + patch)
  "lodash":   "~4.17.21", // chấp nhận >=4.17.21 và <4.18.0 (chỉ patch)
  "react":    "18.2.0"    // ghim chính xác — không tự nâng gì
}

Khi cài lại không có lockfile, npm lấy phiên bản cao nhất khớp range. Nên ^4.18.0 có thể resolve thành 4.19.5 ở lần cài sau nếu maintainer phát hành thêm — đây là chỗ "tự nâng" xảy ra. Lockfile cố định phiên bản thực tế bất kể range, nên hai cùng tồn tại: range nói "được nâng tới đâu", lockfile nói "đang dùng đúng cái nào".

Vấn đề gặp trong production

Failure mode: breaking change lọt qua minor/patch. SemVer là quy ước con người tuân thủ, không phải máy ép. Một maintainer có thể vô tình (hoặc do hiểu khác về "breaking") đưa một thay đổi phá tương thích vào bản minor hoặc patch. Vì range ^/~ tự nhận các bản đó, build có thể vỡ sau khi cài lại dù bạn "không đổi gì". Đây là lý do lockfile + npm ci quan trọng: chúng chặn việc tự nâng ngoài ý muốn, để nâng cấp luôn là một hành động có chủ đích, được test.

Failure mode: nâng major mà không đọc changelog. Tăng major nghĩa là có breaking change — nâng express@4 lên express@5 mà không đọc migration guide gần như chắc chắn vỡ. Major update phải được xử lý như một task riêng: đọc changelog, sửa code theo, test kỹ, không gộp chung với thay đổi khác.

Failure mode: ghim quá chặt làm bỏ lỡ bản vá bảo mật. Ngược lại với nâng mù: ghim cứng mọi dependency và không bao giờ cập nhật khiến bỏ lỡ các patch vá lỗ hổng. Cân bằng: cho phép patch tự động (an toàn nhất theo SemVer) cho phần lớn, ghim chặt phần cực nhạy cảm, và có quy trình cập nhật minor/major định kỳ có kiểm soát.

Failure mode: pre-release và 0.x hành xử khác. Phiên bản 0.x.y không theo hợp đồng major thông thường — trong 0.x, một bản minor có thể chứa breaking change (vì API chưa ổn định). ^0.2.3 chỉ cho phép tới <0.3.0, không phải <1.0.0. Dependency 0.x cần thận trọng hơn vì chưa cam kết ổn định.

Cách debug và monitor

Khi "build vỡ mà không đổi code", kiểm tra lockfile có được commit và CI có dùng npm ci không — nếu CI chạy npm install không lockfile, nó có thể đã tự nâng qua range. So sánh lockfile giữa lần chạy được và lần vỡ (git diff trên lockfile) để xác định package nào đã đổi phiên bản. Khi cố tình nâng, đọc changelog cho khoảng phiên bản đó và chạy full test suite. Dùng Dependabot/Renovate để nhận PR nâng cấp riêng lẻ kèm changelog — mỗi nâng cấp là một PR test được độc lập, thay vì nâng hàng loạt khó truy lỗi. Theo dõi npm outdated để thấy khoảng cách giữa phiên bản đang dùng và mới nhất.

Tradeoff

Range rộng (^) nhận tính năng và vá nhanh, ít phải sửa package.json, nhưng rủi ro tự nâng vào một bản vô tình breaking. Ghim chặt ổn định và tái lập tuyệt đối nhưng chậm nhận vá (gồm vá bảo mật) và tốn công cập nhật thủ công. Quy tắc thực tế: dùng ^/~ trong package.json để khai ý định, nhưng dựa vào lockfile + npm ci để kiểm soát phiên bản thực tế ở mọi môi trường; nâng cấp là hành động có chủ đích (đọc changelog, test, một PR mỗi nâng cấp), không phải hệ quả ngẫu nhiên của việc cài lại; cho phép patch tự động, xử lý major như task riêng, và thận trọng đặc biệt với dependency 0.x. Cân giữa "cập nhật" và "ổn định" theo mức quan trọng.

Câu hỏi phỏng vấn

^ và ~ khác gì nhau, và vì sao một bản minor/patch vẫn có thể làm vỡ build?

^ cho phép npm nâng tự động trong cùng major — cả minor và patch (^4.18.0 = >=4.18.0 <5.0.0); ~ chỉ cho phép nâng patch (~4.17.21 = >=4.17.21 <4.18.0); ghim chính xác (18.2.0) không tự nâng gì. Khi cài lại không có lockfile, npm lấy phiên bản cao nhất khớp range, nên ^ có thể tự nhảy lên một minor mới. Một bản minor/patch vẫn có thể làm vỡ build vì SemVer là quy ước con người tuân thủ, không phải đảm bảo do máy ép: maintainer có thể vô tình đưa breaking change vào bản đáng lẽ tương thích ngược, và range ^/~ sẽ tự nhận nó — build vỡ dù "không đổi gì". Điểm ăn điểm: vì vậy phải commit lockfile và dùng npm ci để chặn tự nâng ngoài ý muốn (nâng cấp luôn là hành động có chủ đích, được test, mỗi PR một nâng cấp), xử lý major như task riêng có đọc changelog, cho phép patch tự động để không bỏ lỡ vá bảo mật, và lưu ý 0.x không theo hợp đồng major thông thường nên minor trong 0.x có thể breaking.

Hands-on

Tạo một package.json với một dependency khai ^, một khai ~, và một ghim chính xác; chạy npm outdated để thấy khoảng cách tới bản mới nhất và lý giải bản nào sẽ tự nâng tới đâu. Xóa lockfile, cài lại, và so sánh phiên bản resolve để thấy ^ có thể nhảy minor; rồi khôi phục lockfile và dùng npm ci để xác nhận nó cố định. Nâng một package qua một bản major thật (ví dụ một thư viện có breaking change), đọc changelog, sửa code theo migration guide, và chạy test để cảm nhận vì sao major là task riêng. Cuối cùng cấu hình Renovate/Dependabot trên một repo và quan sát mỗi nâng cấp đến dưới dạng một PR riêng kèm changelog.

npm Ecosystem — Dependency Management

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:46 +0000

Quản lý dependency: lockfile, ba loại dependency, và rủi ro supply chain

Một dự án Node thực tế kéo theo hàng trăm tới hàng nghìn package gián tiếp. Quản lý chúng không chỉ là npm install — mà là kiểm soát chính xác phiên bản nào chạy ở production (lockfile), phân loại đúng dependency nào cần lúc chạy / lúc dev / do host cung cấp, và phòng các package độc hại hoặc dính lỗ hổng (supply chain). Làm ẩu ở đây dẫn tới "chạy được trên máy tôi" do lệch phiên bản, hoặc tệ hơn, một package bị chiếm quyền tiêm mã độc vào build.

Cơ chế hoạt động

package.json khai dải phiên bản chấp nhận ("^4.18.0"); lockfile (package-lock.json/yarn.lock/pnpm-lock.yaml) ghi chính xác phiên bản đã resolve cho từng package, kể cả gián tiếp. npm ci cài đúng theo lockfile — đây là lệnh dùng ở CI/production để build tái lập được.

{
  "dependencies":    { "express": "^4.18.0" },  // cần lúc runtime -> vào production
  "devDependencies": { "jest": "^29.0.0" },     // chỉ lúc dev/test -> KHÔNG vào production
  "peerDependencies":{ "react": ">=18" }         // host phải cung cấp; package không tự cài
}

Ba loại khác mục đích: dependencies đi cùng app khi chạy; devDependencies chỉ cho dev (build, test, lint) và bị bỏ khi npm install --production; peerDependencies là cách một thư viện nói "tôi cần host có React 18, nhưng tôi không tự mang React để tránh hai bản React xung đột".

Vấn đề gặp trong production

Failure mode: không commit lockfile / không dùng npm ci. Nếu CI chạy npm install không có lockfile, nó resolve lại dải ^ và có thể lấy phiên bản mới hơn lúc dev — "chạy được trên máy tôi" vì máy dev có lockfile cũ còn CI thì không. Lockfile phải được commit, và CI/production dùng npm ci (cài đúng lockfile, fail nếu lệch) để mọi môi trường chạy cùng cây phụ thuộc.

Failure mode: phân loại sai dependency. Để một thư viện build (TypeScript, một bundler) trong dependencies làm image production phình và chứa thứ không cần; ngược lại để một package runtime trong devDependencies làm production thiếu module lúc chạy (Cannot find module chỉ trên production sau khi --production). Phân loại đúng theo "có cần khi app chạy không".

Failure mode: supply chain attack. Đây là rủi ro nghiêm trọng và thực tế: một package (thường là dependency gián tiếp sâu) bị chiếm tài khoản maintainer hoặc bị chèn mã độc trong một bản phát hành mới, và mọi dự án tự động nâng qua dải ^ sẽ kéo bản độc về. Phòng vệ: lockfile (không tự nhảy phiên bản), npm audit quét lỗ hổng đã biết, ghim phiên bản cho dependency nhạy cảm, và xem kỹ trước khi thêm package mới (số lượt dùng, lịch sử bảo trì, số dependency con). Càng ít dependency, bề mặt tấn công càng nhỏ.

Failure mode: dependency trùng lặp/xung đột phiên bản. Hai package cần hai phiên bản khác nhau của cùng một thư viện làm cây phình và đôi khi gây bug tinh vi (hai bản của cùng một lib không nhận nhau). npm dedupe gom bớt; với thư viện cần một bản dùng chung (như React), peerDependencies là cơ chế tránh trùng.

Cách debug và monitor

"Chạy được local, lỗi trên CI/production" với khác biệt hành vi package — kiểm tra lockfile đã commit chưa và CI có dùng npm ci không. Cannot find module chỉ trên production sau khi cài --production nghĩa là một runtime dependency bị xếp nhầm vào devDependencies. Chạy npm audit định kỳ (và trong CI) để bắt lỗ hổng đã biết; tích hợp một công cụ như Dependabot/Renovate để được cảnh báo và nâng có kiểm soát. Theo dõi kích thước cây phụ thuộc (npm ls) — tăng đột biến khi thêm một package nhỏ nghĩa là nó kéo theo nhiều dependency con, cân nhắc lại. Trước khi thêm package, kiểm tra độ phổ biến, tần suất bảo trì, và số dependency con.

Tradeoff

Dùng package mới nhất có tính năng và vá lỗi mới — đổi lại rủi ro breaking change và (với bản vừa phát hành) rủi ro supply chain chưa kịp phát hiện. Ghim phiên bản và cập nhật có kiểm soát thì ổn định và an toàn hơn, đổi lại chậm nhận tính năng/vá. Quy tắc thực tế: luôn commit lockfile và dùng npm ci ở CI/production để build tái lập; phân loại dependency đúng theo nhu cầu runtime; chạy npm audit và cập nhật theo lịch có kiểm soát (đọc changelog, test) thay vì nâng mù; giữ số dependency tối thiểu để giảm bề mặt tấn công. Cân giữa "mới" và "ổn định" theo mức độ quan trọng của hệ thống.

Câu hỏi phỏng vấn

peerDependency dùng khi nào, và vì sao phải commit lockfile và dùng npm ci?

peerDependencies dùng khi một thư viện cần host cung cấp một package chung thay vì tự mang theo — điển hình là plugin/component library cần React: khai React là peer dependency để package không tự cài React riêng, tránh việc có hai bản React trong cây gây xung đột (hook không hoạt động, context không khớp). Phải commit lockfile vì package.json chỉ khai dải phiên bản (^4.18.0) còn lockfile ghi chính xác phiên bản đã resolve cho mọi package gồm gián tiếp; không có nó, mỗi lần cài có thể resolve ra phiên bản khác, gây "chạy được trên máy tôi". npm ci cài đúng theo lockfile và fail nếu lệch, nên dùng ở CI/production để mọi môi trường chạy cùng cây phụ thuộc, build tái lập được. Điểm ăn điểm: lockfile + npm ci cũng là phòng vệ supply chain (không tự nhảy sang bản độc qua dải ^), kết hợp npm audit, ghim phiên bản nhạy cảm, và giữ ít dependency để giảm bề mặt tấn công; phân loại sai runtime dependency vào devDependencies gây Cannot find module chỉ trên production.

Hands-on

Lấy một dự án thật, xóa node_modules và cài bằng npm install không lockfile rồi bằng npm ci có lockfile, so sánh cây phụ thuộc resolve ra để thấy vì sao lockfile + npm ci cho build tái lập. Cố tình xếp một runtime dependency vào devDependencies, chạy npm install --production, và quan sát Cannot find module lúc chạy — rồi sửa phân loại. Chạy npm audit để xem các lỗ hổng đã biết và thử nâng một package có lỗ hổng theo cách có kiểm soát (đọc changelog, test). Cuối cùng thêm một package nhỏ và dùng npm ls để thấy nó kéo theo bao nhiêu dependency con, đánh giá bề mặt tấn công tăng thêm.

Module System — Module Resolution

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:43 +0000

Module resolution: cách runtime tìm file một import, và vì sao alias hay vỡ

Khi viết import { x } from './utils' hay import x from 'lodash', có một thuật toán quyết định file nào thực sự được load. Hiểu thuật toán này là điều kiện để gỡ lỗi "Cannot find module" — lỗi xuất hiện nhiều khi cấu hình path alias (@/components), vì alias do công cụ build hiểu, không phải Node hiểu sẵn, nên dễ vỡ khi một mắt xích (TypeScript, bundler, runtime, test) không được cấu hình khớp. Đây là nguồn của loại bug khó chịu "chạy được lúc dev, lỗi lúc build/test/production".

Cơ chế hoạt động

Node phân biệt hai loại đường dẫn. Đường dẫn tương đối/tuyệt đối (./, ../, /) resolve trực tiếp tới file, thử các đuôi (.js, .json...) và index. Đường dẫn "bare" (lodash, @scope/pkg) là package: Node leo các thư mục node_modules từ file hiện tại lên gốc, và trong mỗi package đọc package.json ("main", "exports", "module") để biết file vào.

import './utils'        // file: ./utils.js hoặc ./utils/index.js
import 'lodash'         // package: node_modules/lodash, đọc package.json
import '@/components/Button' // alias: KHÔNG phải cú pháp Node — cần công cụ map lại

Alias (@/...) không có ý nghĩa với Node thuần. Nó được khai trong tsconfig.json (compilerOptions.paths) cho TypeScript hiểu lúc compile, và phải được khai song song trong mọi công cụ khác chạm tới code: bundler (webpack resolve.alias, vite resolve.alias), test runner (Jest moduleNameMapper), và runtime nếu chạy thẳng. tsconfig paths chỉ dạy compiler — nó không tự đổi đường dẫn trong output, nên thiếu cấu hình ở tầng chạy là vỡ.

Vấn đề gặp trong production

Failure mode: alias chạy dev nhưng vỡ ở build/test/runtime. Đây là cái bẫy kinh điển. tsconfig.json có paths: { "@/*": ["src/*"] } nên editor và tsc không báo lỗi, nhưng:

- Jest không biết @/ -> test fail "Cannot find module '@/utils'"
- Bundler không cấu hình alias -> build fail
- Chạy file đã compile bằng node -> runtime "Cannot find module '@/utils'"

Vì tsconfig paths chỉ phục vụ type-check, mỗi công cụ khác cần cấu hình alias riêng của nó. Bỏ sót một công cụ là một môi trường vỡ. Khi đổi alias, phải đổi đồng bộ ở tất cả các nơi.

Failure mode: sai alias trỏ tới nơi không tồn tại gây lỗi runtime. Một alias cấu hình lệch (trỏ src/ nhưng output ở dist/) compile sạch nhưng runtime không tìm thấy file. Vì lỗi chỉ xuất hiện lúc chạy chứ không lúc type-check, nó lọt qua tới khi thực thi.

Failure mode: case-sensitivity giữa máy dev và server. macOS không phân biệt hoa/thường trong tên file, Linux (server/CI) thì có. import './Button' trỏ file button.tsx chạy ngon trên Mac, vỡ "Cannot find module" trên CI/production Linux. Đây là một trong những lỗi "chỉ vỡ trên CI" hay gặp nhất.

Failure mode: exports field chặn deep import. Package hiện đại dùng "exports" trong package.json để khai các entry hợp lệ; import sâu vào file nội bộ (pkg/lib/internal) không được liệt kê sẽ bị chặn dù file tồn tại. Phải dùng entry point package công bố.

Cách debug và monitor

"Cannot find module" — bước đầu xác định loại: alias (@/) hay package hay tương đối. Nếu alias, kiểm tra alias đã khai ở mọi công cụ (tsconfig + bundler + test + runtime) chưa, và trỏ đúng thư mục output không. Nếu chỉ vỡ trên CI mà chạy được local, nghi case-sensitivity — kiểm tra hoa/thường tên file khớp chính xác import. Với package, kiểm tra package.json "exports" có cho phép đường dẫn đang import không. Bật forceConsistentCasingInFileNames trong tsconfig để bắt lỗi hoa/thường lúc compile thay vì để CI phát hiện. Khi cấu hình alias mới, chạy cả build, test, và runtime — không chỉ dev server — trước khi tin nó hoạt động.

Tradeoff

Path alias làm import dễ đọc và ổn định (@/components/Button thay vì ../../../components/Button), tránh chuỗi ../ dài và khỏi sửa import khi di chuyển file. Cái giá là tăng độ phức tạp build: phải cấu hình alias đồng bộ ở mọi công cụ, và một mắt xích thiếu là một môi trường vỡ — đúng loại lỗi khó chịu vì lệch giữa dev và build/CI. Quy tắc thực tế: dùng alias cho gốc dự án (@/) để tránh ../ sâu, nhưng giữ cấu hình tập trung và đồng bộ qua tất cả công cụ; bật forceConsistentCasingInFileNames; và luôn xác nhận alias hoạt động ở build/test/runtime chứ không chỉ editor. Với dự án nhỏ, import tương đối có khi đơn giản hơn là gánh đồng bộ alias.

Câu hỏi phỏng vấn

Node resolve một module như thế nào, và vì sao path alias chạy được lúc dev nhưng vỡ lúc build hoặc test?

Node phân biệt đường dẫn tương đối/tuyệt đối (./, /) — resolve trực tiếp tới file, thử các đuôi và index — với đường dẫn "bare" (lodash) — leo các node_modules từ file hiện tại lên gốc và đọc package.json (main/exports/module) để tìm entry. Path alias như @/components không phải cú pháp Node hiểu sẵn: nó được khai trong tsconfig.json paths để TypeScript hiểu lúc type-check, nhưng tsconfig paths không tự đổi đường dẫn trong output. Nên alias chạy được lúc dev (editor/tsc hiểu) nhưng vỡ ở build/test/runtime nếu các công cụ đó — bundler (resolve.alias), test runner (Jest moduleNameMapper), runtime — chưa được cấu hình alias riêng; mỗi mắt xích thiếu là một môi trường "Cannot find module". Điểm ăn điểm: nêu thêm case-sensitivity (chạy trên Mac vỡ trên CI Linux, bật forceConsistentCasingInFileNames), exports field chặn deep import, và quy tắc luôn kiểm alias ở build/test/runtime chứ không chỉ dev.

Hands-on

Cấu hình một path alias @/* → src/* chỉ trong tsconfig.json và quan sát editor/tsc không báo lỗi, rồi chạy test (Jest) và build (vite/webpack) để thấy chúng fail "Cannot find module" — sau đó thêm alias tương ứng vào moduleNameMapper và resolve.alias để cả ba môi trường cùng chạy. Đổi tên một file thành chữ thường nhưng giữ import viết hoa, chạy local trên Mac thấy OK rồi chạy trên một container Linux để tái hiện lỗi CI, và bật forceConsistentCasingInFileNames để bắt nó lúc compile. Cuối cùng thử deep-import vào một file nội bộ của một package có "exports" để gặp lỗi bị chặn, và sửa bằng cách dùng entry point công bố.

Module System — CommonJS vs ESM

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:40 +0000

CommonJS vs ESM: hai hệ module, vì sao trộn chúng gây lỗi build

JavaScript có hai hệ module song song: CommonJS (CJS — require/module.exports, hệ cũ của Node) và ES Modules (ESM — import/export, chuẩn của ngôn ngữ). Chúng khác nhau ở bản chất chứ không chỉ cú pháp: CJS load đồng bộ tại runtime, ESM phân giải tĩnh trước khi chạy. Khác biệt đó là lý do tree-shaking chỉ làm được tốt với ESM, là lý do import một package CJS đôi khi lấy sai default, và là nguồn của hàng loạt lỗi build "Cannot use import statement outside a module" / "require is not defined" khi một dự án trộn cả hai. Đây là kiến thức bắt buộc khi migrate hoặc tích hợp package.

Cơ chế hoạt động

CJS: module được resolve và thực thi khi require chạy; export là một object có thể đổi lúc runtime. ESM: import/export là tĩnh — phân giải lúc parse, trước khi code chạy, nên bundler biết chính xác cái gì được import và loại bỏ phần không dùng (tree-shaking).

// CommonJS
const lodash = require('lodash')      // đồng bộ, lấy cả module
module.exports = { foo }

// ESM
import { debounce } from 'lodash-es'  // tĩnh, tree-shakeable -> chỉ debounce vào bundle
export const foo = () => {}

Trong Node, hệ module được quyết định bởi "type" trong package.json ("module" = ESM, mặc định/"commonjs" = CJS) hoặc đuôi file (.mjs = ESM, .cjs = CJS). ESM hỗ trợ import() động (trả Promise) để load điều kiện/lười; CJS dùng require ngay tại chỗ.

Vấn đề gặp trong production

Failure mode: ESM không require được, CJS không import tĩnh dễ dàng. Một module ESM không thể require (nó async); và import một package CJS đôi khi cần lấy qua default thay vì named import, vì CJS không có named export tĩnh thật:

// package CJS, import từ ESM:
import pkg from 'some-cjs-lib'        // OK: lấy module.exports qua default
import { thing } from 'some-cjs-lib'  // có thể lỗi: 'thing' không phải named export tĩnh

Lỗi "named export not found" khi import một package CJS từ ESM là tình huống cực phổ biến. Cách xử lý: import default rồi destructure, hoặc dùng bản ESM của package nếu có.

Failure mode: lỗi build/runtime khi trộn không nhất quán. "Cannot use import statement outside a module" (chạy ESM ở context CJS), "require is not defined in ES module scope", hay lỗi khi một file .js được hiểu nhầm hệ — gần như luôn do "type" trong package.json không khớp cú pháp dùng. Một dự án nên nhất quán một hệ; khi buộc trộn, dùng đuôi .mjs/.cjs rõ ràng cho phần khác hệ.

Failure mode: circular dependency hành xử khác nhau. Cả hai hệ xử lý import vòng nhưng khác: CJS trả về export một phần (những gì đã chạy tới thời điểm đó), dễ ra undefined ngầm; ESM dùng live binding nên thường an toàn hơn nhưng vẫn lỗi nếu dùng giá trị trước khi nó khởi tạo. Vòng phụ thuộc là dấu hiệu thiết kế cần tách, độc lập với hệ module.

Failure mode: tree-shaking không hiệu quả với CJS. Vì CJS động (export đổi được lúc runtime), bundler không loại an toàn được phần không dùng — import một package CJS lớn có thể kéo cả nó vào bundle dù chỉ dùng một hàm. Dùng bản ESM (lodash-es thay lodash) để tree-shaking ăn.

Cách debug và monitor

Khi gặp "Cannot use import statement outside a module" hoặc "require is not defined", kiểm tra "type" trong package.json và đuôi file có khớp cú pháp đang dùng không — đây là nguyên nhân số một. Lỗi "does not provide an export named X" khi import package: package đó là CJS, đổi sang default import. Để đo bundle phình do CJS, dùng bundle analyzer xem package nào vào trọn vẹn dù chỉ dùng một phần — đổi sang bản ESM nếu có. Khi migrate CJS→ESM, làm từng phần và chạy test sau mỗi bước; chú ý các thứ chỉ CJS có (__dirname, require.main) phải thay bằng tương đương ESM (import.meta.url).

Tradeoff

ESM là chuẩn của ngôn ngữ, hỗ trợ tree-shaking và phân tích tĩnh tốt hơn, là hướng đi tương lai — đổi lại ecosystem chưa đồng đều: nhiều package vẫn CJS, và trộn hai hệ gây lỗi tích hợp thật. CJS chín, tương thích rộng, đơn giản (đồng bộ) nhưng không tree-shake tốt và không phải chuẩn. Quy tắc thực tế cho dự án mới: dùng ESM nhất quán, ưu tiên package có bản ESM; khi buộc dùng package CJS, import default; giữ một hệ trong toàn dự án và chỉ dùng .mjs/.cjs khi thật sự cần trộn. Migrate khi lợi ích (tree-shaking, chuẩn hóa) vượt chi phí xử lý tương thích.

Câu hỏi phỏng vấn

CommonJS khác ESM ở đâu, và vì sao tree-shaking chỉ hiệu quả với ESM?

CommonJS dùng require/module.exports, load đồng bộ tại runtime, và export là object có thể thay đổi lúc chạy; ESM dùng import/export, phân giải tĩnh trước khi chạy (lúc parse), hỗ trợ import() động trả Promise. Trong Node, hệ được quyết bởi "type" trong package.json hoặc đuôi .mjs/.cjs. Tree-shaking chỉ hiệu quả với ESM vì cấu trúc import/export là tĩnh — bundler biết chắc lúc build cái gì được import và loại bỏ an toàn phần không dùng; còn CJS động nên export có thể đổi lúc runtime, bundler không thể loại an toàn và thường kéo cả package vào bundle. Điểm ăn điểm: nêu các lỗi thực tế khi trộn ("Cannot use import statement outside a module", "require is not defined", named export not found khi import package CJS — phải dùng default import), khác biệt xử lý circular dependency (CJS trả export một phần dễ ra undefined, ESM live binding), và lời khuyên giữ một hệ nhất quán, ưu tiên ESM cho dự án mới.

Hands-on

Lấy một dự án Node CJS thật và migrate sang ESM: đổi "type": "module" trong package.json, chuyển require/module.exports sang import/export, thay __dirname bằng import.meta.url, và chạy test sau mỗi bước để bắt lỗi tương thích. Cố tình import một named export từ một package CJS để tái hiện lỗi "does not provide an export named", rồi sửa bằng default import. Dùng bundle analyzer so sánh kích thước bundle khi import lodash (CJS) chỉ dùng một hàm so với lodash-es (ESM) để thấy tree-shaking hoạt động. Cuối cùng dựng một circular dependency và quan sát khác biệt hành vi giữa chạy ở CJS và ESM.

Big O — Complexity Analysis

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:38 +0000

Big O: vì sao O(n²) chạy tốt khi demo rồi sập khi dữ liệu lớn

Big O mô tả độ phức tạp của thuật toán tăng theo kích thước input như thế nào — không phải thời gian tuyệt đối, mà tốc độ tăng. Đây là công cụ để dự đoán code sẽ giữ vững hay sập khi dữ liệu lớn lên, trước khi nó xảy ra trong production. Lý do thực tế: một thuật toán O(n²) chạy mượt với 100 phần tử lúc dev (10.000 thao tác) nhưng với 100.000 phần tử ở production là 10 tỷ thao tác — CPU spike, request timeout. Hiểu Big O biến "tự dưng chậm khi nhiều dữ liệu" thành thứ đoán trước được và chữa được bằng cách đổi cấu trúc dữ liệu.

Cơ chế hoạt động

Big O đếm thao tác theo n (kích thước input), bỏ qua hằng số và số hạng bậc thấp. Các bậc thường gặp, từ tốt tới xấu: O(1) hằng số, O(log n) tìm kiếm nhị phân, O(n) duyệt một lần, O(n log n) sort, O(n²) vòng lặp lồng, O(2ⁿ) đệ quy phân nhánh.

// O(n²): với mỗi phần tử, quét lại cả mảng tìm trùng
function hasDuplicate(arr) {
  for (let i = 0; i < arr.length; i++)
    for (let j = i + 1; j < arr.length; j++)
      if (arr[i] === arr[j]) return true
  return false
}

// O(n): dùng Set, đổi việc "tìm trong mảng" O(n) thành "tra Set" O(1)
function hasDuplicate(arr) {
  const seen = new Set()
  for (const x of arr) {
    if (seen.has(x)) return true // tra O(1)
    seen.add(x)
  }
  return false
}

Mấu chốt phổ biến nhất: một vòng lặp lồng để tìm kiếm bên trong thường là O(n²), và gần như luôn hạ được xuống O(n) bằng một Set/Map (hash) — đổi việc dò tuyến tính thành tra cứu hằng số. Cùng kết quả, khác hẳn về khả năng chịu tải.

Vấn đề gặp trong production

Failure mode: O(n²) ẩn trong vòng lặp lồng. Lỗi hiệu năng phổ biến nhất ở backend: với mỗi phần tử của danh sách A, tìm phần tử tương ứng trong danh sách B bằng find/includes/filter:

// O(n*m): với mỗi order, quét toàn bộ users để tìm tên -> sập khi cả hai lớn
const result = orders.map(o => ({ ...o, userName: users.find(u => u.id === o.userId).name }))

// O(n+m): dựng Map một lần, tra O(1)
const userMap = new Map(users.map(u => [u.id, u]))
const result = orders.map(o => ({ ...o, userName: userMap.get(o.userId)?.name }))

.find bên trong .map là dấu hiệu kinh điển — nó ẩn một vòng lặp lồng. Với dữ liệu test nhỏ không thấy gì; với dữ liệu thật, thời gian tăng theo bình phương.

Failure mode: tối ưu sai chỗ (premature optimization). Ngược lại, vi chỉnh một đoạn O(n) chạy một lần lúc khởi động, hay đổi code rõ ràng thành code khó đọc để tiết kiệm vài mili-giây ở chỗ không nóng, là phí công và thêm rủi ro bug. Big O chỉ quan trọng ở nơi n lớn và tăng; với n nhỏ cố định, hằng số và độ dễ đọc quan trọng hơn bậc.

Failure mode: bỏ qua space complexity. Đôi khi đổi thời gian lấy bộ nhớ (dựng Map để tra nhanh tốn RAM bằng kích thước dữ liệu). Với dữ liệu rất lớn, một giải pháp O(n) thời gian nhưng O(n) bộ nhớ có thể OOM — cần cân cả hai trục.

Cách debug và monitor

Khi một endpoint chậm dần theo lượng dữ liệu (nhanh trên staging, chậm trên production), nghi ngay một bậc phức tạp xấu — đo thời gian theo kích thước input thực tế, nếu thời gian tăng theo bình phương khi n gấp đôi thì là O(n²). Tìm trong code các vòng lặp lồng và đặc biệt .find/.includes/.indexOf bên trong .map/.forEach/vòng lặp — đó là O(n²) trá hình. Profiler (CPU flame graph) chỉ ra hàm chiếm thời gian; nếu nó là một vòng lặp tìm kiếm, hạ bằng hash. Theo dõi độ trễ theo phân vị (p99) khi dữ liệu tăng — bậc xấu lộ ra ở đuôi trước. Đừng tối ưu khi chưa đo: xác định hot path bằng profiler thật rồi mới sửa.

Tradeoff

Thuật toán bậc thấp hơn (O(n) thay O(n²)) chịu tải tốt hơn nhiều khi dữ liệu lớn — đây là khác biệt giữa "giữ được" và "sập". Cái giá đôi khi là code phức tạp hơn (dựng cấu trúc phụ) và tốn bộ nhớ hơn (đổi time lấy space). Nhưng tối ưu sai chỗ — vi chỉnh nơi n nhỏ hoặc không nóng — chỉ thêm độ khó đọc và rủi ro mà không lợi. Quy tắc thực tế: viết code rõ ràng trước; đo để tìm hot path thật; ở hot path có n lớn, ưu tiên hạ bậc (vòng lặp lồng → hash); cân cả space khi dữ liệu rất lớn; và bỏ qua tối ưu ở chỗ n nhỏ cố định nơi độ dễ đọc đáng giá hơn.

Câu hỏi phỏng vấn

Làm sao HashMap giảm một thuật toán từ O(n²) xuống O(n), và khi nào KHÔNG nên tối ưu?

Một thuật toán O(n²) điển hình là vòng lặp lồng để tìm kiếm: với mỗi phần tử của danh sách A, quét tuyến tính danh sách B (find/includes) — mỗi lần tìm tốn O(n), nhân với n phần tử thành O(n²). HashMap/Set hạ xuống O(n) bằng cách dựng một bảng tra một lần (O(n)) rồi mỗi lần tìm chỉ tốn O(1), tổng O(n+m): đổi "dò tuyến tính lặp lại" thành "tra cứu hằng số". Đây là vì sao .find bên trong .map nên thay bằng Map.get. KHÔNG nên tối ưu khi n nhỏ và cố định hoặc đoạn code không nằm trên hot path — vi chỉnh ở đó chỉ làm code khó đọc và thêm rủi ro mà không cải thiện thực tế (premature optimization); ưu tiên độ rõ ràng, đo bằng profiler để tìm hot path thật rồi mới sửa. Điểm ăn điểm: cân cả space complexity (dựng Map tốn RAM, dữ liệu rất lớn có thể OOM) và theo dõi độ trễ p99 khi dữ liệu tăng vì bậc xấu lộ ở đuôi trước.

Hands-on

Lấy một đoạn ghép dữ liệu thật có .find/.includes bên trong .map (ví dụ gắn tên user vào danh sách order, hoặc tìm trùng trong một danh sách) và đo thời gian chạy với n = 1.000, 10.000, 100.000 để thấy thời gian tăng theo bình phương. Refactor bằng cách dựng một Map tra cứu một lần và đo lại để thấy nó tăng tuyến tính. Dùng profiler để xác nhận hot path là vòng lặp tìm kiếm trước khi sửa. Cuối cùng, đo cả bộ nhớ của bản dùng Map trên dữ liệu rất lớn để thấy đánh đổi time-space, và tạo một ví dụ ngược (tối ưu một đoạn n nhỏ không nóng) để cảm nhận premature optimization làm code khó đọc mà không lợi.

Edge Case — Boundary Testing

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:35 +0000

Boundary testing: bug nằm ở rìa, không ở giữa

Phần lớn bug production không nằm ở "đường chính" (input bình thường, đã chạy ngàn lần) mà ở các biên: danh sách rỗng, đúng giới hạn (off-by-one), giá trị null/undefined, số 0 và số âm, chuỗi rỗng, ngày đầu/cuối tháng, trang cuối của phân trang, request đồng thời. Testing mindset là thói quen, khi nhìn một feature, tự hỏi "rìa của nó ở đâu" trước khi nghĩ tới đường chính. Bỏ qua biên là lý do một feature "chạy tốt khi demo" rồi vỡ khi gặp dữ liệu thật đa dạng.

Cơ chế hoạt động

Với mỗi input/điều kiện, biên là các giá trị ngay tại và quanh ngưỡng, cùng các trạng thái đặc biệt:

function paginate(items, page, pageSize) {
  return items.slice((page - 1) * pageSize, page * pageSize)
}
// đường chính: page=2, pageSize=10, items có 100 phần tử -> OK
// các biên cần test:
//   items = []           (rỗng)
//   page = 1             (trang đầu)
//   page vượt số trang   (trả rỗng hay lỗi?)
//   page = 0 / âm        (đầu vào không hợp lệ)
//   items.length không chia hết pageSize (trang cuối thiếu)
//   pageSize = 0         (chia/slice bất thường)

Boundary value analysis: với một ngưỡng N, test N-1, N, N+1. Với tập hợp, test rỗng, một phần tử, và "đầy". Phần lớn off-by-one lộ ra đúng ở các điểm này.

Vấn đề gặp trong production

Failure mode: dữ liệu rỗng/null không xử lý. Code viết với giả định "luôn có dữ liệu" vỡ khi gặp rỗng:

const avg = scores.reduce((a, b) => a + b) / scores.length // scores=[] -> reduce throw, hoặc chia 0 -> NaN
const first = users[0].name // users=[] -> undefined.name -> crash

Mảng rỗng, kết quả truy vấn không có hàng, field optional vắng — đây là nhóm biên hay bị bỏ và hay nổ nhất, vì test thủ công lúc dev thường có sẵn dữ liệu.

Failure mode: off-by-one ở giới hạn. Phân trang lệch một hàng, vòng lặp <= thay vì <, lấy substring sai một ký tự — những lỗi này không lộ với input giữa dải, chỉ ở đúng biên (trang cuối, phần tử cuối). Chúng âm thầm: kết quả "gần đúng" nên dễ lọt qua review và demo.

Failure mode: bỏ qua biên thời gian và đồng thời. Ngày cuối tháng/năm, đổi múi giờ, giây nhuận; và biên đồng thời — hai request cùng sửa một bản ghi, cùng đặt đơn cho sản phẩm cuối kho. Những biên này không thấy được khi test tuần tự một mình, nhưng xuất hiện chắc chắn dưới tải production.

Failure mode: test nhiều tốn effort — cần chọn lọc. Không thể test mọi tổ hợp; chi phí là thật. Tập trung vào biên có khả năng xảy ra và hậu quả lớn (rỗng, null, off-by-one ở phân trang/tính tiền, đồng thời trên dữ liệu quan trọng), bỏ qua tổ hợp phi thực tế. Một checklist biên cho mỗi feature đáng giá hơn cố phủ 100%.

Cách debug và monitor

Khi nhận một bug production, ghi lại nó như một test biên trước khi sửa — phần lớn bug là một biên bị bỏ, và test đó ngăn nó tái diễn. Lập checklist biên chung cho team (rỗng, null/undefined, 0/âm, off-by-one, biên thời gian, đồng thời) và soi mỗi feature qua nó trong review. Theo dõi log production cho các lỗi đặc trưng của biên: Cannot read ... of undefined (null chưa xử lý), NaN trong số liệu (chia 0/mảng rỗng), lỗi chỉ xảy ra cuối tháng/cuối trang. Property-based testing (sinh input ngẫu nhiên gồm cả ca biên) bổ sung tốt cho test viết tay khi muốn phủ rộng dải giá trị.

Tradeoff

Test biên kỹ bắt được phần lớn bug trước khi ra production — đầu tư rẻ so với một sự cố. Cái giá là effort: viết và bảo trì test biên tốn thời gian, và không thể phủ mọi tổ hợp. Quy tắc thực tế: ưu tiên biên theo xác suất xảy ra × hậu quả — rỗng/null/off-by-one ở các luồng quan trọng (tính tiền, phân trang, phân quyền) gần như luôn đáng; tổ hợp hiếm và hậu quả nhỏ thì bỏ. Dùng checklist biên làm công cụ nhất quán, ghi mỗi bug production thành test biên, và dùng property-based test để mở rộng dải mà không viết tay từng ca. Mục tiêu là phủ rủi ro, không phải phủ con số.

Câu hỏi phỏng vấn

Những edge case thường gặp nhất là gì, và làm sao quyết định test cái nào khi không thể test hết?

Các biên hay gặp và hay nổ nhất: dữ liệu rỗng (mảng/kết quả truy vấn không có hàng → reduce throw, chia 0 ra NaN, arr[0] undefined), null/undefined ở field optional, giá trị 0 và âm, off-by-one tại ngưỡng (phân trang lệch, <= thay <), biên thời gian (cuối tháng/năm, múi giờ), và biên đồng thời (hai request cùng sửa một bản ghi). Kỹ thuật cốt lõi là boundary value analysis: với ngưỡng N test N-1/N/N+1, với tập hợp test rỗng/một/đầy. Khi không thể test hết, ưu tiên theo xác suất xảy ra × hậu quả: rỗng/null/off-by-one và đồng thời trên các luồng quan trọng (tính tiền, phân quyền, phân trang) gần như luôn đáng; tổ hợp hiếm hậu quả nhỏ thì bỏ. Điểm ăn điểm: dùng checklist biên chung trong review, ghi mỗi bug production thành một test biên để chặn tái diễn, và dùng property-based testing để phủ rộng dải giá trị mà không viết tay từng ca.

Hands-on

Lấy một hàm thật có ngưỡng và tập hợp (ví dụ paginate, hoặc tính trung bình/tổng, hoặc áp giảm giá theo bậc) và liệt kê các biên của nó trước khi viết test: rỗng, một phần tử, đúng ngưỡng và ±1, 0/âm, vượt giới hạn. Viết test cho từng biên và quan sát những ca làm hàm throw/NaN/sai off-by-one mà đường chính không lộ, rồi sửa. Lấy một bug production gần đây (hoặc dựng một bug biên đồng thời: hai lần đặt đơn cho sản phẩm cuối kho) và viết test tái hiện trước khi vá. Cuối cùng thêm một property-based test sinh input ngẫu nhiên để xem nó tự tìm ra ca biên nào mà test viết tay bỏ sót.

Layering — Separation of Concerns

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:32 +0000

Tách tầng: controller mỏng, business logic ở service, truy cập dữ liệu ở repository

Một ứng dụng backend điển hình có ba mối quan tâm khác nhau: nhận/trả HTTP (presentation), logic nghiệp vụ (service/domain), và truy cập dữ liệu (repository). Tách chúng thành các tầng nghĩa là mỗi tầng chỉ biết việc của mình và phụ thuộc một chiều xuống dưới. Lý do thực tế: khi logic nghiệp vụ trộn vào controller, nó dính chặt vào HTTP — không tái sử dụng được cho một job nền hay một CLI, không test được nếu không giả lập request/response, và một controller phình to thành nơi mọi thứ đổ về. "Fat controller" là phản mẫu phổ biến nhất ở backend.

Cơ chế hoạt động

Mỗi tầng một trách nhiệm, phụ thuộc một chiều: controller → service → repository.

// Controller: chỉ dịch HTTP <-> lời gọi nghiệp vụ. Mỏng.
async function placeOrderHandler(req, res, next) {
  try {
    const order = await orderService.placeOrder(req.user.id, req.body) // ủy quyền
    res.status(201).json(toDto(order))
  } catch (err) { next(err) } // để error middleware xử lý
}

// Service: logic nghiệp vụ thuần, không biết gì về HTTP
class OrderService {
  async placeOrder(userId, input) {
    this.validate(input)
    const total = this.pricing.compute(input)
    return this.repo.save({ userId, ...input, total }) // gọi xuống repository
  }
}

// Repository: chỉ biết lưu/đọc dữ liệu, không chứa logic nghiệp vụ
class OrderRepository {
  save(order) { return this.db.insert('orders', order) }
}

Controller không tính tiền, không chạm DB; service không đọc req/res; repository không biết quy tắc nghiệp vụ. Phụ thuộc đi xuống, không vòng lên.

Vấn đề gặp trong production

Failure mode: fat controller. Khi controller làm hết — validate, tính toán, truy vấn DB, định dạng response — logic nghiệp vụ bị nhốt trong tầng HTTP:

async function placeOrder(req, res) {
  if (!req.body.items?.length) return res.status(400).json({ error: '...' })
  let total = 0
  for (const i of req.body.items) total += i.price * i.qty   // nghiệp vụ kẹt trong controller
  await db.query('insert into orders ...')                    // truy cập DB thẳng
  // ...không tái dùng được, không test được nếu không giả lập req/res
}

Khi cần đặt đơn từ một cron job hay một message queue (không có HTTP), không gọi lại được — phải copy logic, và hai bản drift dần. Tách service ra cho phép mọi điểm vào (HTTP, job, CLI) dùng chung một logic.

Failure mode: logic rò vào sai tầng. Hai biến thể hay gặp: business logic chui xuống repository (repo chứa if user.isPremium), và truy cập DB chui lên controller. Cả hai phá tính một-chiều và làm tầng mất ý nghĩa. Quy tắc đặt code: quyết định nghiệp vụ ở service; câu lệnh đọc/ghi dữ liệu ở repository; chuyển đổi HTTP ở controller.

Failure mode: over-layering / abstraction thừa. Phản ứng quá đà là thêm tầng cho mọi thứ — một interface + một mapper + một DTO cho cả CRUD tầm thường nhất, khiến thêm một field phải sửa sáu file. Số tầng nên tương xứng độ phức tạp: CRUD đơn giản có thể controller gọi thẳng repository; tầng service đáng có khi có logic nghiệp vụ thật để chứa. Tách tầng để cô lập mối quan tâm có thật, không phải để đủ "kiến trúc đẹp".

Cách debug và monitor

Dấu hiệu fat controller: file handler dài, import cả driver DB lẫn thư viện nghiệp vụ, và test handler phải mock req/res cùng database. Dấu hiệu rò tầng: tìm câu lệnh SQL/ORM trong controller, hoặc if quyết định nghiệp vụ trong repository. Một kiểm tra nhanh: "logic này có gọi lại được từ một context không-HTTP không?" — nếu không, nó đang kẹt trong controller. Khi cùng một quy tắc nghiệp vụ xuất hiện ở cả HTTP handler lẫn job handler, đó là bằng chứng logic chưa được tách ra tầng dùng chung. Ngược lại, nếu thêm một field tầm thường phải đụng nhiều tầng/mapper, có thể đã over-layer.

Tradeoff

Tách tầng cho tái sử dụng (mọi điểm vào dùng chung logic), test được (service thuần test không cần HTTP/DB thật), và thay đổi khoanh vùng (đổi DB chỉ đụng repository, đổi API chỉ đụng controller). Cái giá là nhiều tầng, nhiều file, và việc đi qua các tầng cho một thao tác đơn giản. Quy tắc thực tế: giữ controller mỏng (chỉ dịch HTTP), đặt logic nghiệp vụ ở service, truy cập dữ liệu ở repository, phụ thuộc một chiều; nhưng cho số tầng tương xứng độ phức tạp — đừng dựng đủ ba tầng + mapper cho CRUD không có logic. Tầng tồn tại để cô lập mối quan tâm thật, không phải để trang trí.

Câu hỏi phỏng vấn

Controller nên chứa gì, và vì sao không nên để business logic trong controller?

Controller nên mỏng: chỉ dịch giữa HTTP và lời gọi nghiệp vụ — đọc input từ request, gọi service, ánh xạ kết quả/lỗi thành response (thường đẩy lỗi sang error middleware). Không nên để business logic trong controller vì nó làm logic dính chặt vào tầng HTTP: không tái sử dụng được từ context khác (cron job, message queue, CLI) nên buộc copy và hai bản drift; không test được nếu không giả lập req/res; và controller phình thành nơi mọi thứ đổ về. Tách ra: quyết định nghiệp vụ ở service (thuần, không biết HTTP), đọc/ghi dữ liệu ở repository, phụ thuộc một chiều controller→service→repository. Điểm ăn điểm: cảnh báo cả hai chiều rò tầng (SQL trong controller, if nghiệp vụ trong repository) lẫn over-layering (đủ tầng + mapper cho CRUD không có logic) — số tầng nên tương xứng độ phức tạp thật.

Hands-on

Lấy một fat controller thật (handler vừa validate, vừa tính toán, vừa query DB, vừa format) và tách thành ba tầng: controller mỏng chỉ dịch HTTP, service chứa logic nghiệp vụ thuần, repository chỉ đọc/ghi dữ liệu. Viết unit test cho service mà không mock req/res hay DB thật để thấy nó test được độc lập. Sau đó gọi lại chính service đó từ một điểm vào không-HTTP (một script/cron giả lập) để chứng minh logic tái sử dụng được mà không copy. Cố tình để một câu query rò lên controller và một if nghiệp vụ rò xuống repository, rồi sửa về đúng tầng; cuối cùng đối chiếu với một CRUD tầm thường để quyết định chỗ nào không cần tầng service.

Refactoring — Code Smell

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:30 +0000

Code smell: dấu hiệu cần refactor, và vì sao không có test thì đừng đụng

Code smell là những dấu hiệu bề mặt gợi ý có vấn đề sâu hơn về thiết kế — duplicated code, long method, magic number, large class, primitive obsession. Bản thân smell không phải bug; nó là "mùi" cảnh báo code sẽ khó sửa, dễ sai khi thay đổi. Nhận ra smell là kỹ năng review cốt lõi. Nhưng có một quy tắc đi kèm quan trọng không kém: refactor là thay đổi cấu trúc mà không đổi hành vi, và không có test bảo vệ thì mọi refactor là một canh bạc — bạn không có cách nào biết mình có vô tình đổi hành vi không.

Cơ chế hoạt động

Một số smell phổ biến nhất và cách khử:

// Magic number: 0.1 và 86400000 nghĩa là gì?
if (total > 0.1) { ... }
setTimeout(cleanup, 86400000)
// -> extract constant đặt tên
const MIN_DISCOUNT_RATE = 0.1
const ONE_DAY_MS = 24 * 60 * 60 * 1000

// Duplicated code: cùng logic ở nhiều nơi -> extract function
// Long method -> tách theo mức trừu tượng (xem PF031)
// Primitive obsession: truyền (lat, lng) lẻ khắp nơi -> gói thành value object Coordinates
// Feature envy: method dùng dữ liệu của object khác nhiều hơn của chính nó -> chuyển method sang object kia

Mỗi smell có một refactoring tương ứng (extract constant/method, introduce parameter object, move method). Điểm cốt lõi: refactoring là chuỗi bước nhỏ, mỗi bước giữ nguyên hành vi, xác nhận bằng test sau mỗi bước — không phải viết lại một mạch.

Vấn đề gặp trong production

Failure mode: refactor không test gây hồi quy. Đây là rủi ro lớn nhất. "Dọn dẹp" một hàm phức tạp mà không có test sẽ vô tình đổi một edge case — một điều kiện biên, một thứ tự xử lý — và bug chỉ lộ ra ở production tuần sau, khó truy về đúng commit refactor. Quy tắc: trước khi refactor code chưa có test, viết characterization test trước — test nắm lại hành vi hiện tại (kể cả hành vi "lạ"), để mọi thay đổi cấu trúc sau đó được kiểm chứng là không đổi hành vi.

// trước khi refactor calculatePrice (không ai dám đụng), khóa hành vi hiện tại lại
test('giữ hành vi hiện tại', () => {
  expect(calculatePrice(sampleCart)).toBe(1234) // ghi lại output thực tế đang chạy
})

Failure mode: refactor lẫn với thay đổi tính năng trong một PR. Trộn "đổi cấu trúc" và "đổi hành vi" trong cùng một thay đổi làm review bất khả thi và khó truy lỗi — không biết một bug đến từ refactor hay từ feature. Tách thành hai PR: một refactor thuần (test xanh không đổi), một feature.

Failure mode: đuổi theo smell mà không có giá trị. Không phải mọi smell đều đáng khử. Một đoạn duplicated nhỏ ở hai chỗ ổn định, hay một magic number rõ trong ngữ cảnh, gắng abstract có khi tạo abstraction sai (gom hai thứ trông giống nhưng thay đổi vì lý do khác — coupling sai). Refactor có chi phí và rủi ro; ưu tiên smell ở code thay đổi thường xuyên và phức tạp, bỏ qua smell ở góc yên tĩnh.

Cách debug và monitor

Trong review, các smell dễ thấy: số lặp lại (magic number), khối code copy-paste (duplication), hàm/class quá lớn, danh sách tham số dài (parameter object), switch/if trên cùng "loại" ở nhiều nơi (thiếu polymorphism). Trước khi đồng ý một PR refactor lớn, câu hỏi đầu tiên: "có test phủ vùng này không?" — nếu không, yêu cầu characterization test trước. Theo dõi độ phủ test ở các module hay refactor; vùng phức tạp mà phủ thấp là nơi refactor nguy hiểm nhất. Công cụ phân tích tĩnh phát hiện duplication và complexity tự động, dùng để khoanh vùng nhưng quyết định khử hay không vẫn là phán đoán.

Tradeoff

Khử smell làm code dễ đọc, dễ sửa, ít lỗi khi thay đổi về sau — đầu tư vào khả năng bảo trì. Cái giá là thời gian, rủi ro hồi quy (đặc biệt khi thiếu test), và nguy cơ tạo abstraction sai khi gom những thứ chỉ tình cờ giống nhau. Quy tắc thực tế: refactor luôn cần test bảo vệ (viết trước nếu chưa có); làm bước nhỏ, mỗi bước test xanh; tách refactor khỏi thay đổi tính năng; và chọn smell để khử theo giá trị — ưu tiên code nóng và phức tạp, chấp nhận smell vô hại ở chỗ ổn định. Refactor không phải mục tiêu tự thân mà là dọn đường cho thay đổi sắp tới.

Câu hỏi phỏng vấn

Code smell là gì, cho vài ví dụ, và vì sao không nên refactor khi chưa có test?

Code smell là dấu hiệu bề mặt gợi ý vấn đề thiết kế sâu hơn — không phải bug, mà là "mùi" cảnh báo code khó sửa và dễ sai khi đổi; ví dụ: duplicated code, long method, magic number, large class, primitive obsession (dùng kiểu nguyên thủy lẻ thay vì gói thành value object), feature envy. Mỗi smell có một refactoring tương ứng (extract constant/method, introduce parameter object, move method). Không nên refactor khi chưa có test vì refactor theo định nghĩa là đổi cấu trúc mà giữ nguyên hành vi — không có test thì không có cách nào biết mình có vô tình đổi một edge case không, và hồi quy sẽ lộ muộn ở production khó truy về commit. Điểm ăn điểm: viết characterization test khóa hành vi hiện tại trước khi đụng code chưa phủ test, làm bước nhỏ test xanh sau mỗi bước, tách refactor khỏi feature trong PR riêng, và chỉ ưu tiên khử smell ở code nóng/phức tạp vì refactor có chi phí và rủi ro tạo abstraction sai.

Hands-on

Lấy một hàm legacy thật chưa có test (kiểu calculatePrice với nhiều điều kiện và magic number mà cả nhóm ngại đụng), viết characterization test khóa lại output hiện tại cho một bộ input đại diện. Sau đó refactor từng bước nhỏ — extract constant cho các magic number, extract method cho khối lặp, gói các tham số nguyên thủy đi cùng nhau thành một parameter object — chạy test sau mỗi bước để xác nhận hành vi không đổi. Cố tình thực hiện một bước làm đổi một edge case và quan sát test bắt được. Cuối cùng, tách một PR đang trộn refactor với thêm tính năng thành hai phần riêng và đối chiếu độ dễ review.

Function — Small Function

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:26 +0000

Hàm nhỏ: tách theo mức trừu tượng, không theo số dòng

"Hàm nên nhỏ" là lời khuyên hay bị hiểu thành "đếm dòng": dưới 20 dòng thì tốt, trên thì xấu. Đó là cách hiểu sai. Một hàm tốt làm một việc ở một mức trừu tượng, đọc như một câu mô tả ý định; độ dài chỉ là hệ quả. Mục tiêu thật là giảm độ phức tạp người đọc phải giữ trong đầu cùng lúc — một hàm dài trộn nhiều mức (logic nghiệp vụ lẫn thao tác chuỗi lẫn gọi I/O) buộc đọc tất cả mới hiểu được phần nào. Tách quá tay thành chục hàm tí hon lại gây vấn đề ngược: phải nhảy khắp file để ráp lại một luồng đơn giản.

Cơ chế hoạt động

Nguyên tắc cốt lõi: mỗi hàm nên ở một mức trừu tượng. Hàm cấp cao kể câu chuyện bằng các bước có tên; chi tiết của mỗi bước nằm trong hàm con cùng mức với nhau.

// trộn nhiều mức: điều phối + chi tiết tính toán + định dạng, đọc phải hiểu hết
function checkout(cart) {
  let total = 0
  for (const item of cart.items) total += item.price * item.qty
  if (cart.coupon) total *= (1 - cart.coupon.rate)
  const tax = Math.round(total * 0.1)
  // ... 30 dòng nữa trộn lưu DB và gửi mail
}

// tách theo mức: hàm trên đọc như mô tả ý định
function checkout(cart) {
  const subtotal = calculateSubtotal(cart.items)
  const total = applyCoupon(subtotal, cart.coupon)
  const order = createOrder(cart, total, calculateTax(total))
  return order
}

Bản tách cho người đọc hiểu luồng mà không cần chi tiết; ai cần chi tiết mới mở calculateSubtotal. Mỗi hàm con kiểm thử được riêng.

Vấn đề gặp trong production

Failure mode: hàm dài trộn nhiều mức trừu tượng. Một hàm 200 dòng làm validation + tính toán + truy vấn + định dạng buộc người đọc giữ toàn bộ ngữ cảnh trong đầu, và mỗi sửa đổi nhỏ đụng một khối lớn nên dễ gây hồi quy. Đây là dạng khó bảo trì nhất. Tách thành các bước có tên giảm tải nhận thức và khoanh vùng thay đổi — sửa cách tính thuế chỉ đụng calculateTax.

Failure mode: quá phân mảnh (over-extraction). Phản ứng quá đà là tách mọi thứ, kể cả một biểu thức dùng một lần, thành hàm riêng:

function isPositive(n) { return n > 0 } // dùng đúng một chỗ, che mất ý đơn giản
function addOne(n) { return n + 1 }

Khi đó đọc một luồng phải nhảy qua chục hàm một-dòng rải khắp file, mỗi cú nhảy là một lần mất mạch. Hàm chỉ đáng tách khi nó đặt tên cho một ý niệm (làm rõ ý định) hoặc được dùng lại, không phải để giảm số dòng của hàm cha. Một khối ba dòng có tên rõ trong ngữ cảnh đôi khi dễ đọc hơn một lời gọi hàm phải đi tìm.

Failure mode: tách nhưng vẫn truyền/giữ state lẫn lộn. Tách hàm mà mỗi hàm con vẫn nhận mười tham số hoặc đọc/ghi biến chung thì không giảm phức tạp thật — chỉ dời nó đi. Tách tốt đi kèm dữ liệu vào/ra rõ ràng cho mỗi hàm con.

Cách debug và monitor

Dấu hiệu một hàm nên tách: phải cuộn để đọc hết, có comment kiểu // tính toán / // gửi mail chia hàm thành khúc (mỗi khúc thường là một hàm con), hoặc độ lồng sâu (nhiều tầng if/for). Công cụ đo cyclomatic complexity (qua linter) cảnh báo hàm quá phức tạp — dùng như tín hiệu, không phải luật cứng. Dấu hiệu tách quá tay: đọc một feature phải mở chục file/hàm một-dòng, hoặc tên hàm chỉ lặp lại nội dung (incrementByOne). Một câu hỏi review hữu ích: "hàm này có đọc được như một câu mô tả việc nó làm không, và có cần nhảy đi đâu để hiểu luồng chính không?"

Tradeoff

Tách hàm theo mức trừu tượng làm code dễ đọc (luồng chính như mô tả ý định), dễ test (mỗi phần riêng), dễ sửa an toàn (thay đổi khoanh vùng). Cái giá khi làm quá là phân mảnh — luồng trải khắp nhiều hàm nhỏ, đọc phải nhảy liên tục, gián đoạn mạch hiểu. Quy tắc thực tế: tách khi một hàm trộn nhiều mức trừu tượng hoặc một khối xứng đáng có một cái tên giải thích ý định; giữ lại khi tách chỉ để giảm dòng mà không thêm nghĩa. Đo bằng "đọc có hiểu ý định không", không bằng số dòng tuyệt đối — không có con số kỳ diệu nào.

Câu hỏi phỏng vấn

Một hàm nên dài bao nhiêu dòng, và khi nào tách hàm là sai?

Không có con số cố định — độ dài là hệ quả, không phải mục tiêu. Nguyên tắc đúng là mỗi hàm làm một việc ở một mức trừu tượng và đọc được như một câu mô tả ý định: hàm cấp cao kể luồng bằng các bước có tên, chi tiết của mỗi bước nằm trong hàm con cùng mức. Một hàm dài trộn nhiều mức (điều phối + tính toán + I/O + định dạng) cần tách vì nó buộc giữ toàn bộ ngữ cảnh trong đầu và mỗi sửa nhỏ đụng khối lớn gây hồi quy. Tách là sai khi over-extraction: biến mọi biểu thức dùng một lần thành hàm riêng làm luồng trải khắp file, đọc phải nhảy liên tục và mất mạch — hàm chỉ đáng tách khi đặt tên cho một ý niệm (làm rõ ý định) hoặc được tái sử dụng. Điểm ăn điểm: dùng cyclomatic complexity và comment-chia-khúc làm tín hiệu tách, và đảm bảo mỗi hàm con có dữ liệu vào/ra rõ chứ không chỉ dời state đi.

Hands-on

Lấy một hàm dài thật (kiểu checkout/processRequest 100+ dòng trộn validation, tính toán, truy vấn, định dạng) và tách hàm cấp cao thành các bước có tên ở cùng mức trừu tượng, đẩy chi tiết xuống hàm con với input/output rõ ràng; viết unit test cho một hàm con thuần (như calculateTax) để thấy nó test được độc lập. Sau đó cố tình over-extract một hàm khác thành nhiều hàm một-dòng (isPositive, addOne) và cảm nhận việc đọc luồng phải nhảy liên tục, rồi gộp lại những cái không thêm nghĩa. Chạy linter đo cyclomatic complexity trước/sau để đối chiếu tín hiệu với cảm nhận đọc.

Naming — Meaningful Naming

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:24 +0000

Đặt tên có nghĩa: tên sai tốn nhiều giờ hơn tên dài

Tên là tài liệu được đọc nhiều nhất trong code — mỗi lần đọc một hàm, một biến, người đọc dựa vào tên để hiểu ý định mà không phải đọc hết phần thân. Tên tốt làm code tự giải thích; tên sai chủ động đánh lừa, dẫn người đọc tới giả định sai và gây bug khi họ dùng một hàm theo cách tên gợi ý mà không phải cách nó thực sự làm. Trong review, đây là loại góp ý đáng giá nhất nhưng hay bị xem nhẹ: một tên gây hiểu nhầm sống trong codebase nhiều năm và đánh lừa mọi người chạm vào nó.

Cơ chế hoạt động

Tên tốt nêu ý định và đơn vị, không nêu cách hiện thực; nêu cái nó trả về hoặc cái nó là, ở mức trừu tượng của nơi dùng:

// mơ hồ / gây hiểu nhầm
const d = getData()            // d là gì? getData lấy data nào?
function check(u) {}           // check cái gì? trả bool hay throw?
let flag = true                // flag cho cái gì?
const list = users.filter(...) // list của cái gì sau khi filter?

// rõ nghĩa
const activeUsers = getActiveUsers()
function assertCanCheckout(user): void {} // assert -> throw nếu sai; tên nói rõ
let hasUnsavedChanges = true
const verifiedUsers = users.filter(u => u.isVerified)

Quy ước mang thông tin: tiền tố is/has/can cho boolean, động từ cho hàm (fetch, calculate, assert), danh từ cho giá trị, đơn vị trong tên khi có (timeoutMs, priceInCents). Người đọc suy ra hành vi từ tên mà không mở thân hàm.

Vấn đề gặp trong production

Failure mode: tên gây hiểu nhầm dẫn tới dùng sai. Tên tệ hơn cả tên mơ hồ là tên sai — gợi ý một hành vi mà hàm không có:

function getUser(id) {           // tên nói "get" (đọc), nhưng...
  const u = db.find(id)
  u.lastSeen = Date.now()        // ...nó còn GHI — side effect ẩn sau tên "get"
  db.save(u)
  return u
}

get gợi ý một thao tác đọc thuần, không tác dụng phụ. Người dùng gọi getUser trong một vòng lặp để đọc, vô tình ghi DB mỗi lần — một bug hiệu năng và tính đúng đắn sinh ra vì tin vào tên. Tên đúng (fetchAndTouchUser hoặc tách thành hai hàm) ngăn được. Quy ước phổ biến: get/is/has không side effect; thao tác có tác dụng phụ dùng động từ nói rõ (update, save, mark).

Failure mode: đơn vị/ngữ cảnh thiếu trong tên gây lỗi tính toán. timeout, delay, size không có đơn vị là nguồn lỗi kinh điển — giây hay mili-giây? byte hay kilobyte? setTimeout(delay) với delay = 5 ý là 5 giây nhưng thành 5ms. Tên mang đơn vị (delaySeconds, sizeBytes) hoặc priceInCents loại bỏ cả lớp lỗi quy đổi.

Failure mode: tên không khớp với cái nó làm (drift). Một hàm validateEmail qua thời gian được thêm cả việc gửi email xác nhận, nhưng tên không đổi. Tên giờ nói dối. Khi sửa hành vi một hàm/biến, cập nhật tên theo — tên lỗi thời còn tệ hơn tên dở từ đầu vì người ta tin nó.

Cách debug và monitor

Khi đọc code phải liên tục mở thân hàm để biết nó thực sự làm gì dù tên "có vẻ rõ", đó là dấu hiệu tên không khớp hành vi. Trong review, một câu hỏi mạnh: "tên này có cho người gọi đoán đúng hành vi mà không đọc thân không?" — nếu không, đề xuất đổi. Tên một-chữ (d, tmp, data, obj), tên có số (user2, handleClick2), và boolean phủ định kép (isNotDisabled) là các pattern cần soi. Khi đổi hành vi trong một PR, kiểm tra tên liên quan có còn đúng không — coi tên là một phần của thay đổi, không phải thứ bất biến. IDE rename an toàn nên đổi tên rẻ; đừng giữ tên dở vì ngại sửa.

Tradeoff

Tên rõ nghĩa thường dài hơn tên viết tắt, nhưng đánh đổi gần như luôn đáng: code được đọc nhiều hơn viết rất nhiều lần, và mỗi lần đọc một tên rõ tiết kiệm công so với giải mã một tên cụt hay sai. Cực đoan ngược lại — tên dài lê thê mô tả cả hiện thực (getUserListFromDatabaseAndFilterByActiveStatusThenSort) — cũng tệ vì lẫn ý định với chi tiết và khó đọc. Quy tắc thực tế: tên đủ dài để nêu ý định và đơn vị, ngắn nhất có thể mà vẫn không mơ hồ; theo quy ước nhất quán (is/has cho bool, động từ cho hàm, đơn vị trong tên); và quan trọng nhất — tên không được nói dối về hành vi, cập nhật tên khi hành vi đổi.

Câu hỏi phỏng vấn

Một tên hàm tốt trông thế nào, và vì sao tên gây hiểu nhầm nguy hiểm hơn tên mơ hồ?

Tên hàm tốt nêu ý định (cái nó làm/trả về) ở mức trừu tượng của nơi dùng, không nêu chi tiết hiện thực, và theo quy ước mang thông tin: động từ cho hành động (fetch, calculate, assert), is/has/can cho boolean, đơn vị trong tên khi có (timeoutMs, priceInCents) — để người gọi đoán đúng hành vi mà không cần đọc thân hàm. Tên gây hiểu nhầm nguy hiểm hơn tên mơ hồ vì tên mơ hồ chỉ buộc người đọc kiểm tra thêm, còn tên sai chủ động dẫn tới giả định sai: một hàm tên getUser mà âm thầm ghi DB sẽ bị gọi trong vòng lặp như thao tác đọc thuần, sinh bug hiệu năng và tính đúng đắn vì người ta tin tên. Điểm ăn điểm: quy ước get/is/has không side effect, đặt đơn vị vào tên để tránh lỗi quy đổi, và cập nhật tên khi hành vi thay đổi vì tên lỗi thời còn tệ hơn tên dở từ đầu.

Hands-on

Lấy một file thật trong codebase và rà các tên: tìm tên một-chữ/mơ hồ (d, data, tmp, flag), tên thiếu đơn vị (timeout, size, delay), và đặc biệt tên gây hiểu nhầm — hàm get/is có side effect ẩn. Đổi tên cho rõ ý định và đơn vị bằng rename an toàn của IDE, và với hàm có side effect ẩn sau tên đọc, hoặc đổi tên nói rõ hoặc tách thành hai hàm. Tạo một ví dụ cụ thể: một getX âm thầm ghi DB, gọi nó trong vòng lặp để thấy bug sinh ra từ việc tin tên, rồi sửa. Cuối cùng tìm một hàm có hành vi đã "drift" khỏi tên và cập nhật tên cho khớp.

Immutability — Immutable Data

Nghề không nhiều chẳng sắc — Mon, 29 Jun 2026 14:52:21 +0000

Immutability: không sửa tại chỗ, tạo bản mới — vì sao nó loại bỏ cả lớp bug

Immutable data nghĩa là một khi tạo ra, giá trị không bị sửa tại chỗ; mọi "thay đổi" tạo ra một bản sao mới với phần đã đổi. Cách làm này loại bỏ một nguồn bug lớn: side effect ngầm, nơi một hàm sửa object mà nơi gọi không ngờ tới, gây ra hành vi sai ở một chỗ hoàn toàn khác. Nó cũng là nền của cách React phát hiện thay đổi (so sánh tham chiếu) và của khả năng suy luận về state. Cái giá là sao chép tốn bộ nhớ và CPU khi dữ liệu lớn — nên immutability là một đánh đổi có chủ đích, không phải luật tuyệt đối.

Cơ chế hoạt động

Object và array trong JS được truyền theo tham chiếu, nên sửa tại chỗ ảnh hưởng mọi nơi giữ cùng tham chiếu. Cập nhật immutable tạo bản mới bằng spread thay vì sửa gốc:

// mutable: sửa tại chỗ — gốc bị đổi
function addItem(cart, item) { cart.items.push(item); return cart }

// immutable: trả bản mới, gốc nguyên vẹn
function addItem(cart, item) {
  return { ...cart, items: [...cart.items, item] }
}

Bản immutable không đụng cart gốc — mọi nơi còn giữ tham chiếu cũ vẫn thấy giá trị cũ, đúng như mong đợi. Lưu ý spread là shallow copy: chỉ sao chép một cấp; object lồng sâu cần spread từng cấp trên đường tới chỗ đổi.

Vấn đề gặp trong production

Failure mode: side effect ngầm do mutate đối số. Một hàm tiện ích sửa object truyền vào sẽ gây bug ở nơi không liên quan:

function applyDefaults(config) {
  config.timeout = config.timeout ?? 30 // BUG: sửa config gốc của caller
  return config
}
const shared = { retries: 3 }
applyDefaults(shared) // shared giờ có timeout=30, ngoài ý muốn của nơi khác đang dùng shared

Vì shared được truyền theo tham chiếu và bị sửa tại chỗ, mọi nơi khác giữ shared đột nhiên thấy giá trị đổi. Loại bug này cực khó truy vì nguyên nhân (hàm sửa đối số) và triệu chứng (giá trị sai ở chỗ khác) cách xa nhau. Trả bản mới (return { ...config, timeout: config.timeout ?? 30 }) loại bỏ hẳn.

Failure mode: React không re-render vì mutate state. React quyết định re-render bằng so sánh tham chiếu state. Sửa tại chỗ giữ nguyên tham chiếu nên React tưởng không có gì đổi:

// BUG: cùng tham chiếu mảng -> React bỏ qua, UI không cập nhật
setItems(items => { items.push(newItem); return items })
// đúng: tham chiếu mới
setItems(items => [...items, newItem])

Đây là một trong những bug React phổ biến nhất với người mới: state "đã đổi" nhưng UI đứng yên, vì tham chiếu không đổi.

Failure mode: chi phí sao chép dữ liệu lớn. Spread một mảng/object khổng lồ mỗi lần cập nhật tốn bộ nhớ và CPU; trong vòng lặp nóng hoặc state rất lớn, đây là chi phí thật. Với dữ liệu lớn cần cập nhật thường xuyên, dùng structural sharing (thư viện immutable như Immer hoặc cấu trúc persistent) — chia sẻ phần không đổi giữa các bản, chỉ sao chép phần thay đổi.

Cách debug và monitor

Khi một giá trị "tự đổi" ở nơi không sửa nó, nghi ngay mutate ngầm: tìm các hàm nhận object/array rồi gọi push/splice/sort/gán property lên đối số — đó là các thao tác sửa tại chỗ. Object.freeze (hoặc freeze sâu khi dev) làm mọi mutate ngoài ý muốn throw ngay tại nguồn thay vì gây bug âm thầm. Với bug React "state đổi mà không render", kiểm tra hàm cập nhật có tạo tham chiếu mới không. Đo chi phí: nếu profiler cho thấy nhiều thời gian vào việc sao chép, đó là lúc cân nhắc structural sharing thay vì spread thủ công.

Tradeoff

Immutability loại bỏ side effect ngầm — dễ suy luận (giá trị không đổi sau lưng), dễ debug (theo được dòng thay đổi qua các bản mới), và là nền cho phát hiện thay đổi bằng so sánh tham chiếu (React, memoization). Cái giá là sao chép: tốn bộ nhớ và CPU, đặc biệt với dữ liệu lớn cập nhật thường xuyên, và spread sâu thủ công dễ sai (quên một cấp). Quy tắc thực tế: mặc định immutable cho state ứng dụng và đối số hàm (không mutate cái mình không sở hữu); với dữ liệu lớn/nóng, dùng structural sharing (Immer, persistent structure) để giữ lợi ích mà không trả full copy; và freeze trong môi trường dev để bắt mutate ngoài ý muốn.

Câu hỏi phỏng vấn

Lợi ích của immutable data là gì, và vì sao mutate state trực tiếp làm React không re-render?

Immutable data không sửa giá trị tại chỗ mà tạo bản mới cho mỗi thay đổi, nhờ đó loại bỏ side effect ngầm — không hàm nào sửa object sau lưng nơi gọi — nên dễ suy luận và debug, và cho phép phát hiện thay đổi bằng so sánh tham chiếu thay vì so sánh sâu. React dựa đúng vào so sánh tham chiếu để quyết định re-render: nếu mutate state tại chỗ (items.push(...)), tham chiếu mảng/object không đổi nên React kết luận "không có gì thay đổi" và bỏ qua render, dù nội dung đã khác; phải trả về tham chiếu mới ([...items, newItem]). Điểm ăn điểm: spread là shallow copy nên cập nhật lồng sâu phải spread từng cấp; và đánh đổi là chi phí sao chép với dữ liệu lớn, xử lý bằng structural sharing (Immer/persistent structure) và freeze ở dev để bắt mutate ngoài ý muốn.

Hands-on

Viết một hàm tiện ích nhận một config object dùng chung và sửa nó tại chỗ (gán default), gọi từ nhiều nơi cùng chia sẻ object đó, và quan sát giá trị "tự đổi" ở chỗ không liên quan; sửa thành trả bản mới và xác nhận hết bug. Trong một component React, cập nhật một mảng state bằng push rồi setState để thấy UI không re-render, rồi đổi sang spread tạo tham chiếu mới. Lấy một state lồng sâu thật và viết cập nhật immutable thủ công bằng spread từng cấp (thấy dễ sai), rồi làm lại bằng Immer và so sánh độ rõ ràng; cuối cùng đo chi phí sao chép trên một mảng rất lớn cập nhật trong vòng lặp và so sánh spread với structural sharing.