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

बाजार पर तैयार उपयोग परिदृश्यों, सिफारिशों और नियमों के साथ कोड की समीक्षा के लिए उपकरणों का एक गुच्छा है। GitHub, Phabricator, FishEye / Crucible, GitLab, Bitbucket, Upsource - सूची आगे बढ़ती है। ब्रेट में, हमने एक समय में उनके साथ भी काम किया था: अपने पिछले लेख में मैंने कोड रिव्यू के बारे में अपनी कहानी बताई थी और हम अपने "साइकिल" - कोडिसोक समाधान के आविष्कार के साथ कैसे आए।

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

इसीलिए हिमखंड के दूसरे हिस्से पर ध्यान नहीं दिया जा सकता है।

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

इस परिचय को पढ़ने के बाद, आपके पास एक सवाल हो सकता है: कोड समीक्षा के बारे में क्या जटिल है? बात तल्खी भरी है। इसके अलावा, अधिकांश उपकरण तुरंत ऊपर सूचीबद्ध किए गए हैं और एक फ्लो रिव्यू (बॉक्स से बाहर: सेट, कमिट / स्टार्ट - एंड गो)!

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

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

तो, PILOT ने तब कहा: "समीक्षा प्रक्रिया में मेरे लिए सबसे कठिन बात यह है कि समाप्त और सही ढंग से काम करने वाले को आगे समझौता करना और छोड़ना है, भले ही मैं इसे हल करने का एक और तरीका जानता हूं और भले ही मुझे अपनी विधि अधिक पसंद हो।" मेरी राय में, यह एक महत्वपूर्ण विचार है। और मेरे पूरे लेख का मुख्य संदेश किसी न किसी तरह से इस आसन के इर्द-गिर्द घूमता है।

मुझे एक कोड समीक्षा प्रक्रिया की आवश्यकता क्यों है?

क्या आपकी कंपनी में समीक्षा है? क्या आप इसे सही कर रहे हैं? मेरे पास एक परीक्षण है जिससे आपको संदेह हो सकता है।

आपको केवल तीन सवालों के जवाब देने की जरूरत है:

औसत (एक निर्वात में गोलाकार) कार्य के लिए एक कोड की समीक्षा में कितना समय लगता है?
आप समीक्षा समय को कैसे कम करते हैं?
यदि आप किसी विशिष्ट कार्य की समीक्षा सही ढंग से करते हैं, तो आप कैसे निर्धारित करते हैं?

यदि आपके पास कुछ (या सभी) प्रश्नों के स्पष्ट उत्तर नहीं हैं, यदि आप अपने उत्तरों पर संदेह करते हैं, तो मैं यह मानने की हिम्मत करता हूं कि कुछ गलत हो रहा है।

यदि आपको नहीं पता कि समीक्षा करने में कितना समय लगेगा, और इसे लगातार कम से कम न करें, तो आप कैसे योजना बनाते हैं? क्या यह संभव है कि चार घंटे तक समीक्षा करने वाले कलाकार ने इस बार आधी चाय न पी हो? क्या यह सुनिश्चित करना संभव है कि चाय पीने का समय कार्य से कार्य तक नहीं बढ़ता है? या हो सकता है कि समीक्षक कोड को बिल्कुल नहीं देखता है, लेकिन बस "कोड ठीक है" पर क्लिक करता है?

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

यदि तीसरे प्रश्न का उत्तर तुरंत नहीं आता है, तो यह एक और पूछने के लिए समझ में आता है। क्या आप जानते हैं कि आपको वास्तव में इस प्रक्रिया की आवश्यकता क्यों है? क्योंकि "सभी बड़े लोगों के लिए बहुत प्रथागत है"? शायद आपको उसकी बिल्कुल भी जरूरत नहीं है?

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

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

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

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

खराब कोड की समीक्षा

तो सही प्रक्रिया क्या है? चलो ठीक है। नीचे मेरे बहुत सारे व्यक्तिगत तर्क होंगे, और उन लोगों के लिए जो यह जानने के लिए इंतजार नहीं कर सकते हैं कि मैं यह सब क्या लिख रहा हूं, मैं तुरंत "गुड कोड रिव्यू" भाग पर जाने का प्रस्ताव करता हूं।

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

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

ज्ञान बांटना

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

मैंने बार-बार लोगों से पूछा है कि वे "ज्ञान बांटने" से क्या मतलब है। और जवाब में मैंने अलग-अलग बातें सुनीं।

सबसे पहले, यह स्वीकार किए गए नियमों और प्रथाओं के नवागंतुकों (टीम या प्रभावित घटक में) के लिए एक प्रदर्शन है: यह है कि यह हमारे लिए ऐसा करने के लिए प्रथागत है, और हम ऐसा नहीं करते हैं, यही कारण है और यही कारण है कि।

दूसरे, यह सामान्य चीजों को कैसे किया जाता है, इस पर एक शुरुआती (फिर से एक टीम या एक प्रभावित घटक में) का एक नया रूप है। अचानक उन्हें अक्षम रूप से किया जा रहा है, और क्या कोई नया व्यक्ति इसे खोजने में मदद करेगा?

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

आइए सभी बिंदुओं पर जाएं और यह आकलन करने का प्रयास करें कि वे समीक्षा प्रक्रिया में कितने प्रासंगिक हैं।

शुरुआती लोगों के लिए एक प्रशिक्षण उपकरण के रूप में कोड की समीक्षा

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

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

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

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

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

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

क्या निष्कर्ष निकाला जा सकता है? ऊपर वर्णित प्रक्रिया एक अलग लक्ष्य प्राप्त करने के उद्देश्य से है: प्रशिक्षण के लिए नहीं, बल्कि नियंत्रण के लिए। और यह केवल नियंत्रण न केवल शुरुआती के लिए, बल्कि टीम के लिए भी आवश्यक है।

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

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

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

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

आप यह कहते हुए आपत्ति कर सकते हैं कि हम हर दिन "महत्वपूर्ण लोगों के लिए" कार्यों को तैयार नहीं करते हैं और यह बहुत संभव है कि शुरुआती के लिए बहुत जरूरी नहीं या बहुत महत्वपूर्ण कार्य न सौंपा जाए। और आप सही होंगे।

लेकिन सबसे पहले, एक शुरुआत तुच्छ कार्यों से क्या सीखती है जिसमें कुछ कोड परिवर्तन होते हैं (और ये परिवर्तन महत्वपूर्ण स्थानों में नहीं हैं और व्यवसाय के लिए संभवतः इतने महत्वपूर्ण नहीं हैं, क्योंकि कार्य तत्काल है)? अगर वह हर समय क्रीम को चाटता है तो वह केक कैसे सीख सकता है? सरल से जटिल, निश्चित रूप से संक्रमण की आवश्यकता है। लेकिन ऐसा करना आवश्यक है, ध्यान से प्रक्रिया को नियंत्रित करना। शुरुआती को पढ़ाने की जरूरत है, न कि खुद से सीखने को छोड़ दें।

और दूसरी बात, यहां तक कि ऐसा प्रतीत होता है उपयोगी और सही दृष्टिकोण एक कंपनी को नुकसान पहुंचा सकता है। समझने के लिए यह बहुत सरल है, निष्कर्ष को सरल और समझ में लाने के लिए गैरबराबरी के बिंदु पर लाने की विधि का उपयोग करना।

कल्पना कीजिए कि हम खुले तौर पर घोषणा करते हैं कि उत्पाद प्रबंधक हमें जो कार्य देता है, वे नए लोगों को प्रशिक्षित करने के लिए आवश्यक हैं। क्यों? और कोड की समीक्षा के साथ भी ऐसा ही है: आखिरकार, हम शुरुआती लोगों को कुछ सरल और गैर-जरूरी काम सौंपते हैं ताकि वे सीखें कि हमारे साथ प्रथागत तरीके से कैसे काम करना है।

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

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

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

यदि आपकी कंपनी एक संस्था नहीं है, एक स्कूल नहीं है, एक तकनीकी विद्यालय या कोई अन्य शैक्षणिक संस्थान नहीं है, तो प्रशिक्षण आपकी प्रत्यक्ष जिम्मेदारी नहीं है। व्यवसाय ने आपको अन्य समस्याओं को हल करने और अन्य परिणाम प्राप्त करने के लिए काम पर रखा है।

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

कोड पर एक नए रूप में कोड की समीक्षा

चलो आगे बढ़ते हैं। "अनुभव के आदान-प्रदान" का निम्नलिखित परिदृश्य यह है: हम टीम में कुछ करते हैं, आंतरिक समझौतों का पालन करते हैं, और हमारी आँखें धुंधली हो जाती हैं, और फिर एक नया व्यक्ति आया (किसी अन्य कंपनी से या किसी अन्य घटक से) - और शायद वह हमारी खामियों को देखेगा काम का संगठन।

विचार अच्छा है, यह उचित लगता है। वास्तव में, अगर हम कुछ गलत कर रहे हैं तो क्या होगा?

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

स्पष्ट रूप से नहीं, क्योंकि: 1) हमने हमेशा सोडा के बिना किया था, और परिणाम बुरा नहीं था; 2) यह संभव है कि ग्राहक हमसे केक लें, न कि दूसरे बेकरी से, क्योंकि वे सोडा के स्वाद की तरह नहीं हैं; 3) केक तैयार है, शादी आज रात है, और हमारे पास नए केक को सेंकने का समय नहीं होगा।

फिर यह सब क्यों है? अनुभव साझा करना आवश्यक है। नए सिरे से देखने की जरूरत है। लेकिन, यह मुझे एक अलग स्तर पर लगता है। उदाहरण के लिए, केक को पकाने से पहले , आप एक शुरुआत के साथ देख सकते हैं: “और इससे पहले आपने यह कैसे किया? यह तरीका बेहतर क्यों है? ” और, शायद, यह हमारे नियमित ग्राहकों को एक कोशिश करने और उनकी राय लेने के लिए पुराने और नए तरीके से एक-दो केक पकाने के लायक है।

लेखों या रिपोर्टों में देखी गई सर्वोत्तम प्रथाओं का विचारहीन कार्यान्वयन कंपनी और उत्पाद को नुकसान पहुंचा सकता है। "सोडा को सभी प्रमुख खिलाड़ियों द्वारा केक में जोड़ा जाता है:" बगले "," ट्रेस्कबुक "," रिलेकान "," यमडेक्स "। हर कोई इसे करता है। ” तो क्या? इस वजह से, क्या पेट्या को पहले से तैयार किसी कार्य के रीमेक से तुरंत निपटना चाहिए?

मुझे यकीन है कि नहीं। यदि शुरू में, समस्या को हल करने से पहले, आप इस बात से सहमत नहीं थे कि "केक में सोडा होगा", तो कोड समीक्षा चरण में इसके अतिरिक्त की मांग करना बहुत ही अदूरदर्शी है। आपके व्यवसाय में "केक में सोडा होने" का लक्ष्य नहीं है। यदि आपके केक पहले से ही अच्छे से बिक रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि उनके पास सोडा है या नहीं।

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

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

कोड की एक कोड के लिए एक परिचय के रूप में कोड की समीक्षा

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

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

आइए कोड को लिखने वाले व्यक्ति की आंखों के माध्यम से स्थिति को देखें। , ?

, - (, , , ). , ? , . , , , .

, , , , . . , ?

, - . , - . , : , . , , , , .

, . , - ? — . , , .

, , , - . , . , , . , , , . . , - : , , .

? , , — . .

best practices « -» « , ». तो क्या? Best practices , , . , ? . , - , .

best practices, , . . — - , / — . « », « », « — , DI». ? ?

, , . , , — , .

, -, «», , - . ? - , , , . , . , .

-, « » «» , . -, . , , - , : ? . , , ( : , ).

, , . , , ( , ?).

— . , , . . ? bus factor , , - , .

, , , : , ?

— , , ?
— .
— ?
— .

. , ? , , , ? , , , — ?

, , , , , ?

, , , . , , .

, . , , , ( ), , ( , , , — , . .). , .

— , , , . ( , , . .) . — — .

Code review

« ?» . , , .

: - , , - , , . git blame , , , , , .

, , — , , , ( ) — . , , . . , ?

. ?

, , , . , , , . , - ( , ). , , — , , , .

, , . ? , .

, , , . , . , ? .

, , — , . ( )?

« - - » . , . .

: . .

, , . , . , .

, , — . , .

— . , . , . , .

, , :

? , , ? ? , , ? - , ? ? ? और इसी तरह।

, . , . , .

, , . , , , . , , , .

, best practices, . , , , , . . , , . , .

,

. , , . - , , - .

, , . , API- . , bus factor, .

, . .

- ? , . , . null , « ». .

, . , ? ?

-

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

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

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

निष्कर्ष

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

और अंत में, मैं कुछ और सुझाव दूंगा।

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

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

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

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

लेकिन, निर्णय, आप के साथ रहता है।

कोड समीक्षा: आप इसे गलत कर रहे हैं