ต้นทุนการสลับบริบทที่แท้จริง: 5 ล้าน GitHub PR บอกอะไรเรา
เราวิเคราะห์ข้อมูลจาก PR กว่า 5 ล้านรายการเพื่อวัดต้นทุนที่แท้จริงของการสลับบริบทสำหรับนักพัฒนา – และมันไม่ได้อยู่ที่ที่คุณคิด
By Ellis Keane · 2026-03-29
ต้นทุนการสลับบริบทที่บทความส่วนใหญ่อ้างถึง – 23 นาทีในการโฟกัสซ้ำหลังถูกขัดจังหวะ จากงานวิจัยของ Gloria Mark แห่ง UC Irvine – เป็นผลลัพธ์จริงจากการศึกษาจริง แต่งานวิจัยนั้นวัดผลกับแรงงานความรู้ทั่วไปในปี 2008 ไม่ใช่วิศวกรซอฟต์แวร์ และอุตสาหกรรมบล็อกโพสต์ที่นำ 23 นาทีคูณกับจำนวนการขัดจังหวะที่สันนิษฐานเพื่อผลิตตัวเลขต้นทุนรายปีที่น่าตกใจ (มักมาพร้อมรูปสต็อกของคนกุมหัว) กำลังทำสิ่งที่งานวิจัยต้นฉบับไม่เคยตั้งใจ
ผมมีส่วนได้ส่วนเสียส่วนตัวในคำถามนี้ ที่บริษัทก่อนหน้า ผมใช้เวลา – และนี่ไม่ได้พูดเกินจริง – 80 ถึง 100 เปอร์เซ็นต์ของบางวันเป็นเพียงเราเตอร์มนุษย์ ไม่ได้เขียนโค้ด ไม่ได้รีวิวมัน แค่ส่งต่อข้อมูลระหว่างคนและเครื่องมือ เพราะไม่มีระบบเดียวที่เชื่อมต่อพวกเขา ประสบการณ์นั้นเป็นส่วนหนึ่งของสาเหตุที่เราสร้าง Sugarbug แต่ยังเป็นสาเหตุที่ผมสงสัยเครื่องคำนวณต้นทุนการสลับบริบทมาตรฐาน พวกมันวัดการขัดจังหวะ แต่ไม่ได้วัดวันที่คุณใช้โดยไม่เคยได้ทำสิ่งที่ควรทำตั้งแต่แรก
ดังนั้นเราจึงต้องการรู้ว่าการสลับบริบทมีต้นทุนจริงๆ เท่าไรในงานวิศวกรรม – ไม่ใช่ในแง่ผลิตภาพนักพัฒนาที่เป็นนามธรรม แต่วัดจากสิ่งที่ทีมผลิตในแต่ละวัน: pull request เราสังเคราะห์ผลการศึกษาจากสามงานวิจัยขนาดใหญ่ที่ครอบคลุม PR กว่า 5 ล้านรายการในโปรเจกต์โอเพนซอร์สหลายพันโปรเจกต์ และดูว่าอะไรเป็นตัวขับเคลื่อนเวลาการรีวิว pull request อย่างแท้จริง
ผลลัพธ์หลัก: การสลับบริบทที่แพงที่สุดไม่ใช่การแจ้งเตือน Slack ที่ทำลายสมาธิของคุณ มันคือ pull request ที่นั่งอยู่ในคิวรีวิวเป็นวัน บังคับให้ผู้เขียนต้องสร้างโมเดลทางความคิดทั้งหมดใหม่เมื่อคำถามมาถึงในที่สุด
ชุดข้อมูลที่เราใช้
เราไม่ได้สร้างตัวดึงข้อมูลเองและวิเคราะห์ PR 10,000 รายการแยกกัน เราสังเคราะห์ผลจากการศึกษาที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญสองงานและชุดข้อมูลอุตสาหกรรมหนึ่งชุด แล้วทดสอบข้อสรุปของพวกเขากับกันและกัน
stat: "3.35M" headline: "จำนวน pull request ที่ Zhang et al. วิเคราะห์" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
ชุดข้อมูลหลักสามชุด:
- Zhang et al. (2022) งานวิจัยที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญ: 3,347,937 PR ที่ปิดแล้วใน 11,230 โปรเจกต์ ใช้ mixed-effects linear regression เพื่อระบุสิ่งที่ขับเคลื่อนความล่าช้าในการรีวิว PR ตีพิมพ์ใน Empirical Software Engineering
- Adadot (2023) ชุดข้อมูลอุตสาหกรรม: PR ที่ถูก merge กว่า 300,000 รายการจากนักพัฒนาประมาณ 30,000 คน ไม่ได้ผ่านการตรวจสอบโดยผู้เชี่ยวชาญ แต่ตัวอย่างมีขนาดใหญ่และวิธีการ (Kendall tau correlation) โปร่งใส เน้นที่ขนาด PR กับ lead time
- การศึกษา multi-reviewing (2019) งานวิจัยที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญ: 1,836,280 PR ใน 760 โปรเจกต์ GitHub ตีพิมพ์ใน Information and Software Technology ตรวจสอบพฤติกรรมการรีวิวพร้อมกัน – ซึ่งเป็น proxy โดยตรงของการสลับบริบทในการรีวิวโค้ด
เราอ้างอิงข้อมูลเหล่านี้กับ 2024 DORA State of DevOps Report และ รายงานประสบการณ์นักพัฒนาปี 2024 ของ Atlassian (สำรวจนักพัฒนากว่า 2,100 คนเกี่ยวกับการสลับบริบท ผลิตภาพนักพัฒนา และด้านมนุษย์ของสมการ)
คิวคือตัวฆ่าที่แท้จริง
Zhang et al. พบว่าเวลาที่ PR ต้องรอให้ได้รับการตอบสนองครั้งแรก – คอมเมนต์แรก การรีวิวแรก อะไรก็แรก – อธิบาย 58.7% ของความแปรผัน ในอายุขัยรวมของ PR นั่นคือตัวพยากรณ์ที่สังเกตพบแข็งแกร่งที่สุดในชุดข้อมูล – ก้าวหน้ากว่าขนาด PR ความซับซ้อนของโค้ด หรือจำนวนไฟล์ที่เปลี่ยนแปลง! ห่างกันไม่น้อยเลย
ต้นทุนที่ใหญ่ที่สุดของการสลับบริบทในการรีวิวโค้ดไม่ใช่การสลับตัวเอง – มันคือคิวที่ก่อตัวขึ้นในขณะที่ทุกคนกำลังยุ่งกับการสลับระหว่างสิ่งอื่น
ลองนึกถึงความหมายของมันในทางปฏิบัติ วิศวกรเปิด PR เวล 10 โมงเช้า ผู้รีวิวที่กำหนดไว้กำลังมุ่งหน้ากับ feature branch ของตัวเอง หรืออยู่ในการประชุม หรือกำลังคัดกรองข้อความ Slack (และตามความเป็นจริงอาจเป็นทั้งสามอย่างตามลำดับ) PR นั้นก็นั่งรอ เมื่อถึงเวล 3 โมงบ่าย ผู้เขียนได้ย้ายไปทำอย่างอื่นแล้ว ตอนนี้ผู้รีวิวมีคำถาม ซึ่งหมายความว่าผู้เขียนต้องสลับบริบทกลับไปยังโค้ดที่เขียนห้าชั่วโมงที่แล้ว สร้างโมเดลทางความคิดใหม่ และตอบ การตอบนั้นมาถึงเวล 4:30 โมง แต่ผู้รีวิวกลับบ้านไปแล้ว
PR นั้นก็แก่ขึ้นอีกหนึ่งวัน
ข้อมูลชี้ให้เห็นว่านี่เป็นปัญหาของคิวมากกว่าปัญหาวินัย – และต้นทุนการสลับบริบทของคิวนั้นสะสมในแบบที่เครื่องคำนวณการขัดจังหวะไม่สามารถจับได้
PR ขนาดเล็กจะไม่ช่วยคุณได้
คุณเคยได้ยินข้อนี้มาก่อน: PR ขนาดเล็กจะได้รับการรีวิวเร็วกว่า ดังนั้นให้ PR ของคุณเล็ก นั่นไม่ผิดทีเดียว แต่ขนาดผลกระทบ (จริงๆ) เล็กกว่าที่คุณคาดหวัง
การวิเคราะห์ PR กว่า 300,000 รายการของ Adadot พบ Kendall tau correlation เพียง 0.06 ระหว่างขนาด PR กับ lead time – ความสัมพันธ์ที่อ่อนแอ แม้ว่าการศึกษาไม่ได้รายงาน confidence interval สำหรับตัวเลขรวม PR ที่น้อยกว่า 100 บรรทัดมีความน่าจะเป็นประมาณ 80% ที่จะเสร็จสมบูรณ์ภายในหนึ่งสัปดาห์ ซึ่งฟังดูดีจนกว่าคุณจะรู้ว่านั่นคืออัตราการเสร็จสิ้นเดียวกับ PR ที่นั่งอยู่ในคิวรีวิวของใครบางคนเป็นเวลาหกวัน!
stat: "0.06" headline: "ความสัมพันธ์ระหว่างขนาด PR กับ lead time" source: "การวิเคราะห์ของ Adadot จาก PR กว่า 300,000 รายการจากนักพัฒนาประมาณ 30,000 คน (2023)"
ผลลัพธ์ที่น่าสนใจกว่า: ความสัมพันธ์นี้แปรผันอย่างมากระหว่างองค์กร ตั้งแต่ 0.1 ถึงเกือบ 0.7 ขึ้นอยู่กับบริษัท ซึ่งแนะนำว่าขนาด PR ไม่ใช่คอขวดโดยเนื้อแท้ – แต่เป็นวัฒนธรรมและกระบวนการรีวิวรอบๆ PR ทีมที่มีรูปแบบการรีวิวที่แข็งแกร่งสามารถจัดการ PR ขนาดใหญ่ได้อย่างมีประสิทธิภาพ ทีมที่มองการรีวิวเป็นเรื่องรองจะยากลำบากกับ PR ขนาดใดก็ตาม
เกณฑ์ 400 บรรทัดจากการศึกษาการรีวิวโค้ดของ SmartBear/Cisco ยังคงเป็นหลักการที่มีประโยชน์ – ข้อมูลของ Adadot ยังพบว่าการมีส่วนร่วมในการรีวิวลดลงเกินช่วงนั้น แต่การเพิ่มประสิทธิภาพสำหรับ PR ขนาดเล็กโดยไม่แก้ไขรูปแบบการรีวิวที่อยู่เบื้องหลัง คือ (และผมพูดสิ่งนี้ด้วยความรักอย่างแท้จริงสำหรับผู้จัดการวิศวกรรมทุกคนที่เคยพยายาม) การจัดเรียงเก้าอี้บนเรือที่กำลังจม
ทุกคนรีวิวทุกอย่างพร้อมกัน
การศึกษา multi-reviewing พบว่า 62% ของ pull request เกี่ยวข้องกับนักพัฒนาที่กำลังรีวิว PR หลายรายการพร้อมกัน สำคัญกว่านั้น พวกเขาพบความสัมพันธ์ที่มีนัยสำคัญทางสถิติ: การรีวิวพร้อมกันมากขึ้นต่อผู้รีวิวสัมพันธ์กับ latency การแก้ไข PR ที่ยาวนานขึ้น
62% ของ pull request เกี่ยวข้องกับนักพัฒนาที่กำลังรีวิว PR หลายรายการพร้อมกัน – และการ multi-reviewing สัมพันธ์โดยตรงกับเวลาแก้ไขที่ยาวนานขึ้น attribution: การศึกษา multi-reviewing pull-requests, PR 1.8 ล้านรายการใน 760 โปรเจกต์
กลไกนั้นสมเหตุสมผล (แม้ว่าการศึกษาซึ่งเป็นการสังเกตการณ์จะไม่ได้พิสูจน์ทิศทางของความเป็นเหตุเป็นผล) ผู้รีวิวหยิบ PR #1 อ่าน diff ผ่านๆ เริ่มสร้างโมเดลทางความคิดว่าโค้ดพยายามทำอะไร จากนั้นการแจ้งเตือนมาถึง – PR #2 ต้องการการรีวิวเพราะมันบล็อก deploy ผู้รีวิวสลับ เมื่อพวกเขากลับมาที่ PR #1 พวกเขาต้องอ่าน diff ใหม่ครึ่งหนึ่งเพราะโมเดลทางความคิดได้เสื่อมลง
ขยายเรื่องนี้ข้ามทีมวิศวกรแปดคน แต่ละคนมี PR เปิดอยู่สองหรือสาม แต่ละคนรีวิวให้เพื่อนร่วมงานสองหรือสาม และค่าใช้จ่ายในการประสานงานก็เริ่มอธิบายตัวเอง แยกต่างหาก 2024 DORA Report พบว่ากลุ่ม "high performer" ลดลงจาก 31% เป็น 22% ในขณะที่กลุ่ม low-performer เติบโตจาก 17% เป็น 25% DORA ไม่ได้แยก review concurrency ของ PR เป็นปัจจัย แต่ค่าใช้จ่ายในการประสานงานที่เพิ่มขึ้นเป็นผู้มีส่วนร่วมที่เป็นไปได้สำหรับการเปลี่ยนแปลงนั้น
สิ่งที่การประมาณการต้นทุนการสลับบริบทเข้าใจผิด
ขอให้ผมพูดตรงๆ เกี่ยวกับตัวเลข "$50K ต่อนักพัฒนาต่อปี" ที่หมุนเวียนอย่างกว้างขวางในบทความต้นทุนการสลับบริบท วิธีการเบื้องหลังการประมาณการเหล่านี้ส่วนใหญ่คือ: นำเวลาโฟกัสซ้ำ 23 นาที คูณกับจำนวนการขัดจังหวะรายวันที่ประมาณ (มักอยู่ที่ 6 ถึง 15 ขึ้นอยู่กับว่าผู้เขียนรู้สึกอยากแต่งเรื่องมากแค่ไหน) คูณกับอัตราค่าจ้างรายชั่วโมงของนักพัฒนา แล้วคำนวณเป็นรายปี
ปัญหาไม่ได้อยู่ที่ตัวเลขคณิตผิด ปัญหาคือมันปฏิบัติต่อการสลับบริบททั้งหมดเป็นเรื่องเดียวกัน การสลับจากการเขียนโค้ดลึกๆ ไปยังข้อความ Slack ที่ถามว่าทีมจะกินกลางวันที่ไหน – นั่นคือการสลับบริบท การสลับจากการรีวิว PR หนึ่งไปยังการรีวิว PR อื่นใน codebase ที่แตกต่างกันอย่างสิ้นเชิง – นั่นก็เป็นการสลับบริบทเช่นกัน แต่ต้นทุนทางปัญญานั้นไม่สามารถเปรียบได้เลย และการรวมพวกมันเป็นอัตรารายชั่วโมงเดียวบดบังว่าความเสียหายที่แท้จริงเกิดขึ้นที่ไหน
เพื่อให้เป็นรูปธรรม: ที่งานสุดท้ายของผม วันทั่วไปหมายถึงการสลับระหว่าง Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster และช่อง Telegram และ Signal มากมาย – และผมแน่ใจว่าผมลืมไปอีกครึ่งโหล ตอนนี้ผมใช้เพียงไม่กี่อย่าง (Signal, Obsidian, Figma, GitHub, อีเมล, ปฏิทิน) ต้นทุนต่อการสลับไม่ได้เปลี่ยน สิ่งที่เปลี่ยนคือจำนวนบริบทที่อยู่ในคิวรอความสนใจ – และว่าบริบทใดที่สำคัญจริงๆ
ข้อมูล PR ชี้ให้เห็นว่าการสลับที่แพงคือสิ่งที่สร้างคิว ไม่ใช่สิ่งที่ขัดจังหวะ flow นักพัฒนาที่ได้รับการ ping ให้รีวิว PR ทันที (ภายในไม่กี่นาที) และทำการรีวิว 50 บรรทัดอย่างรวดเร็ว – นั่นคือการขัดจังหวะสั้นๆ ที่ให้ผลตอบแทนสูง นักพัฒนาที่คิวคำขอรีวิวนั้นไว้พร้อมกับอีกสี่รายการและไปถึงมันพรุ่งนี้ – นั่นคือการขัดจังหวะที่ยาวนานกว่าสำหรับผู้รีวิวแต่สร้างต้นทุนที่ใหญ่กว่ามากสำหรับผู้เขียนและทีม
สิ่งที่เครื่องคำนวณต้นทุนวัด
- การขัดจังหวะของบุคคล – บ่อยแค่ไหนที่ flow ของคนๆ หนึ่งหยุดชะงัก
- เวลาโฟกัสซ้ำ – ใช้เวลาเท่าไรในการกลับไปทำงานก่อนหน้า
- การคูณอัตราค่าจ้างรายชั่วโมง – ตัวเลขรายปีที่น่ากลัว
สิ่งที่ข้อมูล PR แสดงให้เห็นจริงๆ
- การก่อตัวของคิว – PR รอการตอบสนองครั้งแรก
- Review concurrency – ผู้รีวิวที่จัดการ PR หลายรายการพร้อมกัน
- ความล่าช้าแบบต่อเนื่อง – การสลับบริบทของผู้เขียนที่สะสมกับความล่าช้าของผู้รีวิว
ความหมายสำหรับทีมของคุณ
หากคุณพยายามลดต้นทุนการสลับบริบทสำหรับนักพัฒนาในทีมของคุณ คำตอบในทางปฏิบัติน่าเบื่อ – ซึ่งน่าจะเป็นสาเหตุที่ไม่ค่อยมีใครเขียนถึง มันไม่ใช่เครื่องมือ มันไม่ใช่กรอบกระบวนการที่มีโปรแกรมรับรอง มันคือรูปแบบการรีวิว (ผมรู้ ผมรู้ ไม่มีใครได้รับการเลื่อนตำแหน่งจากการปรับปรุงรูปแบบการรีวิว)
engineering benchmarks ปี 2025 ของ LinearB ที่ดึงจาก PR 6.1 ล้านรายการใน 3,000 องค์กร พบว่าทีมที่บรรลุ cycle time ระดับ elite (น้อยกว่า 2.5 วัน) มีลักษณะร่วมหนึ่ง: พวกเขารีวิว PR อย่างรวดเร็ว ไม่ใช่เพราะพวกเขามี PR น้อยกว่า หรือเพราะ PR ของพวกเขาเล็กกว่า (แม้ว่ามักจะเป็นเช่นนั้น) แต่เพราะการตอบสนองต่อคำขอรีวิวภายในชั่วโมงเป็นบรรทัดฐานของทีม ไม่ใช่เรื่องรอง
สำหรับสิ่งที่คุ้มค่า Ben และผม – ทีมสองคน – เฉลี่ยนาทีในการตอบสนอง PR ครั้งแรก ไม่ใช่ชั่วโมง นั่นไม่ใช่การโอ้อวดเกี่ยวกับวินัย (เราไม่ได้ทำ) มันคือข้อตกลงทีม: คำขอรีวิวคือการแจ้งเตือนที่คุณไม่คิว CI actions และการทดสอบอัตโนมัติจัดการการตรวจสอบเชิงกล ซึ่งหมายความว่าการรีวิวโดยมนุษย์ – ส่วนที่ต้องการบริบทจริงๆ – สั้นกว่าและเกิดขึ้นทันที ข้อตกลงมาก่อน เครื่องมือเพียงทำให้มันยั่งยืน
ในทางปฏิบัติ นั่นหมายความว่า:
- วัด time-to-first-response ไม่ใช่แค่ cycle time หากคุณติดตาม DORA metrics ให้เพิ่มตัวนี้ มันคือตัวพยากรณ์เดี่ยวที่แข็งแกร่งที่สุดของ PR throughput (อธิบาย 58.7% ของความแปรผันในอายุขัย ตาม Zhang et al.)
- จำกัด review concurrency หากผู้รีวิวมีคำขอรีวิวที่รอดำเนินการสาม รายการที่สี่จะไม่ได้รับการรีวิวที่ดีอยู่ดี ข้อมูล multi-reviewing แสดงความสัมพันธ์ที่ชัดเจนระหว่าง concurrency และ latency เริ่มต้นด้วย WIP limit สองรีวิวพร้อมกันและติดตามผลกระทบ
- หยุดเพิ่มประสิทธิภาพขนาด PR โดยแยกส่วน PR ขนาดเล็กดี แต่ไม่ใช่ตัวแทนของทีมที่รีวิวสิ่งต่างๆ จริงๆ ทีมที่ผลิต PR 50 บรรทัดยี่สิบรายการต่อวันพร้อม review backlog 48 ชั่วโมงแย่กว่าทีมที่ผลิต PR 200 บรรทัดห้ารายการพร้อมการรีวิวในวันเดียวกัน
- ยอมรับว่าการรีวิวคืองานจริง การสำรวจปี 2024 ของ Atlassian พบว่า 69% ของนักพัฒนาสูญเสียเวลากว่า 8 ชั่วโมงต่อสัปดาห์จากความไม่มีประสิทธิภาพ การรีวิวไม่จำเป็นต้องเป็นหนึ่งในความไม่มีประสิทธิภาพเหล่านั้น – แต่ก็ต่อเมื่อถูกปฏิบัติเป็นกิจกรรมวิศวกรรมชั้นหนึ่ง ไม่ใช่การขัดจังหวะงาน "จริง"
และนี่คือส่วนที่ไม่มีใครในพื้นที่เครื่องมือผลิตภาพ (รวมถึงพวกเราด้วยเพื่อความเป็นธรรม) อยากพูดออกมาดังๆ: การแทรกแซงที่มีผลกระทบมากที่สุดสำหรับต้นทุนการสลับบริบทในทีมวิศวกรรมไม่ใช่เครื่องมือ มันคือข้อตกลงทีมเกี่ยวกับเมื่อ PR ได้รับการรีวิว หากบรรทัดฐานโดยนัยของทีมของคุณคือ "ผมจะไปรีวิวเมื่อมีช่องว่าง" ไม่มีเครื่องมือใดจะป้องกัน queuing cascade ที่ข้อมูล PR เปิดเผย
เครื่องมือช่วย – ความสามารถในการเห็นบริบทเต็มรูปแบบของ PR โดยไม่ต้องเปิดสี่แท็บเบราว์เซอร์ช่วยลดภาระทางปัญญาต่อการสลับ และการนำเสนอว่าการรีวิวใดที่กำลังบล็อกงานของคนอื่นช่วยจัดลำดับความสำคัญ แต่คันโยกหลักคือข้อตกลง และข้อตกลงนั้นฟรี ไม่ต้องการเครื่องคำนวณ 23 นาที
การสลับบริบทที่แพงที่สุดไม่ใช่การแจ้งเตือนที่ทำลายสมาธิของคุณ มันคือคำขอรีวิวที่นั่งอยู่ในคิวเป็นวัน บังคับให้ผู้เขียนต้องสร้างบริบททางความคิดใหม่เมื่อคำถามมาถึงในที่สุด
รับข่าวกรองสัญญาณส่งตรงถึงกล่องจดหมายของคุณ
คำถามที่พบบ่อย
Q: ต้นทุนการสลับบริบทต่อนักพัฒนาต่อปีเป็นเท่าไร A: การประมาณการมีความแตกต่างกัน แต่งานวิจัยเบื้องหลังนั้นมีน้ำหนักน้อยกว่าที่บทความส่วนใหญ่แนะนำ การศึกษาของ Gloria Mark แห่ง UC Irvine พบเวลาโฟกัสซ้ำ 23 นาทีต่อการขัดจังหวะหนึ่งครั้ง และการสำรวจปี 2024 ของ Atlassian จากนักพัฒนากว่า 2,100 คน พบว่า 69% สูญเสียเวลากว่า 8 ชั่วโมงต่อสัปดาห์จากความไม่มีประสิทธิภาพ ตัวเลขเงินดอลลาร์ขึ้นอยู่กับสมมติฐานเงินเดือน ความถี่ในการขัดจังหวะ และคำจำกัดความของ "การสลับ" ของคุณ – ซึ่งเป็นสาเหตุที่เราเน้นที่ข้อมูล PR แทน
Q: Sugarbug ช่วยลดการสลับบริบทสำหรับทีมวิศวกรรมได้หรือไม่ A: ใช่ Sugarbug เชื่อมต่อเครื่องมืออย่าง Linear, GitHub, Slack และ Figma เข้าสู่กราฟความรู้เดียว เพื่อให้วิศวกรเห็นบริบทเต็มรูปแบบของงาน – PR ที่เกี่ยวข้อง การสนทนา Slack คอมเมนต์ Figma – โดยไม่ต้องเปิดสี่แท็บ เป้าหมายคือการสลับน้อยลง ไม่ใช่เครื่องมือน้อยลง
Q: ขนาด pull request ที่เหมาะสมเพื่อลดความล่าช้าในการรีวิวคือเท่าไร A: งานวิจัยจากการวิเคราะห์ PR กว่า 300,000 รายการของ Adadot พบว่า PR ที่มีโค้ดน้อยกว่า 100 บรรทัด มีความน่าจะเป็นประมาณ 80% ที่จะเสร็จสมบูรณ์ภายในหนึ่งสัปดาห์ เมื่อเกิน 400 บรรทัด คุณภาพการรีวิวและความเร็วในการเสร็จสิ้นจะลดลงทั้งคู่ PR ขนาดเล็กยังช่วยลดภาระการสลับบริบทของผู้รีวิวด้วย
Q: Sugarbug เชื่อมต่อกับ GitHub pull requests ได้หรือไม่ A: ได้ Sugarbug ดึงข้อมูลกิจกรรม GitHub – PR, คอมเมนต์, การรีวิว และการเปลี่ยนแปลงสถานะ – และเชื่อมโยงกับสัญญาณที่เกี่ยวข้องในเครื่องมืออื่นๆ ของคุณ หาก Linear issue เป็นจุดกำเนิดของ PR และ Slack thread มีการถกเถียงถึงแนวทาง Sugarbug จะเชื่อมต่อทั้งสามโดยอัตโนมัติ
Q: สถิติ "23 นาทีในการโฟกัสซ้ำ" มาจากไหน A: มาจากงานวิจัยของ Gloria Mark แห่ง UC Irvine ที่ตีพิมพ์ใน "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008) การศึกษาพบว่าพนักงานใช้เวลาเฉลี่ย 23 นาที 15 วินาทีในการกลับไปทำงานเดิมหลังถูกขัดจังหวะ ควรสังเกตว่าการศึกษาสังเกตแรงงานความรู้ทั่วไป ไม่ใช่วิศวกรซอฟต์แวร์โดยเฉพาะ