कोड समीक्षा को दो सप्ताह से कई घंटों तक कैसे कम करें। Yandex.Market टीम का अनुभव

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

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

पहले आपको यह कल्पना करने की आवश्यकता है कि विकास में किस तरह का प्रवाह हमने अपनाया है:

एक ही बात, केवल बिंदु से और शब्दों में:

1. डेवलपर कार्य लेता है।
2. उसे बनाता है।
3. Github पर भरता है और PR को खोलता है।
4. एक कोड समीक्षा पास करता है।
5. एक डेमो स्टैंड एकत्र करता है और इसे एक परीक्षक को देता है।
6. परीक्षक डेमो स्टैंड की जांच करता है।
7. रिलीज़ में सत्यापित कार्य एकत्र किया जाता है।
8. रिलीज में परीक्षण।
9. ठेस पर लेआउट।
10. लड़ाई में अंतिम परीक्षण।

जिम्मेदारी के क्षेत्रों द्वारा, कार्य को निम्नलिखित चरणों में विभाजित किया गया है:

1-5 - डेवलपर पर जिम्मेदारी;
6-7 - परीक्षक पर जिम्मेदारी;
8-10 - रिलीज मास्टर पर जिम्मेदारी।

इसलिए, उन्होंने विश्लेषण करना शुरू किया कि हमें सबसे अधिक समय क्या लगता है। सौभाग्य से, आंतरिक विश्लेषण उपकरण हैं। हर कोई इस बात पर भरोसा करता है कि सबसे लंबी, निश्चित रूप से, विकास प्रक्रिया खुद (स्थिति "इन वर्क" है) ... और यह इस तरह से निकला। लेकिन एक पल ने हमें सबसे ज्यादा हैरान किया। एक समीक्षा की औसत अवधि दो सप्ताह है!

चरण 1. पार्सिंग पीआर

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

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

चरण 2: एक ब्राउज़र के साथ जुदा

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

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

चरण 3. उपकरण का विस्तार

इस स्तर पर, हमने पहले से ही सरल बनाने की कोशिश की, जैसा कि हमने सोचा था, समीक्षकों का जीवन। निम्नलिखित उपकरण सामने के सिरे के शस्त्रागार में थे:

• कोड शैली चेकर्स;
• परीक्षण चलाने;
• पीआर में ही विभिन्न nerdy चेक;
• revyushnitsa;
• मेल और टास्क ट्रैकर पर अलर्ट।

ऐसा लगेगा कि सब कुछ है। लो और समीक्षा करो!

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

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

चरण 4. पहला एसएलए

क्रिया 2 और 3 के समानांतर, हमने कर्मचारियों के साथ मिलकर काम करना शुरू किया और बताया कि कोड की समीक्षा कार्य से ही अविभाज्य है। उन्होंने समझाया कि "सत्यापित" को लाना डेवलपर की जिम्मेदारी है। इसके अलावा, जिम्मेदारी केवल सहयोगियों के लिए ही नहीं है, बल्कि उपयोगकर्ताओं के लिए भी है! बिक्री के लिए सुविधाओं का तेज़ वितरण - यही मैं हासिल करना चाहता था। और टीम को सुधार प्रक्रिया के लिए सहानुभूति थी।

इस स्तर पर, आदर्श कोड समीक्षा का पहला विचार पैदा हुआ था। बेशक, हर कोई चाहता है कि यह 5 मिनट में हो, लेकिन यह हमेशा संभव नहीं है। यह ध्यान में रखते हुए कि हमारे पास एक बहु-क्षेत्रीय टीम है (चार घंटे के समय के अंतर के साथ), हम इस बात पर सहमत हुए कि हमारा SLA एक दिन होगा, अर्थात। 24 घंटे यह SLA सभी कर्मचारियों के लिए घोषित किया गया था और, अपने हाथों को रगड़कर, परिणामों की प्रतीक्षा करने लगे।

लेकिन स्थिति नहीं बदली है। सबसे अच्छे हफ्तों में, पुल के आधे अनुरोध 1 दिन में फिट हो जाते हैं। बाकी उसके लिए बाहर निकले।

हमारे पास एक छोटी स्क्रिप्ट थी जो पीआर पर टाइम कोड की समीक्षा का मूल्यांकन करती थी। हमने "पिछड़ने" की तलाश में सभी पीआरएस के लिए उन्हें दैनिक आधार पर दोष देना शुरू कर दिया। लगभग हर दिन ऐसा ही एक पैकेट था।

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

चरण 5. एसएलए ट्रैकर

जहां से इंतजार नहीं हुआ वहां से मदद मिली। ट्रैकर के हमारे सहयोगियों ने एक आश्चर्यजनक बात की घोषणा की: अब आप ट्रैकर में ही एसएलए स्थापित कर सकते हैं। इसके अलावा, आप इसे पूरी तरह से अलग तरीके से कॉन्फ़िगर कर सकते हैं। कार्य में कुछ घटना द्वारा एक निश्चित टाइमर को चालू किया जाता है। किसी घटना के लिए, यह विराम दे सकता है। और किसी घटना पर रुकें। हाँ, यह वही है जो हमें चाहिए!

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

यह भी अच्छा था कि टाइमर काम के घंटों और एक कैलेंडर को ध्यान में रखता था! हम निर्धारित करते हैं कि 9h कोड की समीक्षा के लिए सौंपा गया है, अर्थात्। एक व्यवसाय दिवस। इस मामले में, अलर्ट शुरू होने के बाद 2h चालू होता है, या यदि नौ घंटे की समय सीमा बाधित होती है। परिणाम एक तरह की ईमानदार निगरानी थी। सबसे पहले, हमने प्रयोग के लिए टाइमर चालू किया, बग्स का एक पैकेट एकत्र किया और ट्रैकर को निर्यात किया।

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

इस लेखन के समय, हमारे पास 415 कार्य हैं जिसमें टाइमर शुरू हो गया है। इनमें से 29 नौ घंटे की सीमा से आगे निकल गए। यद्यपि, यदि आप एक करीब से देखते हैं, तो आप ऐसे कार्यों का भी सामना करेंगे, जिनकी कोड समीक्षा अगले घंटे के भीतर पूरी हो गई थी। यदि हम उन्हें भी त्याग देते हैं, तो 17 कार्य शेष रह जाते हैं। और यह लगभग 4.1% है!

परिणाम। समुराई लगातार अपनी तलवार तेज कर रहा है

पीछे मुड़कर देखें और हमारे सभी कार्यों को याद करते हुए, एक निष्कर्ष निकाला जा सकता है - सभी साधन अच्छे हैं। हमारे सभी कदम वांछित परिणाम का कारण बने: 92% से अधिक पुल अनुरोधों ने हमारे SLA को संतुष्ट करना शुरू कर दिया ! कम और कम फटे हुए कार्य, कोड की समीक्षा तेज है। धीरे-धीरे, थोड़ा-थोड़ा करके, कोड की 75% समीक्षा 5 घंटे में फिट होने लगी ! और सुधार के लिए गतिशीलता अभी भी सकारात्मक है। संख्यात्मक संकेतकों के अलावा, हमें उपमहाद्वीपों से अधिक सकारात्मक प्रतिक्रिया मिलनी शुरू हुई। इस तथ्य से और भी अधिक प्रसन्नता हुई कि टीम ने इस पूरी प्रक्रिया पर प्रतिक्रिया दी। यहां तक ​​कि एक प्रक्रिया जैसे कि कोड रिव्यू एक्सीलरेशन ने टीम को और भी ज्यादा प्रभावित किया। प्रत्येक भागीदार जिम्मेदारी को समझने लगा कि वह दूसरों के सामने आता है, क्योंकि एक त्वरित समीक्षा कोड हमें अपने उपयोगकर्ताओं को और भी तेजी से लाभान्वित करने की अनुमति देता है।

बेशक, 9h अंतिम सपना नहीं है, लेकिन फिर भी सफलता है। लेकिन इस पर हमारा रुकने का इरादा नहीं है। हम कोड की समीक्षा प्रक्रिया की निगरानी करना और कर्मचारियों को सामना करने वाली सभी तकनीकी और यहां तक ​​कि मनोवैज्ञानिक समस्याओं को हल करना जारी रखते हैं ताकि हमारी प्रक्रिया यथासंभव उत्पादक हो और साथ ही टीम के लिए आरामदायक हो।

क्यू एंड ए क्या होगा अगर ...?

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

प्रश्न : और क्या होगा यदि जटिल पीआर, 100500+ कोड की लाइनें हैं, और "पत्र को बदल दें" हैं। न्याय कहाँ है?
A : हाँ, यह सच है। जब हम मानक कोड समीक्षा पर काम कर रहे थे, तो हमने इसे ऊपरी सीमा के साथ ले लिया, अर्थात। जटिल पीआर की कोड समीक्षा SLA में फिट होनी चाहिए। लेकिन एक ही समय में, हम सभी को इन सीमाओं में चलाने का कोई लक्ष्य नहीं है। हम हमेशा अनुरोधों को खींचने के लिए सहानुभूति रखते हैं, जिसमें एक दिन में टूटी हुई पट्टी के बावजूद एक जीवंत, उपयोगी चर्चा होती है।

हमारे पास स्टोरीपॉइंट्स पर SLA ग्रेड्स की योजना है। उदाहरण के लिए 1SP - 1h, 3SP - 5h, 5SP - 2d। सौभाग्य से, ट्रैकर पहले से ही इसके लिए सक्षम है। हम अभी इसके लिए तैयार नहीं हैं - हमारे पास अभी भी एक लंबा रास्ता तय करना है।