2.9 पुल रिक्वेस्ट और कोड समीक्षा मेट्रिक्स

अवलोकन और प्रेरणा

कोड समीक्षा आमतौर पर विषय 2.6 के साइकल-टाइम विघटन के भीतर एकल सबसे बड़ा प्रतीक्षा-समय योगदानकर्ता है, और यह वह चरण भी है जो एक साझा प्लेटफ़ॉर्म बॉटलनेक या एक बाहरी निर्भरता के विपरीत, सुधार के लिए सबसे सीधे एक टीम के अपने नियंत्रण में है। यह विषय उन विशिष्ट मेट्रिक्स को कवर करता है जो समीक्षा चरण के भीतर रहते हैं: पहली समीक्षा तक का समय, पुल रिक्वेस्ट आकार, समीक्षा पुनरावृत्ति गिनती, और समीक्षक लोड वितरण, और उन वास्तविक गुणवत्ता लाभ का त्याग किए बिना समीक्षा गति सुधारने के लिए उनका उपयोग कैसे करें जो समीक्षा को प्रदान करना माना जाता है।

यह विषय जिस जोखिम के प्रति सबसे अधिक सचेत है वह एक ऐसा है जिसे इस पुस्तक ने अभी तक सीधे कवर नहीं किया है: समीक्षा गति का अनुकूलन करना, लापरवाही से किया जाए तो, चुपचाप समीक्षा गुणवत्ता को क्षरित कर सकता है। एक टीम जो हर चीज़ को एक रबर स्टैंप के साथ स्वीकृत करके अपने पहली-समीक्षा-तक-समय को आधा कर देती है उसने एक मेट्रिक सुधारा है जबकि प्रथा के वास्तविक मूल्य को नष्ट कर दिया है। इस विषय की हर सिफ़ारिश इस समझौते को ध्यान में रखते हुए लिखी गई है, क्योंकि पुल रिक्वेस्ट मेट्रिक्स इस पुस्तक में उन सबसे आसान मेट्रिक्स में से हैं जिनके साथ ऐसे तरीक़े से चालाकी की जा सकती है जो एक डैशबोर्ड पर अच्छा दिखता है जबकि अंतर्निहित कोडबेस को मापने योग्य रूप से बदतर बनाता है।

बड़ी टीमों के लिए, समीक्षा मेट्रिक्स लोड-संतुलन समस्याओं को उजागर करते हैं जो अन्यथा अदृश्य होती हैं: वरिष्ठ इंजीनियरों की एक छोटी संख्या समीक्षा लोड का एक असंगत हिस्सा अवशोषित करती है, एक विशिष्ट टीम या कोडबेस क्षेत्र जहाँ समीक्षाएँ लगातार अटक जाती हैं, या अत्यधिक बड़े पुल रिक्वेस्टों का एक पैटर्न जो समीक्षक परिश्रम की परवाह किए बिना गहन समीक्षा को व्यावहारिक रूप से असंभव बना देता है। ये पैटर्न बड़े पैमाने पर एक छोटी टीम की तुलना में कहीं अधिक संयोजित होते हैं, जहाँ हर कोई इसे उजागर करने के लिए किसी मेट्रिक की आवश्यकता के बिना सीधे असंतुलन देख सकता है।

प्रमुख सिद्धांत

पहली समीक्षा तक का समय आमतौर पर सबसे बड़ा लीवर है, समीक्षा गहनता स्वयं नहीं। अधिकांश देरी एक पुल रिक्वेस्ट के देखे जाने की प्रतीक्षा से आती है, समीक्षा वार्तालाप के शुरू होने के बाद लंबा समय लेने से नहीं।
छोटे पुल रिक्वेस्टों की तेज़ी से और अधिक गहनता से समीक्षा होती है, केवल तेज़ी से नहीं। आकार गति और गुणवत्ता दोनों के लिए एक साथ एक लीवरेज बिंदु है।
समीक्षा गति और समीक्षा गुणवत्ता स्वचालित रूप से तनाव में नहीं हैं, लेकिन उन्हें लापरवाही से समझौता किया जा सकता है। उस व्यापार के विरुद्ध स्पष्ट रूप से रक्षा करें।
समीक्षक लोड असंतुलन सामान्य है और आमतौर पर एक मेट्रिक के बिना अदृश्य है। लोगों की एक छोटी संख्या अक्सर एक असंगत हिस्सा अवशोषित करती है।
ये मेट्रिक्स रबर-स्टैंप चालाकी जोखिम के प्रति उजागर हैं। बिना किसी वास्तविक जाँच के एक तेज़ स्वीकृति समीक्षा के पूरे उद्देश्य को विफल कर देती है।

सिफ़ारिशें

पहली समीक्षा तक का समय प्राथमिक गति मेट्रिक के रूप में ट्रैक करें

एक पुल रिक्वेस्ट के खुलने से लेकर एक समीक्षक की पहली सारगर्भित टिप्पणी या स्वीकृति तक के अंतराल को मापें, अपने वर्ज़न कंट्रोल प्लेटफ़ॉर्म से स्वचालित रूप से इंस्ट्रूमेंट किया गया। यह आमतौर पर समीक्षा चरण (विषय 2.5, विषय 2.6) के भीतर प्रमुख प्रतीक्षा-समय योगदानकर्ता है, और इसे सुधारना, स्पष्ट समीक्षा-नियुक्ति मानदंडों, सूचना प्रथाओं, या समर्पित समीक्षा समय ब्लॉकों के माध्यम से, आमतौर पर एक टीम के लिए उपलब्ध समग्र साइकल टाइम में एकल सबसे बड़ा सुधार उत्पन्न करता है।

पुल रिक्वेस्ट आकार को ट्रैक करें और सक्रिय रूप से छोटे परिवर्तनों को प्रोत्साहित करें

प्रति पुल रिक्वेस्ट बदली गई पंक्तियों या छुई गई फ़ाइलों को मापें, और एक लगातार बड़े माध्यिका आकार को सीधे संबोधित करने लायक़ एक संकेत मानें। छोटे पुल रिक्वेस्टों की तेज़ी से समीक्षा होती है, अधिक गहनता से समीक्षा होती है (एक समीक्षक वास्तव में पूरे परिवर्तन को अपने दिमाग़ में रख सकता है), और यदि कुछ ग़लत होता है तो इन्हें वापस लौटाना आसान होता है, जो विषय 2.10 में डिप्लॉयमेंट फ़्रीक्वेंसी के पीछे के बैच-आकार सिद्धांत से सीधे जुड़ता है। जहाँ भी काम इसकी अनुमति देता है वहाँ बड़े परिवर्तनों को छोटे, स्वतंत्र रूप से समीक्षा योग्य पुल रिक्वेस्टों के एक अनुक्रम में विभाजित करने को प्रोत्साहित करें।

समीक्षक लोड वितरण की स्पष्ट रूप से निगरानी करें

एक चलती हुई विंडो में प्रति व्यक्ति पूर्ण की गई समीक्षाओं की संख्या को ट्रैक करें, और विशेष रूप से लोगों की एक छोटी संख्या द्वारा एक असंगत हिस्सा अवशोषित करने के लिए देखें। यह पैटर्न सामान्य है, अक्सर सबसे वरिष्ठ या सबसे विश्वसनीय इंजीनियरों पर पड़ता है, और एक बॉटलनेक (उनकी उपलब्धता पूरी टीम के समीक्षा थ्रूपुट को सीमित करती है) और एक बर्नआउट जोखिम (विषय 3.2 भलाई मेट्रिक्स को अधिक गहराई से कवर करता है) दोनों बनाता है। जो भी सबसे तेज़ जवाब देता है उसके आसपास डिफ़ॉल्ट रूप से इसे केंद्रित होने देने की बजाय जान-बूझकर समीक्षा ज़िम्मेदारी को घुमाएँ।

रबर-स्टैंप चालाकी जोखिम के विरुद्ध स्पष्ट रूप से रक्षा करें

पहली-समीक्षा-तक-समय को एक गुणवत्ता संकेत के साथ जोड़ें: शून्य समीक्षा टिप्पणियों के साथ स्वीकृत किए गए परिवर्तनों में वापस ट्रेस किए गए दोषों या घटनाओं की दर, या हाल ही में समीक्षा किए गए कोड के लिए आवश्यक मर्ज-पश्चात सुधारों की दर। एक टीम जो बिना वास्तविक जाँच के स्वीकृत करके समीक्षा गति में सुधार करती है उसे यह गार्डरेल क्षरित होते देखना चाहिए, जो ठीक विषय 1.2 का युग्मन सिद्धांत है जो इस विशिष्ट मेट्रिक परिवार पर लागू होता है। इस काउंटर-मेट्रिक को दृष्टि में रखे बिना कभी समीक्षा गति का पीछा न करें।

व्यक्तियों को आँकने के लिए नहीं, घर्षण को पहचानने के लिए समीक्षा पुनरावृत्ति गिनती का उपयोग करें

मर्ज होने से पहले एक पुल रिक्वेस्ट जितने समीक्षा दौरों से गुज़रता है वह संख्या वास्तविक घर्षण, अस्पष्ट आवश्यकताएँ, दृष्टिकोण के बारे में असहमति, असंगत शैली अपेक्षाएँ, का संकेत दे सकती है, जिसे प्रक्रिया स्तर पर जाँचना लायक़ है। इस संख्या का उपयोग व्यक्तिगत लेखकों या समीक्षकों को सीधे आँकने के लिए करने से बचें; एक उच्च पुनरावृत्ति गिनती अक्सर एक व्यक्तिगत की बजाय एक प्रणाली या संचार संकेत होती है, और इसे एक व्यक्तिगत स्कोरकार्ड मानना ठीक उसी मूल्यांकनात्मक बहाव का जोखिम रखता है जिसके विरुद्ध विषय 1.1 चेतावनी देता है।

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
केवल पहली समीक्षा तक समय के लिए अनुकूलन	तेज़, स्पष्ट संकेत, इंस्ट्रूमेंट करना आसान	अगर बिना गार्ड के छोड़ा जाए तो सतही, रबर-स्टैंप समीक्षा को प्रोत्साहित कर सकता है
केवल पुल रिक्वेस्ट आकार कमी के लिए अनुकूलन	गति और गहनता दोनों को एक साथ सुधारता है	सभी काम छोटे वृद्धिशील भागों में साफ़-साफ़ विभाजित नहीं होते
समीक्षा लोड को समान रूप से घुमाना	बॉटलनेक और बर्नआउट जोखिम को घटाता है	विशिष्ट विशेषज्ञता की आवश्यकता वाले विशेष, समीक्षा-में-कठिन कोड के लिए समीक्षा को धीमा कर सकता है
वरिष्ठ इंजीनियरों के बीच समीक्षा को केंद्रित करना	गहन डोमेन विशेषज्ञता लगातार लागू होती है	समय के साथ एक बॉटलनेक और एक बर्नआउट जोखिम बनाता है

केंद्रीय तनाव है गति बनाम जाँच की गहराई। समीक्षा को तेज़ करने के लिए इस विषय की हर तकनीक, तेज़ पहली प्रतिक्रिया, छोटे पुल रिक्वेस्ट, अधिक वितरित समीक्षक लोड, यदि इस विषय द्वारा सुझाए गए गुणवत्ता गार्डरेल के बिना पीछा किया जाए तो वास्तविक जाँच को दूर व्यापार करने का कुछ जोखिम रखती है। तनाव को हर गति मेट्रिक को एक गुणवत्ता संकेत के साथ जोड़कर हल करें, उसी अवधि में ट्रैक किया गया, ताकि एक टीम वास्तविक प्रक्रिया सुधार को चुपचाप क्षरित होते समीक्षा मानक से बता सके।

अपनी टीम के साथ चर्चा करने के प्रश्न

हमारी वास्तविक पहली समीक्षा तक का समय क्या है, और हमारे समग्र साइकल टाइम का कितना हिस्सा समीक्षा चरण उपभोग करता है? धारणा पर निर्भर रहने की बजाय वास्तविक संख्या खींचें; समीक्षा प्रतीक्षा समय अक्सर टीमों के मानने से बड़ा होता है, ठीक इसलिए क्योंकि सक्रिय रूप से काम करने की बजाय प्रतीक्षा में बिताए गए समय को कम आँकना आसान है।
हमारा माध्यिका पुल रिक्वेस्ट आकार क्या है, और यदि वह आकार कम हो जाए तो हमारी समीक्षा देरी का कितना हिस्सा सिकुड़ेगा? बड़े पुल रिक्वेस्ट दोनों समीक्षा करने में धीमे और सतही समीक्षा प्राप्त करने की अधिक संभावना रखते हैं बस इसलिए क्योंकि एक समीक्षक पूरी चीज़ को एक साथ अपने दिमाग़ में नहीं रख सकता। केवल माध्यिका नहीं, अपने वास्तविक आकार वितरण को देखें।
क्या समीक्षा लोड लोगों की एक छोटी संख्या पर केंद्रित है, और यदि उनमें से एक दो सप्ताह के लिए अनुपलब्ध हो तो हमारे समीक्षा थ्रूपुट का क्या होगा? यह प्रश्न एक साथ एक बॉटलनेक जोखिम और एक बर्नआउट जोखिम दोनों को उजागर करता है। धारणा पर निर्भर रहने की बजाय वास्तविक समीक्षक-लोड डेटा खींचें।
क्या हमने कभी एक समीक्षा-गति मेट्रिक को इस तरह सुधारा है जिसने, विचार करने पर, वास्तविक जाँच को कम किया? यहाँ ईमानदार रहें; यह ठीक वही रबर-स्टैंप जोखिम है जिसे यह विषय नाम देता है, और बिना ऐसा करने के किसी जान-बूझकर निर्णय के इसमें फिसलना आसान है।
हमारी टीम में एक उच्च समीक्षा पुनरावृत्ति गिनती आमतौर पर क्या संकेत देती है: वास्तविक असहमति, अस्पष्ट आवश्यकताएँ, या असंगत शैली अपेक्षाएँ? असामान्य रूप से उच्च पुनरावृत्ति गिनती वाले पुल रिक्वेस्टों के एक नमूने को देखें और वास्तविक पैटर्न का निदान करें, यह मानने की बजाय कि यह लेखक या समीक्षक में से किसी पर बुरी तरह प्रतिबिंबित होता है।
क्या हमारे पास अपने समीक्षा-गति मेट्रिक्स के साथ जोड़ा गया एक गुणवत्ता गार्डरेल है, या हम अलगाव में गति ट्रैक कर रहे हैं? यदि ईमानदार उत्तर है कि ऐसा कोई गार्डरेल मौजूद नहीं है, तो वह विषय 1.2 के युग्मन सिद्धांत के अनुसार समीक्षा गति को और आगे धकेलने से पहले बंद करने लायक़ एक अंतर है।

क्षेत्र दृष्टिकोण

स्टार्टअप। एक छोटी टीम के साथ समीक्षा अक्सर डिफ़ॉल्ट रूप से तेज़ होती है, कभी-कभी लगभग बहुत ही तेज़, न्यूनतम जाँच के साथ एकल-स्वीकृतिकर्ता समीक्षा क्योंकि हर कोई हर किसी पर भरोसा करता है। टीम बढ़ने के साथ जिस जोखिम पर नज़र रखनी है वह है समीक्षा गुणवत्ता का टीम आकार के साथ न बढ़ना, क्योंकि अनौपचारिक विश्वास जो पाँच इंजीनियरों के लिए काम करता था वह स्वचालित रूप से पचास के लिए काम नहीं करता।

छोटा व्यवसाय। अधिकांश वर्ज़न-कंट्रोल प्लेटफ़ॉर्म बॉक्स से बाहर समय-से-मर्ज और समीक्षा-गिनती आँकड़े रिपोर्ट करते हैं; कस्टम इंस्ट्रूमेंटेशन बनाने की बजाय इनका उपयोग करें। अपनाने लायक़ मुख्य अनुशासन बस यह देखना है कि क्या टीम के बढ़ने के साथ समीक्षा लोड चुपचाप एक या दो लोगों पर केंद्रित हो गया है।

एंटरप्राइज़। यहाँ समीक्षक लोड असंतुलन और विशेष-ज्ञान बॉटलनेक विशेष रूप से सामान्य हैं, जहाँ एक महत्वपूर्ण प्रणाली में गहन डोमेन विशेषज्ञता टीम आकार की परवाह किए बिना समीक्षा ज़िम्मेदारी को एक छोटे समूह में केंद्रित कर सकती है। विशेषज्ञता को फैलाने के लिए जान-बूझकर ज्ञान-साझाकरण और समीक्षा रोटेशन में निवेश करें, बॉटलनेक और उस विशेषज्ञता के बहुत कम लोगों में रहने के बस-फ़ैक्टर जोखिम दोनों को कम करते हुए।

सरकार। यहाँ समीक्षा प्रक्रियाएँ अक्सर गुणवत्ता लक्ष्यों के साथ-साथ अनुपालन भार भी वहन करती हैं, जो डिज़ाइन द्वारा पुल रिक्वेस्टों को बड़ा और समीक्षाओं को धीमा बना सकती हैं। जहाँ वास्तविक अनुपालन आवश्यकताएँ गहन समीक्षा की माँग करती हैं, वहाँ समीक्षा की वास्तविक गहराई से समझौता करने की बजाय प्रतीक्षा समय को कम करने (तेज़ समीक्षा नियुक्ति, स्पष्ट ट्राएज) पर सुधार प्रयास केंद्रित करें, और यदि नियामक कारणों से जाँच भारी रहनी चाहिए तो समझौते को स्पष्ट रूप से दस्तावेज़ीकृत करें।

उदाहरण

एंटरप्राइज़। एक साइबर सुरक्षा कंपनी के इंजीनियरिंग संगठन ने पाया कि मुट्ठी भर प्रिंसिपल इंजीनियर दो सौ लोगों के संगठन में सभी कोड समीक्षाओं का 40% से अधिक पूरा कर रहे थे, एक असंतुलन जिसे किसी ने तब तक सीधे नहीं मापा था जब तक समीक्षक-लोड डेटा नहीं खींचा गया। यह एकाग्रता दोनों एक बॉटलनेक थी, क्योंकि उन इंजीनियरों की उपलब्धता पूरे संगठन के लिए समीक्षा थ्रूपुट सीमित करती थी, और एक बर्नआउट जोखिम जो एक एंगेजमेंट सर्वेक्षण (विषय 3.2) द्वारा अलग से चिह्नित की गई। संगठन ने लक्षित ज्ञान-साझाकरण सत्रों के साथ जोड़ा गया एक संरचित समीक्षा-रोटेशन कार्यक्रम पेश किया, और दो चौथाइयों के भीतर समीक्षा लोड बहुत व्यापक समूह में फैल गया, कम हुए बॉटलनेक के प्रत्यक्ष दुष्प्रभाव के रूप में पहली समीक्षा तक का समय सुधरते हुए।

सरकार। एक कर प्राधिकरण की इंजीनियरिंग टीम, डिलीवरी गति सुधारने के दबाव में, पहली समीक्षा तक के समय को आधा करने का लक्ष्य निर्धारित किया। एक चौथाई के भीतर, लक्ष्य पूरा हुआ, लेकिन एक बाद की गुणवत्ता ऑडिट ने मर्ज-पश्चात दोष-फिक्स पुल रिक्वेस्टों में तेज़ वृद्धि पाई, उन परिवर्तनों में केंद्रित जिन्हें एक एकल, संक्षिप्त टिप्पणी के साथ स्वीकृत किया गया था। टीम के समाधान ने गति लक्ष्य को एक स्पष्ट गुणवत्ता गार्डरेल के साथ जोड़ा, एक समीक्षा के दो सप्ताह के भीतर आवश्यक मर्ज-पश्चात सुधारों की दर, और टीम को इस बात पर फिर से प्रशिक्षित किया कि एक सारगर्भित समीक्षा को वास्तव में क्या आवश्यकता होती है, बेहतर समीक्षा नियुक्ति और छोटे पुल रिक्वेस्ट आकारों से आए गति सुधार के अधिकांश हिस्से को बनाए रखते हुए वास्तविक जाँच को बहाल किया।

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

अच्छी तरह प्रबंधित समीक्षा मेट्रिक्स का प्रतिफल गुणवत्ता का त्याग किए बिना तेज़ डिलीवरी है, जो एक दुर्लभ संयोजन है: अधिकांश डिलीवरी सुधार कहीं न कहीं गति को जोखिम के विरुद्ध व्यापार करते हैं, लेकिन समीक्षा-चरण सुधार, छोटे पुल रिक्वेस्ट, बेहतर लोड वितरण, तेज़ पहली-प्रतिक्रिया, इस विषय द्वारा सुझाए गए गुणवत्ता गार्डरेल के साथ किए जाने पर वास्तव में दोनों को एक साथ सुधारते हैं। ऊपर का साइबर सुरक्षा उदाहरण विशिष्ट है: एक बॉटलनेक को ठीक करना गति को सुधारता है जबकि अंतर्निहित समीक्षा गुणवत्ता, यदि कुछ भी, विशेषज्ञता के अधिक व्यापक रूप से फैलने के साथ सुधरी।

कुल स्वामित्व लागत कम है: इनमें से अधिकांश मेट्रिक्स न्यूनतम अतिरिक्त इंस्ट्रूमेंटेशन के साथ सीधे मौजूदा वर्ज़न-कंट्रोल प्लेटफ़ॉर्म डेटा से आते हैं, और जिन प्रक्रिया परिवर्तनों की ओर वे इशारा करते हैं, समीक्षा रोटेशन, छोटे पुल रिक्वेस्टों को प्रोत्साहित करना, अधिकांशतः अनुशासन की लागत लेते हैं, टूलिंग निवेश की नहीं।

विरोधी-पैटर्न और नुक़सान

बिना जोड़े गए गुणवत्ता गार्डरेल के पहली समीक्षा तक का समय अनुकूलित करना: रबर-स्टैंप स्वीकृति को आमंत्रित करता है जो समीक्षा के उद्देश्य को विफल कर देता है।
समीक्षक लोड एकाग्रता को नज़रअंदाज़ करना: एक बॉटलनेक और एक बर्नआउट जोखिम दोनों बनाता है जो मापे जाने तक अदृश्य रहता है।
समीक्षा पुनरावृत्ति गिनती को एक व्यक्तिगत स्कोरकार्ड मानना: अक्सर एक व्यक्तिगत की बजाय एक प्रणाली या संचार संकेत।
लगातार बड़े पुल रिक्वेस्टों को अपरिहार्य मानना: अधिकांश बड़े परिवर्तनों को टीमों के शुरू में मानने से आगे विभाजित किया जा सकता है।
परिवर्तन जोखिम की परवाह किए बिना समान समीक्षा गहराई लागू करना: कम-जोखिम परिवर्तनों पर जाँच बर्बाद करता है जबकि संभावित रूप से उच्च-जोखिम वालों की कम जाँच करता है।
समीक्षा गति मापना लेकिन कभी यह न जाँचना कि क्या इसके साथ वास्तविक जाँच में गिरावट आई: इस मेट्रिक परिवार के साथ अनजाने में चालाकी होने का सबसे सामान्य तरीक़ा।

परिपक्वता मॉडल

स्तर 1, आरंभ: समीक्षा मेट्रिक्स ट्रैक नहीं की जातीं; समीक्षा लोड वितरण और पुल रिक्वेस्ट आकार अदृश्य हैं।
स्तर 2, विकास: प्लेटफ़ॉर्म डिफ़ॉल्ट से कुछ समीक्षा-गति डेटा मौजूद है, लेकिन कोई गुणवत्ता गार्डरेल नहीं है और समीक्षक लोड का कोई सक्रिय प्रबंधन नहीं है।
स्तर 3, मानकीकरण: पहली समीक्षा तक का समय, पुल रिक्वेस्ट आकार, और समीक्षक लोड को लगातार ट्रैक किया जाता है, गति सुधारों के विरुद्ध जोड़े गए एक स्पष्ट गुणवत्ता गार्डरेल के साथ।
स्तर 4, प्रबंधन: समीक्षक लोड को रोटेशन और ज्ञान साझाकरण के माध्यम से सक्रिय रूप से पुनर्संतुलित किया जाता है; पुनरावृत्ति-गिनती पैटर्न को व्यक्तिगत स्तर की बजाय प्रक्रिया स्तर पर जाँचा जाता है।
स्तर 5, संयोजन: समीक्षा-चरण मेट्रिक्स सीधे प्रक्रिया निवेश को सूचित करते हैं, और संगठन एक निरंतर अवधि में समीक्षा गति और समीक्षा-संबद्ध गुणवत्ता परिणामों दोनों में एक साथ सुधार प्रदर्शित कर सकता है।

चर्चा के लिए विचार

हमारी वर्तमान माध्यिका पहली समीक्षा तक का समय क्या है, और वह समय वास्तव में कहाँ जाता है?
क्या हमारा समीक्षा लोड लोगों की एक छोटी संख्या पर केंद्रित है, और यदि उनमें से एक अनुपलब्ध हो तो क्या जोखिम है?
क्या हमने कभी वास्तविक जाँच की क़ीमत पर समीक्षा गति सुधारी है, यहाँ तक कि अनजाने में भी?
हमारा माध्यिका पुल रिक्वेस्ट आकार क्या है, और अधिकांश परिवर्तन वास्तविक रूप से कितने छोटे हो सकते हैं?
क्या हम एक उच्च समीक्षा पुनरावृत्ति गिनती को एक प्रणाली संकेत या एक व्यक्तिगत निर्णय मानते हैं?

मुख्य निष्कर्ष

पहली समीक्षा तक का समय आमतौर पर समीक्षा चरण के भीतर एकल सबसे बड़ा लीवर है, समीक्षा वार्तालाप की लंबाई स्वयं से अधिक।
छोटे पुल रिक्वेस्ट समीक्षा गति और समीक्षा गहनता दोनों को एक साथ सुधारते हैं।
समीक्षक लोड असंतुलन सामान्य है और आमतौर पर प्रत्यक्ष माप के बिना अदृश्य है; यह एक बॉटलनेक और एक बर्नआउट जोखिम दोनों बनाता है।
इस मेट्रिक परिवार के विशेष रूप से प्रवण रबर-स्टैंप चालाकी जोखिम को पकड़ने के लिए हर समीक्षा-गति मेट्रिक को एक स्पष्ट गुणवत्ता गार्डरेल के साथ जोड़ें।
व्यक्तिगत लेखकों या समीक्षकों को आँकने के लिए नहीं, प्रणाली-स्तरीय घर्षण का निदान करने के लिए समीक्षा पुनरावृत्ति गिनती का उपयोग करें।

संदर्भ और आगे पढ़ने के लिए

Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (कोड समीक्षा प्रथाएँ और डिलीवरी प्रदर्शन से उनका संबंध)।
Modern Code Review research by Alberto Bacchelli and Christian Bird (पैमाने पर कोड समीक्षा प्रथाओं का अनुभवजन्य अध्ययन)।
Peer Reviews in Software: A Practical Guide, by Karl E. Wiegers (समीक्षा प्रक्रिया डिज़ाइन और इसके समझौते)।
The Principles of Product Development Flow, by Donald G. Reinertsen (पुल रिक्वेस्ट आकार-निर्धारण पर लागू बैच-आकार तर्क)।