Home | Blog | Data study

Chi Phí Thực Của Chuyển Đổi Ngữ Cảnh: 5 Triệu GitHub PR

Chúng tôi tổng hợp dữ liệu từ hơn 5 triệu PR để đo chi phí chuyển đổi ngữ cảnh thực sự cho lập trình viên – và nó không phải ở nơi bạn nghĩ.

By Ellis Keane · 2026-03-29

Chi phí chuyển đổi ngữ cảnh mà hầu hết các bài viết trích dẫn – 23 phút để tập trung lại sau khi bị gián đoạn, từ nghiên cứu của Gloria Mark tại UC Irvine – là một phát hiện thực từ một nghiên cứu thực. Nhưng nó đo lường các nhân viên tri thức nói chung vào năm 2008, không phải kỹ sư phần mềm. Và ngành công nghiệp blog post nhân 23 phút với số lần gián đoạn giả định để tạo ra những con số thiệt hại hàng năm đáng báo động (luôn kèm theo ảnh stock của ai đó đang ôm đầu) đang làm điều mà nghiên cứu gốc chưa bao giờ dự định.

Tôi có lợi ích cá nhân trong câu hỏi này. Ở một công ty trước đây, tôi đã dành – và đây không phải là cường điệu – 80 đến 100 phần trăm của một số ngày chỉ để làm một bộ định tuyến con người. Không viết code, không xem xét nó. Chuyển tiếp thông tin giữa mọi người và các công cụ, vì không có hệ thống nào kết nối chúng. Trải nghiệm đó là một phần lý do chúng tôi xây dựng Sugarbug, nhưng cũng là lý do tôi hoài nghi về các máy tính chi phí chuyển đổi ngữ cảnh tiêu chuẩn. Chúng đo lường sự gián đoạn. Chúng không đo lường những ngày bạn không bao giờ đến được việc mà bạn lẽ ra phải làm.

Vì vậy, chúng tôi muốn biết chuyển đổi ngữ cảnh thực sự tốn bao nhiêu trong công việc kỹ thuật – không phải theo thuật ngữ năng suất lập trình viên trừu tượng, mà được đo bằng thứ mà các nhóm sản xuất hàng ngày: pull request. Chúng tôi tổng hợp kết quả từ ba nghiên cứu quy mô lớn bao gồm hơn 5 triệu PR trên hàng nghìn dự án mã nguồn mở, và xem xét điều gì thực sự thúc đẩy thời gian xem xét pull request.

Phát hiện chính: chuyển đổi ngữ cảnh đắt nhất không phải là thông báo Slack làm gián đoạn luồng công việc của bạn. Đó là pull request nằm trong hàng đợi xem xét suốt một ngày, buộc tác giả phải xây dựng lại toàn bộ mô hình tư duy khi câu hỏi cuối cùng đến.

Các Tập Dữ Liệu Chúng Tôi Sử Dụng

Chúng tôi không tạo một công cụ thu thập dữ liệu riêng và phân tích 10.000 PR một cách cô lập. Chúng tôi tổng hợp kết quả từ hai nghiên cứu được bình duyệt và một tập dữ liệu ngành lớn, sau đó kiểm tra chéo các kết luận của chúng.

stat: "3.35M" headline: "Số pull request được Zhang và cộng sự phân tích" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"

Ba tập dữ liệu chính:

Zhang và cộng sự (2022), được bình duyệt: 3.347.937 PR đã đóng trên 11.230 dự án. Sử dụng hồi quy tuyến tính hiệu ứng hỗn hợp để xác định điều gì gây ra độ trễ xem xét PR. Được công bố trên Empirical Software Engineering.
Adadot (2023), tập dữ liệu ngành: hơn 300.000 PR đã được hợp nhất từ ~30.000 lập trình viên. Không được bình duyệt, nhưng mẫu lớn và phương pháp luận (tương quan Kendall tau) minh bạch. Tập trung vào kích thước PR so với lead time.
Nghiên cứu xem xét đa luồng (2019), được bình duyệt: 1.836.280 PR trên 760 dự án GitHub. Được công bố trên Information and Software Technology. Xem xét hành vi xem xét đồng thời – một proxy trực tiếp cho chuyển đổi ngữ cảnh trong xem xét code.

Chúng tôi đối chiếu chéo những điều này với Báo cáo State of DevOps 2024 của DORA và Báo cáo Trải nghiệm Lập trình viên 2024 của Atlassian (khảo sát hơn 2.100 lập trình viên về chuyển đổi ngữ cảnh, năng suất lập trình viên và khía cạnh con người của phương trình).

Hàng Đợi Mới Là Kẻ Giết Chết Thực Sự

Zhang và cộng sự phát hiện rằng thời gian để một PR nhận được phản hồi đầu tiên – bình luận đầu tiên, đánh giá đầu tiên, bất cứ điều gì đầu tiên – giải thích 58,7% phương sai trong tổng vòng đời của PR. Đó là yếu tố dự báo mạnh nhất được quan sát trong tập dữ liệu – vượt trước kích thước PR, độ phức tạp của code, hoặc số lượng file thay đổi! Không gần chút nào.

Chi phí lớn nhất của chuyển đổi ngữ cảnh trong xem xét code không phải là bản thân việc chuyển đổi – mà là hàng đợi hình thành khi mọi người bận chuyển đổi giữa các việc khác.

Hãy nghĩ về ý nghĩa thực tế của điều này. Một kỹ sư mở PR lúc 10 giờ sáng. Người xem xét được chỉ định đang làm việc sâu trong nhánh tính năng của họ, hoặc trong một cuộc họp, hoặc đang phân loại tin nhắn Slack (và thành thật mà nói, có lẽ cả ba theo thứ tự). PR ngồi chờ. Đến 3 giờ chiều khi ai đó lấy nó lên, tác giả đã chuyển sang việc hoàn toàn khác. Bây giờ người xem xét có câu hỏi, nghĩa là tác giả phải chuyển đổi ngữ cảnh trở lại code họ đã viết năm giờ trước, xây dựng lại mô hình tư duy và phản hồi. Phản hồi đó đến lúc 4:30 chiều, nhưng người xem xét đã về nhà.

PR lại lão hóa thêm một ngày.

Dữ liệu gợi ý đây là vấn đề về hàng đợi nhiều hơn là vấn đề về kỷ luật – và chi phí chuyển đổi ngữ cảnh của hàng đợi đó tích lũy theo những cách mà các máy tính gián đoạn hoàn toàn bỏ qua.

PR Nhỏ Sẽ Không Cứu Bạn

Bạn đã nghe điều này trước đây: PR nhỏ hơn được xem xét nhanh hơn, vì vậy hãy giữ PR của bạn nhỏ. Điều đó không sai, nhưng kích thước hiệu ứng (thực sự) nhỏ hơn bạn mong đợi.

Phân tích hơn 300.000 PR của Adadot tìm thấy tương quan Kendall tau chỉ 0,06 giữa kích thước PR và lead time – một mối liên hệ yếu, mặc dù nghiên cứu không báo cáo khoảng tin cậy cho con số tổng hợp. Các PR dưới 100 dòng có xác suất khoảng 80% hoàn thành trong một tuần, nghe có vẻ tốt cho đến khi bạn nhận ra đó là tỷ lệ hoàn thành tương tự như một PR đã nằm trong hàng đợi xem xét của ai đó suốt sáu ngày!

stat: "0.06" headline: "Tương quan giữa kích thước PR và lead time" source: "Phân tích của Adadot từ hơn 300.000 PR của ~30.000 lập trình viên (2023)"

Phát hiện thú vị hơn: tương quan này dao động mạnh giữa các tổ chức, từ 0,1 đến gần 0,7 tùy thuộc vào công ty. Điều này gợi ý rằng kích thước PR vốn không phải là nút thắt cổ chai – văn hóa và quy trình xem xét xung quanh PR mới là. Một nhóm có nhịp xem xét mạnh có thể xử lý hiệu quả các PR lớn hơn. Một nhóm coi xem xét là thứ yếu sẽ vật lộn với PR ở bất kỳ kích thước nào.

Ngưỡng 400 dòng từ nghiên cứu xem xét code của SmartBear/Cisco vẫn là một heuristic hữu ích – dữ liệu của Adadot cũng phát hiện rằng mức độ tham gia xem xét giảm ngoài phạm vi đó. Nhưng tối ưu hóa cho PR nhỏ mà không sửa nhịp xem xét cơ bản là (và tôi nói điều này với tình cảm thực sự dành cho mọi quản lý kỹ thuật đã thử) sắp xếp lại ghế trên tàu đang chìm.

Mọi Người Đang Xem Xét Tất Cả Cùng Một Lúc

Nghiên cứu xem xét đa luồng phát hiện rằng 62% pull request liên quan đến các lập trình viên đang đồng thời xem xét nhiều PR. Quan trọng hơn, họ tìm thấy mối tương quan có ý nghĩa thống kê: nhiều đánh giá đồng thời hơn trên mỗi người xem xét có liên quan đến độ trễ giải quyết PR dài hơn.

62% pull request liên quan đến lập trình viên đồng thời xem xét nhiều PR – và xem xét đa luồng tương quan trực tiếp với thời gian giải quyết lâu hơn. attribution: Nghiên cứu xem xét đa luồng pull-request, 1,8 triệu PR trên 760 dự án

Cơ chế này trực quan (dù nghiên cứu mang tính quan sát không chứng minh hướng nhân quả). Người xem xét lấy PR #1, đọc qua diff, bắt đầu hình thành mô hình tư duy về những gì code đang cố làm. Sau đó một thông báo đến – PR #2 cần xem xét vì nó đang chặn một lần triển khai. Người xem xét chuyển đổi. Khi họ quay lại PR #1, họ phải đọc lại một nửa diff vì mô hình tư duy đã bị phân rã.

Nhân rộng điều đó cho một nhóm tám kỹ sư, mỗi người có hai hoặc ba PR mở, mỗi người xem xét cho hai hoặc ba đồng nghiệp – và chi phí điều phối bắt đầu tự giải thích. Riêng biệt, Báo cáo DORA 2024 phát hiện rằng cụm "high performer" thu hẹp từ 31% xuống 22% trong khi cụm low-performer tăng từ 17% lên 25%. DORA không tách biệt tính đồng thời xem xét PR như một yếu tố, nhưng chi phí điều phối ngày càng tăng là một đóng góp có thể có cho sự thay đổi đó.

Điều Mà Các Ước Tính Chi Phí Chuyển Đổi Ngữ Cảnh Sai

Hãy để tôi thẳng thắn về con số "50.000 đô la mỗi lập trình viên mỗi năm" được lưu hành rộng rãi trong các bài viết chi phí chuyển đổi ngữ cảnh. Phương pháp luận đằng sau hầu hết các ước tính này là: lấy thời gian tập trung lại 23 phút, nhân với số lần gián đoạn hàng ngày ước tính (thường từ 6 đến 15, tùy thuộc vào mức độ kịch tính của tác giả), nhân với mức lương theo giờ của lập trình viên và tính theo năm.

Vấn đề không phải là phép toán sai. Vấn đề là nó coi tất cả các lần chuyển đổi ngữ cảnh là tương đương. Chuyển từ việc code sâu sang một tin nhắn Slack hỏi nhóm ăn trưa ở đâu – đó là một lần chuyển đổi ngữ cảnh. Chuyển từ xem xét một PR sang xem xét một PR khác trong một codebase hoàn toàn khác – đó cũng là chuyển đổi ngữ cảnh. Nhưng chi phí nhận thức không thể so sánh được, và san phẳng chúng thành một mức lương theo giờ duy nhất che khuất nơi thiệt hại thực sự xảy ra.

Nói cụ thể: ở công việc cuối cùng của tôi, một ngày điển hình có nghĩa là chuyển đổi giữa Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster và vô số kênh Telegram và Signal – và tôi chắc chắn đang quên nửa tá. Bây giờ tôi dùng một số ít (Signal, Obsidian, Figma, GitHub, email, lịch). Chi phí mỗi lần chuyển đổi không thay đổi. Điều thay đổi là bao nhiêu ngữ cảnh đang xếp hàng chờ được chú ý – và ngữ cảnh nào thực sự quan trọng.

Dữ liệu PR gợi ý rằng các lần chuyển đổi đắt tiền là những lần tạo ra hàng đợi, không phải những lần làm gián đoạn luồng. Một lập trình viên được ping ngay lập tức (trong vài phút) để xem xét PR và thực hiện đánh giá nhanh 50 dòng – đó là gián đoạn ngắn với lợi tức cao. Một lập trình viên xếp yêu cầu xem xét đó cùng với bốn yêu cầu khác và đến với nó vào ngày mai – đó là gián đoạn dài hơn cho người xem xét nhưng tạo ra chi phí lớn hơn nhiều cho tác giả và nhóm.

Những gì máy tính chi phí đo lường

Các gián đoạn cá nhân – tần suất luồng công việc của ai đó bị phá vỡ
Thời gian tập trung lại – mất bao lâu để quay lại nhiệm vụ trước
Nhân mức lương theo giờ – các con số hàng năm đáng sợ

Những gì dữ liệu PR thực sự cho thấy

Hình thành hàng đợi – PR đang chờ phản hồi đầu tiên
Tính đồng thời xem xét – người xem xét đang xử lý nhiều PR
Độ trễ cascade – chuyển đổi ngữ cảnh của tác giả khuếch đại độ trễ của người xem xét

Ý Nghĩa Với Nhóm Của Bạn

Nếu bạn đang cố gắng giảm chi phí chuyển đổi ngữ cảnh cho các lập trình viên trong nhóm của mình, câu trả lời thực tế thật nhàm chán – đó có lẽ là lý do tại sao nó không được viết nhiều. Không phải một công cụ. Không phải một khung quy trình với chương trình chứng nhận. Đó là nhịp xem xét. (Tôi biết, tôi biết. Không ai bao giờ được thăng chức vì cải thiện nhịp xem xét.)

Các tiêu chuẩn kỹ thuật năm 2025 của LinearB, được rút ra từ 6,1 triệu PR trên 3.000 tổ chức, phát hiện rằng các nhóm đạt được chu kỳ thời gian elite (dưới 2,5 ngày) có chung một đặc điểm: họ xem xét PR nhanh chóng. Không phải vì họ có ít PR hơn, hoặc vì PR của họ nhỏ hơn (mặc dù thường là vậy), mà vì phản hồi yêu cầu xem xét trong vài giờ là chuẩn mực của nhóm, không phải một suy nghĩ sau.

Để tham khảo, Ben và tôi – một nhóm hai người – trung bình tính bằng phút cho phản hồi PR đầu tiên, không phải giờ. Đó không phải là sự khoe khoang về kỷ luật (chúng tôi không như vậy). Đó là một thỏa thuận nhóm: yêu cầu xem xét là thông báo duy nhất bạn không xếp hàng. Các CI action và kiểm tra tự động xử lý các kiểm tra cơ học, có nghĩa là đánh giá của con người – phần đòi hỏi ngữ cảnh thực sự – ngắn hơn và xảy ra ngay lập tức. Thỏa thuận đến trước. Công cụ chỉ làm cho nó bền vững.

Trên thực tế, điều đó có nghĩa là:

Đo thời gian đến phản hồi đầu tiên, không chỉ chu kỳ thời gian. Nếu bạn đang theo dõi các chỉ số DORA, hãy thêm cái này. Đó là yếu tố dự báo mạnh nhất duy nhất về thông lượng PR (giải thích 58,7% phương sai vòng đời, theo Zhang và cộng sự).

Hạn chế tính đồng thời xem xét. Nếu người xem xét có ba yêu cầu xem xét đang chờ, yêu cầu thứ tư sẽ không được xem xét tốt anyway. Dữ liệu xem xét đa luồng cho thấy mối liên hệ rõ ràng giữa tính đồng thời và độ trễ. Bắt đầu với giới hạn WIP là hai đánh giá đồng thời và theo dõi tác động.

Dừng tối ưu hóa kích thước PR một cách độc lập. PR nhỏ thì tốt, nhưng chúng không phải là sự thay thế cho một nhóm thực sự xem xét mọi thứ. Một nhóm tạo ra hai mươi PR 50 dòng mỗi ngày với tồn đọng xem xét 48 giờ tệ hơn một nhóm tạo ra năm PR 200 dòng với đánh giá trong ngày.

Thừa nhận rằng xem xét là công việc thực sự. Khảo sát năm 2024 của Atlassian phát hiện rằng 69% lập trình viên mất hơn 8 giờ mỗi tuần vì sự kém hiệu quả. Xem xét không nhất thiết phải là một trong những sự kém hiệu quả đó – nhưng chỉ khi nó được coi là hoạt động kỹ thuật hàng đầu, không phải là sự gián đoạn công việc "thực sự".

Và đây là phần mà không ai trong không gian công cụ năng suất (kể cả chúng tôi, thành thật mà nói) muốn nói thẳng: sự can thiệp có tác động nhất đối với chi phí chuyển đổi ngữ cảnh trong các nhóm kỹ thuật không phải là một công cụ. Đó là một thỏa thuận nhóm về thời điểm các PR được xem xét. Nếu chuẩn mực ngầm của nhóm bạn là "Tôi sẽ xem xét khi có thời gian rảnh", không có công cụ nào sẽ ngăn được cascade hàng đợi mà dữ liệu PR tiết lộ.

Công cụ giúp ích – có thể xem toàn bộ ngữ cảnh của một PR mà không cần mở bốn tab trình duyệt giúp giảm tải nhận thức mỗi lần chuyển đổi, và làm rõ đánh giá nào đang chặn công việc của người khác giúp ưu tiên. Nhưng đòn bẩy cốt lõi là thỏa thuận, và các thỏa thuận là miễn phí. Không cần máy tính 23 phút.

Chuyển đổi ngữ cảnh đắt nhất không phải là thông báo làm gián đoạn luồng công việc của bạn. Đó là yêu cầu xem xét nằm trong hàng đợi suốt một ngày, buộc tác giả phải xây dựng lại ngữ cảnh tư duy khi câu hỏi cuối cùng đến.

Nhận trí tuệ tín hiệu trực tiếp vào hộp thư của bạn.

Câu Hỏi Thường Gặp

Q: Chi phí chuyển đổi ngữ cảnh mỗi lập trình viên mỗi năm là bao nhiêu? A: Ước tính có sự chênh lệch, nhưng nghiên cứu nền tảng mỏng hơn nhiều so với hầu hết các bài viết gợi ý. Nghiên cứu của Gloria Mark tại UC Irvine phát hiện 23 phút tập trung lại sau mỗi lần bị gián đoạn, và khảo sát năm 2024 của Atlassian với hơn 2.100 lập trình viên cho thấy 69% mất hơn 8 giờ mỗi tuần vì sự kém hiệu quả. Con số tính bằng đô la phụ thuộc nhiều vào giả định về mức lương, tần suất bị gián đoạn và cách bạn định nghĩa "chuyển đổi" – đó là lý do chúng tôi tập trung vào dữ liệu PR.

Q: Sugarbug có giúp giảm chuyển đổi ngữ cảnh cho các nhóm kỹ thuật không? A: Có. Sugarbug kết nối các công cụ như Linear, GitHub, Slack và Figma vào một đồ thị tri thức duy nhất, để các kỹ sư có thể thấy toàn bộ ngữ cảnh của một nhiệm vụ – PR liên quan, cuộc thảo luận trên Slack, bình luận Figma – mà không cần mở bốn tab. Mục tiêu là ít chuyển đổi hơn, không phải ít công cụ hơn.

Q: Kích thước pull request lý tưởng để giảm thiểu độ trễ xem xét là bao nhiêu? A: Nghiên cứu từ phân tích hơn 300.000 PR của Adadot phát hiện rằng các PR dưới 100 dòng code có xác suất khoảng 80% được hoàn thành trong một tuần. Trên 400 dòng, cả chất lượng xem xét lẫn tốc độ hoàn thành đều giảm. Các PR nhỏ hơn cũng giảm gánh nặng chuyển đổi ngữ cảnh của người xem xét.

Q: Sugarbug có tích hợp với GitHub pull requests không? A: Có. Sugarbug thu thập hoạt động GitHub – PR, bình luận, đánh giá và thay đổi trạng thái – và liên kết chúng với các tín hiệu liên quan trong các công cụ khác của bạn. Nếu một vấn đề Linear tạo ra PR và một luồng Slack tranh luận về cách tiếp cận, Sugarbug sẽ tự động kết nối cả ba.

Q: Thống kê "23 phút để tập trung lại" đến từ đâu? A: Nó đến từ nghiên cứu của Gloria Mark tại UC Irvine, được công bố trong "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Nghiên cứu phát hiện rằng người lao động mất trung bình 23 phút 15 giây để quay lại nhiệm vụ ban đầu sau khi bị gián đoạn. Đáng lưu ý là nghiên cứu quan sát các nhân viên tri thức nói chung, không phải cụ thể là kỹ sư phần mềm.