27 thg 8, 2025·8 phút
Thực dụng hệ thống của Rob Pike: Công cụ đơn giản, build Go nhanh
Khám phá tư duy thực dụng của Rob Pike đằng sau Go: công cụ đơn giản, build nhanh, và concurrency dễ đọc—và cách áp dụng trên đội thực tế.
Khám phá tư duy thực dụng của Rob Pike đằng sau Go: công cụ đơn giản, build nhanh, và concurrency dễ đọc—và cách áp dụng trên đội thực tế.
Đây là một triết lý thực hành, không phải tiểu sử của Rob Pike. Ảnh hưởng của Pike lên Go là có thực, nhưng mục tiêu ở đây hữu ích hơn: gọi tên một cách xây dựng phần mềm ưu tiên kết quả hơn là sự thông minh phức tạp.
Bằng “thực dụng hệ thống,” tôi muốn nói đến thiên hướng chọn những phương án giúp hệ thống thực tế dễ xây dựng, vận hành và thay đổi khi có áp lực thời gian. Nó đánh giá cao các công cụ và thiết kế giảm ma sát cho cả đội—đặc biệt là sau vài tháng, khi mã nguồn không còn mới trong đầu bất kỳ ai.
Thực dụng hệ thống là thói quen tự hỏi:
Nếu một kỹ thuật tinh tế nhưng làm tăng số lựa chọn, cấu hình, hoặc tải nhận thức, thực dụng coi đó là chi phí—chứ không phải thành tích.
Để giữ bài viết thực tế, phần còn lại được tổ chức quanh ba trụ cột thường xuất hiện trong văn hóa và tooling của Go:
Đây không phải “luật.” Chúng là thấu kính để cân nhắc đánh đổi khi bạn chọn thư viện, thiết kế dịch vụ, hoặc đặt quy ước cho đội.
Nếu bạn là kỹ sư muốn ít bất ngờ khi build hơn, một tech lead cố gắng đồng bộ đội, hoặc người mới tò mò tự hỏi vì sao cộng đồng Go nói nhiều về sự đơn giản—khung này dành cho bạn. Bạn không cần biết chi tiết nội bộ Go—chỉ cần quan tâm cách các quyết định kỹ thuật hàng ngày cộng lại để tạo ra hệ thống bình tĩnh hơn.
Sự đơn giản không phải về khẩu vị (“tôi thích code tối giản”)—nó là một tính năng sản phẩm cho các đội engineering. Thực dụng hệ thống của Rob Pike coi sự đơn giản là thứ bạn mua bằng các quyết định có chủ ý: ít thành phần chuyển động hơn, ít trường hợp đặc biệt hơn, và ít cơ hội gây bất ngờ hơn.
Độ phức tạp đánh thuế mọi bước công việc. Nó làm chậm phản hồi (build lâu hơn, review lâu hơn, debug lâu hơn) và tăng lỗi vì có nhiều quy tắc để nhớ và nhiều trường hợp biên để vấp phải.
Thuế này cộng dồn trong toàn đội. Một mẹo “thông minh” cứu một dev vài phút có thể khiến năm dev tiếp theo mất một giờ mỗi người—đặc biệt khi họ đang on-call, mệt mỏi, hoặc mới với codebase.
Nhiều hệ thống được xây như thể luôn có developer xuất sắc tốt nhất: người biết các bất biến ẩn, bối cảnh lịch sử, và lý do kỳ lạ một workaround tồn tại. Đội không hoạt động như vậy.
Sự đơn giản tối ưu cho ngày làm việc trung bình và người đóng góp trung bình. Nó làm cho thay đổi an toàn hơn để thử, dễ review hơn, và dễ hoàn tác hơn.
Đây là khác biệt giữa “ấn tượng” và “dễ bảo trì” trong concurrency. Cả hai đều hợp lệ, nhưng một cái dễ lý giải khi chịu áp lực hơn:
// Confusing: hard to follow, hidden coordination.
for _, job := range jobs {
go func() { do(job) }() // also a common closure gotcha
}
// Clear: explicit data flow and ownership.
for _, job := range jobs {
job := job
go func(j Job) {
do(j)
}(job)
}
Phiên bản “rõ ràng” không phải vì dài dòng; nó làm ý định hiển nhiên: dữ liệu nào được dùng, ai sở hữu nó, và nó chảy như thế nào. Độ đọc được đó giữ cho đội nhanh trong nhiều tháng, không chỉ vài phút.
Go đặt một canh bạc có chủ ý: một toolchain nhất quán, “nhàm” là một tính năng năng suất. Thay vì ghép một stack tuỳ chỉnh cho formatting, build, quản lý phụ thuộc và test, Go đi kèm mặc định mà hầu hết đội có thể áp dụng ngay—gofmt, go test, go mod, và hệ thống build hành xử giống nhau trên mọi máy.
Một toolchain chuẩn giảm thuế ẩn của lựa chọn. Khi mỗi repo dùng linter khác, script khác và quy ước khác, thời gian rò rỉ vào thiết lập, tranh luận, và sửa một lần. Với các mặc định của Go, bạn tốn ít năng lượng hơn để đàm phán cách làm việc và nhiều năng lượng hơn để làm việc.
Sự nhất quán này cũng giảm mệt mỏi quyết định. Kỹ sư không cần nhớ “project này dùng formatter nào?” hay “chạy test như thế nào ở đây?” Mong đợi đơn giản: nếu bạn biết Go, bạn có thể đóng góp.
Quy ước chung làm cho cộng tác mượt hơn:
gofmt loại bỏ tranh luận về style và diff ồn ào.go test ./... hoạt động ở mọi nơi.go.mod ghi lại ý định, không phải kiến thức bộ tộc.Sự dự đoán đó đặc biệt có giá trị khi onboard. Đồng đội mới có thể clone, chạy và shipping mà không cần tham quan tool tùy chỉnh.
Tooling không chỉ là “build.” Trong đa số đội Go, baseline thực dụng là ngắn và lặp lại:
gofmt (và đôi khi goimports)go doc cùng với comment package hiển thị sạch sẽgo test (kể cả -race khi cần)go mod tidy, tuỳ chọn go mod vendor)go vet (và một chính sách lint nhỏ nếu cần)Mục tiêu giữ danh sách này nhỏ vừa là xã hội vừa là kỹ thuật: ít lựa chọn hơn nghĩa là ít tranh luận hơn, và nhiều thời gian hơn để ship.
Bạn vẫn cần quy ước đội—nhưng giữ chúng nhẹ. Một /CONTRIBUTING.md ngắn hoặc /docs/go.md có thể ghi lại vài quyết định không nằm trong mặc định (lệnh CI, ranh giới module, cách đặt tên package). Mục tiêu là một tham chiếu nhỏ, sống—không phải cẩm nang quy trình.
"Build nhanh" không chỉ cắt vài giây biên dịch. Nó là phản hồi nhanh: thời gian từ “tôi thay đổi” đến “tôi biết nó có đúng.” Vòng lặp đó bao gồm biên dịch, liên kết, test, linter, và thời gian chờ nhận tín hiệu từ CI.
Khi phản hồi nhanh, kỹ sư tự nhiên thực hiện thay đổi nhỏ, an toàn hơn. Bạn sẽ thấy nhiều commit dần dần, ít “mega-PR”, và ít thời gian debug nhiều biến cùng lúc.
Vòng lặp nhanh cũng khuyến khích chạy test thường xuyên. Nếu go test ./... rẻ, người ta sẽ chạy trước khi push, không phải sau một comment review hay lỗi CI. Qua thời gian, hành vi này cộng dồn: ít build hỏng, ít khoảnh khắc "dừng dây chuyền", và ít chuyển đổi ngữ cảnh.
Build local chậm không chỉ lãng phí thời gian; nó thay đổi thói quen. Người ta trì hoãn test, gom thay đổi, và giữ nhiều trạng thái trí nhớ khi chờ. Điều đó tăng rủi ro và làm lỗi khó xác định hơn.
CI chậm thêm một lớp chi phí: thời gian chờ trong hàng và "thời gian chết." Một pipeline 6‑phút vẫn có thể cảm thấy như 30 phút nếu dính sau các job khác, hoặc nếu lỗi đến khi bạn đã chuyển sang task khác. Kết quả là chú ý bị phân mảnh, nhiều làm lại, và thời gian từ ý tưởng đến merge dài hơn.
Bạn có thể quản lý tốc độ build như bất kỳ kết quả engineering nào bằng cách theo dõi vài con số đơn giản:
Ngay cả đo lường nhẹ nhàng—ghi lại hàng tuần—giúp đội phát hiện suy giảm sớm và biện minh cho công việc cải thiện vòng phản hồi. Build nhanh không phải thứ thích có; nó là hệ số nhân hàng ngày cho sự tập trung, chất lượng và động lực.
Concurrency nghe trừu tượng cho đến khi bạn mô tả nó bằng ngôn ngữ con người: chờ, phối hợp và giao tiếp.
Một nhà hàng có nhiều đơn đang làm. Bếp không hẳn là “làm nhiều thứ cùng một lúc” bằng việc khâu các tác vụ phải chờ—nguyên liệu, lò, nhau. Điều quan trọng là cách đội điều phối để đơn không lẫn lộn và không làm trùng việc.
Go coi concurrency là thứ bạn có thể diễn đạt trực tiếp trong code mà không biến nó thành câu đố.
Ý điểm không phải goroutine là phép màu. Mà là chúng nhỏ đủ để dùng thường xuyên, và channel làm câu chuyện "ai nói với ai" trở nên hiển thị.
Quy tắc này ít là khẩu hiệu hơn là cách giảm bất ngờ. Nếu nhiều goroutine cùng chạm vào cấu trúc dữ liệu chia sẻ, bạn buộc phải suy nghĩ về thời gian và lock. Nếu thay vào đó chúng gửi giá trị qua channel, bạn thường giữ quyền sở hữu rõ ràng: một goroutine sản xuất, một goroutine tiêu thụ, và channel là bàn giao.
Tưởng tượng xử lý file upload:
Một pipeline đọc ID file, một worker pool parse chúng đồng thời, và giai đoạn cuối ghi kết quả.
Hủy bỏ quan trọng khi user đóng tab hoặc request timeout. Trong Go, bạn có thể luồn context.Context qua các giai đoạn và để worker dừng nhanh khi context kết thúc, thay vì tiếp tục công việc tốn kém “vì nó đã bắt đầu.”
Kết quả là concurrency đọc như một workflow: input, bàn giao, và điều kiện dừng—giống phối hợp giữa người hơn là mê cung trạng thái chia sẻ.
Concurrency trở nên khó khi “chuyện gì xảy ra” và “nơi nào xảy ra” không rõ. Mục tiêu không phải khoe sự thông minh—mà là làm luồng rõ ràng cho người đọc kế tiếp (thường là bạn trong tương lai).
Đặt tên rõ là một tính năng concurrency. Nếu một goroutine được khởi, tên hàm nên giải thích tại sao nó tồn tại, không phải cách nó thực hiện: fetchUserLoop, resizeWorker, reportFlusher. Kết hợp với hàm nhỏ làm một việc—đọc, biến đổi, ghi—mỗi goroutine có trách nhiệm rõ ràng.
Thói quen hữu ích là tách “dây nối” khỏi “công việc”: một hàm dựng channel, context, và goroutine; hàm worker làm logic nghiệp vụ. Điều đó giúp dễ lý giải vòng đời và shutdown.
Concurrency vô hạn thường thất bại theo cách buồn tẻ: bộ nhớ tăng, queue đầy, và shutdown lộn xộn. Ưu tiên queue có giới hạn (buffered channel với kích thước xác định) để backpressure rõ ràng.
Dùng context.Context để điều khiển vòng đời, và coi timeout là một phần API:
Channel đọc tốt khi bạn di chuyển dữ liệu hoặc điều phối sự kiện (fan-out worker, pipeline, tín hiệu hủy). Mutex đọc tốt khi bạn bảo vệ trạng thái chia sẻ với các phần tới hạn nhỏ.
Quy tắc: nếu bạn thấy mình gửi “lệnh” qua channel chỉ để mutate struct, hãy cân nhắc lock thay vì vậy.
Hoàn toàn ổn khi trộn mô hình. Một sync.Mutex quanh một map có thể dễ hiểu hơn là dựng một goroutine “owner” cho map và hàng chờ request/response. Thực dụng ở đây là chọn công cụ giữ code rõ ràng—và giữ cấu trúc concurrency nhỏ nhất có thể.
Lỗi concurrency hiếm khi thất bại ầm ĩ. Thường chúng ẩn sau "works on my machine" về timing và chỉ hiện dưới tải cao, CPU chậm, hoặc sau refactor nhỏ đổi lịch trình.
Rò rỉ: goroutine không bao giờ thoát (thường vì không ai đọc từ channel, hoặc một select không thể tiến). Chúng không luôn crash—chỉ khiến CPU và bộ nhớ tăng dần.
Deadlock: hai (hoặc nhiều) goroutine chờ nhau vô hạn. Ví dụ kinh điển là giữ một lock trong khi cố gửi lên channel cần goroutine khác cũng muốn lock.
Block im lặng: code treo mà không panic. Một send trên channel không đệm mà không có receiver, một nhận trên channel không bao giờ đóng, hoặc một select thiếu default/timeout có thể trông bình thường trong diff.
Data race: trạng thái chia sẻ truy cập không đồng bộ. Chúng đặc biệt khó chịu vì có thể qua test trong nhiều tháng rồi mới phá hỏng dữ liệu production.
Code đồng thời phụ thuộc vào các xen kẽ (interleavings) không thấy được trong PR. Reviewer thấy một goroutine và một channel gọn, nhưng không thể chứng minh: “Goroutine này luôn dừng chứ?”, “Có luôn receiver không?”, “Nếu upstream cancel thì sao?”, “Nếu cuộc gọi này block thì sao?” Những thay đổi nhỏ (kích thước buffer, đường xử lý lỗi, return sớm) có thể phá vỡ giả định.
Dùng timeout và cancellation (context.Context) để các hoạt động có đường thoát rõ ràng.
Thêm logging có cấu trúc quanh biên (start/stop, send/receive, cancel/timeout) để các stall dễ chẩn đoán.
Chạy race detector trong CI (go test -race ./...) và viết test căng concurrency (chạy lặp, test song song, assertion có giới hạn thời gian).
Thực dụng hệ thống đổi lấy sự rõ ràng bằng cách thu hẹp tập "cách làm". Đó là thỏa thuận: ít cách làm hơn có nghĩa ít bất ngờ hơn, onboard nhanh hơn, và code dự đoán được. Nhưng đôi khi bạn sẽ cảm thấy như đang làm việc với một tay bị buộc sau lưng.
API và pattern. Khi đội chuẩn hoá trên một vài pattern (một logging, một style config, một router HTTP), thư viện “tốt nhất” cho niche cụ thể có thể không dùng được. Điều này gây bực khi biết một tool chuyên dụng có thể tiết kiệm thời gian—nhất là ở các trường hợp biên.
Generics và abstraction. Generics của Go hữu ích, nhưng văn hoá thực dụng vẫn hoài nghi các hệ type phức tạp và meta-programming. Nếu bạn đến từ hệ sinh thái ưa abstraction nặng, sở thích cho code rõ ràng, cụ thể có thể khiến lặp lại.
Lựa chọn kiến trúc. Sự đơn giản thường đẩy bạn đến ranh giới dịch vụ rõ ràng và cấu trúc dữ liệu thẳng thắn. Nếu bạn hướng tới nền tảng cực kỳ cấu hình hay framework, quy tắc “giữ nhàm” có thể hạn chế tính linh hoạt.
Dùng một thử nghiệm nhẹ trước khi lệch hướng:
Nếu bạn ngoại lệ, hãy coi đó như thí nghiệm có kiểm soát: document lý do, phạm vi (chỉ package/dịch vụ này), và quy tắc sử dụng. Quan trọng nhất, giữ các quy ước cốt lõi nhất quán để đội vẫn chia sẻ mô hình tinh thần chung—ngay cả khi có vài ngoại lệ chính đáng.
Build nhanh và công cụ đơn giản không chỉ là tiện ích cho dev—chúng định hình cách bạn ship an toàn và phục hồi bình tĩnh khi có sự cố.
Khi codebase build nhanh và dự đoán được, đội chạy CI thường xuyên hơn, giữ branch nhỏ hơn, và phát hiện vấn đề tích hợp sớm hơn. Điều đó giảm lỗi "bất ngờ" khi deploy, nơi chi phí sai sót cao nhất.
Lợi ích vận hành rõ nhất trong response incident. Nếu rebuild, test và đóng gói chỉ mất vài phút thay vì vài giờ, bạn có thể lặp fix khi ngữ cảnh còn tươi. Bạn cũng giảm cám dỗ "hot patch" production mà không xác thực đầy đủ.
Sự cố hiếm khi giải quyết bằng sự thông minh; chúng giải quyết bằng tốc độ hiểu. Module nhỏ, dễ đọc giúp trả lời nhanh các câu hỏi cơ bản: Có gì thay đổi? Luồng request đi đâu? Điều gì có thể bị ảnh hưởng?
Ưu tiên explicit của Go (và tránh các hệ thống build quá ma thuật) thường tạo ra artifacts và binary dễ inspect và redeploy. Sự đơn giản đó chuyển thành ít thứ để debug lúc 2 giờ sáng.
Một setup vận hành thực dụng thường bao gồm:
Không có cái gì là one-size-fits-all. Môi trường có quy định, nền tảng legacy và tổ chức lớn có thể cần quy trình nặng hơn. Ý là coi sự đơn giản và tốc độ như tính năng độ tin cậy—không phải sở thích thẩm mỹ.
Thực dụng hệ thống chỉ hiệu quả khi nó xuất hiện trong thói quen hàng ngày—không phải trên một bản tuyên ngôn. Mục tiêu là giảm "thuế quyết định" (dùng công cụ nào? config nào?) và tăng mặc định chung (một cách format, test, build và ship).
1) Bắt đầu với formatter như mặc định bất khả kháng.
Áp dụng gofmt (và tuỳ chọn goimports) và làm tự động: lưu là chạy trong editor cộng pre-commit hoặc kiểm tra CI. Đây là cách nhanh nhất để loại tranh luận và làm diff dễ review.
2) Chuẩn hóa cách chạy test local.
Chọn một lệnh duy nhất mọi người nhớ (ví dụ go test ./...). Ghi vào CONTRIBUTING ngắn. Nếu thêm kiểm tra khác (lint, vet), giữ chúng dự đoán được và có doc.
3) Làm CI phản chiếu cùng workflow đó—rồi tối ưu cho tốc độ.
CI nên chạy cùng lệnh core mà dev chạy local, cộng chỉ những cổng bạn thực sự cần. Sau khi ổn định, tập trung vào tốc độ: cache phụ thuộc, tránh rebuild mọi thứ trên mỗi job, và tách suite chậm để đường phản hồi nhanh vẫn nhanh. Nếu bạn so sánh các option CI, giữ chi phí/giới hạn minh bạch cho đội (xem /pricing).
Nếu bạn thích thiên hướng của Go về một bộ mặc định nhỏ, đáng để nhắm tới cảm giác tương tự trong cách prototype và ship.
Koder.ai là nền tảng vibe-coding cho phép đội tạo app web, backend và mobile từ giao diện chat—vẫn giữ các lối thoát engineering như xuất mã nguồn, triển khai/host, và snapshot với rollback. Các lựa chọn stack có chủ ý (React cho web, Go + PostgreSQL cho backend, Flutter cho mobile), điều này giảm "sprawl toolchain" ở giai đoạn sớm và giữ vòng lặp lặp nhanh khi bạn xác thực ý tưởng.
Chế độ lập kế hoạch cũng giúp đội áp dụng thực dụng từ đầu: thống nhất hình dạng đơn giản nhất của hệ thống, rồi triển khai dần với phản hồi nhanh.
Bạn không cần họp mới—chỉ vài chỉ số nhẹ bạn có thể theo dõi trong doc hoặc dashboard:
Xem lại hàng tháng trong 15 phút. Nếu số xấu đi, đơn giản hoá workflow trước khi thêm quy tắc.
Để thêm ý tưởng workflow đội và ví dụ, giữ một reading list nội bộ nhỏ và luân phiên các bài từ /blog.
Thực dụng hệ thống ít là khẩu hiệu hơn là thỏa thuận làm việc hàng ngày: tối ưu cho sự hiểu của con người và phản hồi nhanh. Nếu chỉ nhớ ba trụ cột, hãy là những thứ này:
Triết lý này không phải tối giản cho mục đích tối giản. Mà là shipping phần mềm dễ thay đổi an toàn hơn: ít thành phần chuyển động, ít trường hợp đặc biệt, và ít bất ngờ khi người khác đọc code của bạn sáu tháng sau.
Chọn một đòn bẩy cụ thể—nhỏ để xong, đủ ý nghĩa để cảm nhận:
Ghi lại trước/sau: thời gian build, số bước chạy kiểm tra, hoặc thời reviewer cần hiểu thay đổi. Thực dụng kiếm được niềm tin khi nó đo được.
Nếu bạn muốn sâu hơn, đọc blog chính thức của Go về tooling, hiệu năng build, và pattern concurrency, và tìm các talk công khai của những người tạo và duy trì Go. Xem chúng như nguồn heuristic: nguyên tắc để áp dụng, không phải luật phải tuân theo.
"Thực dụng hệ thống" là khuynh hướng ưu tiên các quyết định giúp hệ thống thực tế dễ xây dựng, vận hành và thay đổi khi có áp lực thời gian.
Một phép thử nhanh là hỏi liệu lựa chọn đó có cải thiện công việc hàng ngày, giảm bất ngờ trong production, và vẫn dễ hiểu sau vài tháng—đặc biệt với người mới vào mã nguồn.
Độ phức tạp tạo ra một khoản thuế cho hầu hết mọi hoạt động: review, debug, onboard, xử lý sự cố, và thậm chí là thực hiện thay đổi nhỏ một cách an toàn.
Một kỹ thuật khéo léo giúp một người tiết kiệm vài phút có thể khiến cả đội mất hàng giờ sau đó, vì nó tăng số lựa chọn, các trường hợp biên và tải nhận thức.
Các công cụ chuẩn làm giảm "chi phí lựa chọn." Nếu mỗi repo dùng tập script, formatter và quy ước khác nhau, thời gian sẽ rò rỉ vào việc thiết lập và tranh luận.
Các mặc định của Go (như gofmt, go test, và modules) làm cho luồng công việc trở nên dễ dự đoán: nếu bạn biết Go, thường bạn có thể đóng góp ngay—không cần học một toolchain tùy chỉnh trước.
Một formatter chung như gofmt loại bỏ tranh luận về style và các diff ồn ào, khiến review tập trung vào hành vi và độ đúng đắn.
Triển khai thực tế:
Build nhanh rút ngắn thời gian từ “tôi thay đổi” đến “tôi biết nó có hoạt động không”. Vòng lặp ngắn hơn khuyến khích commit nhỏ hơn, test thường xuyên hơn, và ít PR khổng lồ hơn.
Nó cũng giảm chuyển đổi ngữ cảnh: khi kiểm tra nhanh, người ta không trì hoãn test rồi phải debug nhiều biến cùng lúc.
Theo dõi vài con số liên quan trực tiếp đến trải nghiệm dev và tốc độ giao hàng:
Dùng những chỉ số này để phát hiện suy giảm sớm và biện minh cho công việc cải thiện vòng phản hồi.
Một baseline công cụ Go tối thiểu mà đội có thể chuẩn hoá thường là:
gofmtgo test ./...go vet ./...go mod tidyRồi để CI phản chiếu cùng các lệnh developers chạy trên local. Tránh các bước bất ngờ trong CI mà không tồn tại trên máy dev; điều đó giữ cho lỗi dễ chẩn đoán và giảm mất đồng bộ "works on my machine".
Các lỗi concurrency phổ biến gồm:
Các biện pháp hữu ích:
Dùng channel khi bạn đang mô tả luồng dữ liệu hoặc điều phối sự kiện (pipeline, worker pool, fan-out/fan-in, tín hiệu hủy).
Dùng mutex khi bạn đang bảo vệ trạng thái chia sẻ với các phần tới hạn nhỏ.
Nếu bạn gửi "lệnh" qua channel chỉ để mutate một struct, sync.Mutex có thể rõ ràng hơn. Thực dụng là chọn mô hình đơn giản nhất mà người đọc vẫn hiểu rõ.
Nên ngoại lệ khi chuẩn hiện tại thực sự thất bại (về hiệu năng, độ đúng, bảo mật, hoặc gây đau đầu bảo trì), không phải chỉ vì một công cụ mới thú vị.
Một bài kiểm tra ngoại lệ nhẹ:
Nếu đi tiếp, giới hạn phạm vi (một package/dịch vụ), document lý do và giữ các quy ước cốt lõi ổn định để onboarding vẫn mượt.
context.Context xuyên suốt công việc đồng thời và tôn trọng hủy bỏ.go test -race ./... trong CI.