मैं Yandex.Money में एक प्रमुख जावा डेवलपर हूं।

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

यह इस बात की कहानी है कि हमने कोड की समीक्षा कैसे तेज की, अग्रणी डेवलपर्स को उतार दिया और उन उपकरणों को बेहतर बनाया जो हम हर दिन उपयोग करते हैं।

कोड की समीक्षा 1.0। यह पहले कैसे था?

Yandex.Money में, एक कोड समीक्षा लंबे समय से एक अनिवार्य विकास चरण है, और हर कोई लंबे समय से इसका आदी हो चुका है। कुछ ने महसूस किया कि यह परीक्षण के रूप में सिर्फ एक चीज थी; दूसरों ने इसे एक आवश्यक बुराई माना, और किसी को कोड अनुरोध के रूप में केवल पुल अनुरोध के लेखक के रूप में आया, लेकिन किसी और के कोड की समीक्षा से बच गया। मुझे लगता है कि कई लोगों ने अंतिम से पहली यात्रा की है, और यह सामान्य है।

कोड की समीक्षा के लिए, हमने शुरुआत से ही बिटबकेट का उपयोग किया। प्रत्येक घटक रिपॉजिटरी के लिए, 3-4 डिफ़ॉल्ट समीक्षकों की एक सूची जोड़ी गई थी, जिन्हें सभी पीआरओं में जोड़ा गया था। आमतौर पर इस सूची को विभाग के प्रमुख द्वारा संकलित और संपादित किया गया था, और कभी-कभी स्वयं स्वयंसेवक जो किसी विशेष घटक की समीक्षा करना चाहते थे, उन्हें वहां जोड़ा गया था। लाइब्रेरी रिपॉजिटरी में यह थोड़ा आसान था - सभी पुस्तकालयों के लिए समीक्षकों की सूची समान थी, और वरिष्ठ डेवलपर्स को वहां शामिल किया गया था।

नतीजतन, लगभग पूरा बोझ वरिष्ठ डेवलपर्स के बीच समीक्षकों पर पड़ा, जो धीरे-धीरे पर्याप्त हो गए, 60 लोगों को विभाग की वृद्धि को ध्यान में रखते हुए, रिपॉजिटरी (60+ घटक, 100+ लाइब्रेरी) की संख्या में वृद्धि और हमारे सीआई / सीडी का त्वरण।

भारी कार्यभार और समीक्षकों के संसाधन की कमी के अलावा, अन्य समस्याएं थीं:

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

इन समस्याओं को हल करने से पहले, आपको यह तय करने की आवश्यकता है कि हम आम तौर पर एक कोड समीक्षा से क्या उम्मीद करते हैं।

सही कोड समीक्षा कैसे होती है?

हमने चार बिंदुओं की पहचान की है जिन्हें अद्यतन कोड समीक्षा में होना चाहिए:

1. समाधान आर्किटेक्चर को मान्य करें । बहुत स्पष्ट बात है। हम इस घटक में विशेषज्ञता वाले वरिष्ठ डेवलपर्स से इसकी उम्मीद करते हैं।
2. तकनीकी कार्यान्वयन का सत्यापन , जिसे हम इस घटक में विशेषज्ञता के साथ वरिष्ठ और मध्यम विशेषज्ञों से भी उम्मीद करते हैं।
3. ज्ञान का हस्तांतरण , जिसमें व्यावसायिक तर्क के अध्ययन और शुरुआती समीक्षाओं में और जून में कोड समीक्षाओं के माध्यम से कोड आधार शामिल हैं।
4. डेवलपर्स के कठिन कौशल का आकलन करने की क्षमता । मैं चाहता हूं कि प्रत्येक डेवलपर को एक संरक्षक सौंपा जाए जो विकास का मूल्यांकन करता है, विकास वेक्टर को निर्धारित करता है, कुछ कमियों को नोटिस करता है, टिप्पणियां करता है, और इसी तरह। इसलिए, संरक्षक को अपने वार्डों का कोड भी देखना चाहिए।

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

कोड समीक्षा 2.0। कैसा है?

हम क्या लेकर आए? हम कदम दर कदम तर्क करने लगे।

Yandex.Money में, डेवलपर्स व्यावसायिक क्षेत्रों में टीमों में काम करते हैं, आमतौर पर एक टीम में 2-4 बैकेंड डेवलपर्स होते हैं।

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

Yandex.Money में प्रत्येक घटक के पास एक टीम है जो उत्पादन पर इसके लिए जिम्मेदार है और इसके साथ है।

अगर मैं किसी ऐसे घटक को संशोधित करता हूं जिसके लिए एक और टीम जिम्मेदार है, तो इस टीम के डेवलपर्स को समीक्षकों से जोड़ना तर्कसंगत लगता है - वे इस घटक के लिए जिम्मेदार हैं और इसके कोड की गुणवत्ता की निगरानी करना चाहिए। लेकिन समीक्षकों को अधिभार नहीं देने के लिए, हम इस टीम से केवल एक यादृच्छिक व्यक्ति लेते हैं - हम मानते हैं कि यह पर्याप्त है।

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

2018 में, हमने कंपनी में मेंटरिंग इंस्टीट्यूट की शुरुआत की, इसलिए अब वरिष्ठ डेवलपर्स में से एक मेंटर प्रत्येक टीम को देख रहा है। इसके अलावा, कंपनी में प्रत्येक नवागंतुक के पास पहले से ही एक व्यक्तिगत संरक्षक है।

मेरे गुरु को मेरा कोड देखने दो! वह कोड समीक्षा पर समस्याओं के मामले में मदद करने में सक्षम होगा, और तकनीकी कौशल में मेरी ताकत और कमजोरियों का भी अंदाजा लगाएगा।

कुल में, प्रत्येक पुल अनुरोध के समीक्षकों में पांच से छह लोगों को जोड़ा जा सकता है। लेकिन वास्तव में, आमतौर पर वे थोड़े छोटे होते हैं, क्योंकि एक व्यक्ति में विभिन्न भूमिकाएं संयुक्त हो सकती हैं। मेरे संरक्षक एक ही समय में एक विशेषज्ञ हो सकते हैं, और मेरी टीम घटक के लिए जिम्मेदार हो सकती है। विशेष रूप से, 3-4 समीक्षक पुल अनुरोधों के लिए इष्टतम होंगे।

कोड समीक्षा 2.0। हुड के नीचे क्या है?

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

प्लगइन कैसे काम करता है

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

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

रिपोजिटरी विशेषज्ञ

मैं आपको कुछ और बताऊँगा कि हम विशेषज्ञों पर कैसे विचार करते हैं। हर दिन, प्लगइन सभी रिपॉजिटरी से गुजरता है, पिछले वर्ष के सभी पुल अनुरोधों को देखता है और दो सरल मैट्रिक्स पर विचार करता है:

• डेवलपर द्वारा बनाए गए अनुरोधों की संख्या,
• पीआरएस की संख्या जिसकी उन्होंने समीक्षा की और मंजूरी दी, काम या गिरावट की जरूरत थी।

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

इसके बाद, हम इन सभी डेवलपर्स को रेटिंग के आधार पर क्रमबद्ध करते हैं, शीर्ष 5 का चयन करते हैं, रास्ते में, उन लोगों को काटते हैं जिनकी रेटिंग आकस्मिक राहगीरों को काटने के लिए सीमा से नीचे है। और हम आम तौर पर प्रत्येक भंडार के लिए तीन से पांच विशेषज्ञों से प्राप्त करते हैं।

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

जीरा में टास्क चेक करने तक बैन मर्ज पुल रिक्वेस्ट

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

स्वचालित मर्ज पुल अनुरोध

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

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

और हमने इसे एक सुविधाजनक तरीके से लागू किया: हमने एक विशेष ऑटोमार्बॉट बॉट शुरू किया, जिसे हमें बस समीक्षकों को जोड़ने की जरूरत है, ताकि यह इस पुल अनुरोध की निगरानी शुरू कर सके और समय आने पर इसे फ्रीज कर सके।

समीक्षकों की अनुपस्थिति के लिए लेखांकन

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

समीक्षकों के रोजगार के लिए लेखांकन

कोई दिन में दस पीआर की समीक्षा करता है, और कोई पांच। किसी ने पहले से ही 20 अनअप्रूव्ड पीआर जमा कर लिए हैं, जबकि किसी के पास लगभग कोई नहीं है। हम समीक्षकों पर लोड को अधिक समान रूप से वितरित करने के लिए यह सब ध्यान में रखते हैं। जितना अधिक लोड, उतना कम नए पीआर में जोड़ा जाता है - सब कुछ सरल है।

बनाते समय PR आकार चिह्नित करना

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

भविष्य में, हम पीआर सांख्यिकी की गणना करते समय इन विशेषताओं को ध्यान में रखना चाहते हैं।

लेबलिंग तत्काल पीआर

पीआर बनाते समय, लेखक यह संकेत दे सकता है कि पीआर नाम के लिए इस तरह के प्रतीक को जोड़कर कार्य बहुत जरूरी है। यह समीक्षकों द्वारा तुरंत देखा जाएगा और पहले देखने का प्रयास करेगा। यह एक तिपहिया लगता है, लेकिन बहुत उपयोगी और सुविधाजनक है।

ट्रैकिंग शुरू और अंत कोड समीक्षा

यदि प्रक्रिया में सुधार करते समय यह समझना असंभव है कि इसमें कितना सुधार हुआ है, तो शुरू करने का कोई मतलब नहीं है।

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

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

यहां सबसे पतला बिंदु यह है कि कोड समीक्षा को समाप्त करने के लिए कैसे निर्धारित किया जाए? शायद यह पहला ऐप प्राप्त करने का समय है, शायद आखिरी, या शायद पीआर के लेखक द्वारा किए गए अंतिम परिवर्तनों का समय है? मेरे पास इस सवाल का जवाब नहीं है, यहां मुझे सिर्फ एक दूसरे से सहमत होने और एक चीज चुनने या तीनों घटनाओं को मेट्रिक्स से कवर करने और विचलन का पालन करने की आवश्यकता है।

समीक्षकों के ट्रैकिंग डाउनलोड

एक और उपयोगी मीट्रिक समीक्षकों का कार्यभार है। जैसा कि मैंने ऊपर लिखा था, हम नए पीआर के समीक्षकों को असाइन करते समय इसे ध्यान में रखते हैं, लेकिन हम टीमों, विभागों या कंपनियों की गतिशीलता की निगरानी के लिए इस जानकारी को भी प्रकाशित करते हैं। कभी-कभी यह विसंगतियों और संभावित समस्याओं का पता लगाने में मदद करता है: यदि यह स्पष्ट है कि एक टीम में एक या अधिक लोग हर दिन 10 या उससे अधिक अनपेक्षित पीआर लटकाते हैं, तो यह पता लगाने का एक कारण है कि क्या सब कुछ क्रम में है।

ग्राफाना में मेट्रिक्स देखें

जीरा के डेटा पर बिल्डिंग रिपोर्ट उपयोगी है, लेकिन बहुत सुविधाजनक नहीं है, इसलिए हमने ग्राफ्टाना में परिचालन डेटा पर ग्राफ़ बनाने के लिए स्टैट्सड में मुख्य घटनाओं के लिए मीट्रिक भेजना भी जोड़ा। हम पहले परीक्षण तक औसत समय की निगरानी करते हैं, पीआर का औसत जीवन समय, और समस्याओं को जल्दी से खोजने और हल करने के लिए इन मैट्रिक्स के लिए विषम मूल्यों को भी देखते हैं।

लेखन के समय, हमारा डैशबोर्ड इस तरह दिखता है:

आखिर में आपको क्या मिला?

दुर्भाग्य से, हम सभी हिंड्सट में मजबूत हैं, इसलिए हमने ऊपर बताई गई कोड समीक्षा मैट्रिक्स की शुरुआत नहीं की, प्रक्रिया से पहले ही (सितंबर-अक्टूबर 2018) बदलना शुरू हो गया था, लेकिन पहले से ही रास्ते में है, इसलिए हम केवल दिसंबर 2018 की शुरुआत से ही सुधार या गिरावट को ट्रैक कर सकते हैं। हमने क्या नोटिस किया?

पहली चीज जो आपकी आंख को पकड़ती है वह है वरिष्ठ समीक्षकों पर भार में कमी, और मैंने इसे अपने उदाहरण से महसूस किया। जैसा कि मैंने पहले ही उल्लेख किया है, मेरे लिए सुबह के समय लगभग ३० पीआर देखना सामान्य था, लेकिन अब यह संख्या १० से १५ के बीच में उतार-चढ़ाव है। विभाग के आंकड़े इसकी पुष्टि करते हैं: दिसंबर २०१ it से, समीक्षा के लिए इंतजार कर रहे पीआरओ की अधिकतम संख्या किसी के द्वारा नहीं बढ़ाई गई है। उपरोक्त 15. औसतन, हम एक ऐसी तस्वीर देखते हैं जो बताती है कि औसतन प्रत्येक डेवलपर को सुबह 4-5 अनौपचारिक पीआर की उम्मीद है, जो कि काफी पर्याप्त संख्या है।

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

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