स्रोत नियंत्रण भंडार में समीक्षा किए गए स्रोत कोड को प्रबंधित करने का सबसे अच्छा तरीका क्या होगा? स्रोत कोड को जाँच करने से पहले समीक्षा प्रक्रिया से गुजरना चाहिए, या कोड की समीक्षा के बाद कोड की समीक्षा होनी चाहिए? यदि समीक्षा रिपॉजिटरी में कोड की जाँच के बाद होती है, तो उसे कैसे ट्रैक किया जाना चाहिए?
जवाबों:
Google ने मेरे द्वारा देखे गए किसी भी स्थान का सर्वोत्तम कोड समीक्षा अभ्यास किया है। सभी लोग जो मुझसे मिले थे, कोड समीक्षा कैसे करें, इस बारे में पूरी सहमति है। मंत्र "जल्दी और अक्सर समीक्षा" है।
मान लीजिए कि आप एक ऐसी प्रक्रिया का उपयोग करते हैं जो वैसा ही दिखता है जैसा कि ग्राहम ली ने सुझाया था। (जो एक ऐसी प्रक्रिया है जिसे मैंने पहले खुद इस्तेमाल किया था।) समस्या यह है कि समीक्षकों को कोड के बड़े हिस्से को देखने के लिए कहा जा रहा है। यह एक बहुत अधिक प्रयास है, और इसे करने के लिए समीक्षकों को प्राप्त करना कठिन है। और जब वे ऐसा करते हैं, तो उन्हें इसके लिए पूरी तरह से काम करना मुश्किल होता है। इसके अलावा जब वे डिजाइन के मुद्दों को नोटिस करते हैं, तो डेवलपर्स को वापस जाने के लिए और अपने सभी काम कोड को फिर से बेहतर बनाने के लिए इसे प्राप्त करना कठिन होता है। आप अभी भी सामान पकड़ते हैं, और यह अभी भी मूल्यवान है, लेकिन आप ध्यान नहीं देंगे कि आप 90% से अधिक लाभ से गायब हैं।
इसके विपरीत, Google के पास स्रोत नियंत्रण में जाने से पहले हर एक प्रतिबद्ध पर कोड की समीक्षा होती है । Naively कई लोगों को लगता है कि यह एक भारी वजन प्रक्रिया होगी। लेकिन यह अभ्यास में उस तरह से काम नहीं करता है। यह अलगाव में कोड के छोटे टुकड़ों की समीक्षा करने के लिए बड़े पैमाने पर आसान हो जाता है। जब समस्याएँ मिलती हैं, तो डिज़ाइन को बदलना बहुत कम काम है क्योंकि आपने अभी तक उस डिज़ाइन के आसपास कोड का एक गुच्छा नहीं लिखा है। परिणाम यह है कि पूरी तरह से कोड की समीक्षा करना बहुत आसान है, और बदले हुए मुद्दों को ठीक करना बहुत आसान है।
यदि आप Google की तरह कोड समीक्षा करना चाहते हैं (जो मैं वास्तव में करता हूं, वास्तव में अनुशंसा करता हूं), ऐसा करने में आपकी मदद करने के लिए सॉफ्टवेयर है। Google ने अपने टूल को Rietveld के रूप में Subversion के साथ एकीकृत किया है । गो (भाषा) Rietveld के एक संस्करण के साथ विकसित की गई है जिसे Mercurial के साथ उपयोग के लिए संशोधित किया गया है। वहाँ लोग हैं, जो नामित Git का उपयोग के लिए एक पुनर्लेखन है Gerrit । मैंने इसके लिए अनुशंसित दो वाणिज्यिक उपकरण भी देखे हैं, क्रूसिबल और रिव्यू बोर्ड ।
मेरे द्वारा उपयोग किया जाने वाला एकमात्र Google Rietveld का आंतरिक संस्करण है, और मैं इससे बहुत खुश था।
एक तकनीक जो मैंने कई टीमों पर प्रयोग की है वह यह है:
यह समीक्षा करने के लिए कोड लेखक की ज़िम्मेदारी है, और यह सुनिश्चित करने के लिए रिलीज़ शाखा अनुरक्षक की ज़िम्मेदारी है कि केवल समीक्षित कोड को मर्ज किया जाए।
ऐसे उपकरण हैं जो कोड समीक्षा का समर्थन करते हैं, लेकिन मैंने उनका कभी उपयोग नहीं किया है। ट्रैकिंग जिसने किसी भी मर्ज के लिए समीक्षा की, वह रेपो के अंदर किया जा सकता है। मैंने svn प्रॉपर्टीज़ और पेरफोर्स जॉब्स का इस्तेमाल किया है, जो यह दिखाने के लिए प्रतिबद्ध है कि किसने क्या रिव्यू किया।
मैंने कभी भी कमिटेड / नॉन-कमिटेड मापदंड द्वारा समीक्षा के लिए कोड अलग नहीं किया है - मैंने जो एकमात्र मानदंड पाया है, वह यह है कि यूनिट टेस्ट और इंटीग्रेशन टेस्ट हरे हैं।
ट्रैकिंग के लिए मैं आपके पसंदीदा मुद्दे ट्रैकर में प्रवाह को अद्यतन करने की सिफारिश करूंगा। इसके बजाय परीक्षा के लिए:
आप एक और चरण शुरू करना चाहते हैं (समीक्षा):
इसलिए कार्यान्वित राज्य में प्रत्येक टिकट के लिए आप एक समीक्षक को असाइन कर सकते हैं और केवल समीक्षित टिकट क्यूए के लिए अग्रिम होंगे।
मेरे पास कोड समीक्षाओं का केवल एक ही अनुभव है, इसलिए मैं यह नहीं कह सकता कि यह कितना अच्छा है।
मैं कोडर्स के एक छोटे (~ 10-15) समूह के साथ काम कर रहा था, और हम वीएस टीम फाउंडेशन स्टूडियो का उपयोग कर रहे थे। हमें दिन में एक बार कोड के बारे में पूछा गया था, और प्रत्येक प्रतिबद्ध कोड की समीक्षा समूह में किसी अन्य व्यक्ति द्वारा की जानी थी (उम्मीद है कि किसी व्यक्ति द्वारा परियोजना में शामिल भी)। प्रतिबद्ध के दौरान, एक क्षेत्र में व्यक्ति का नाम भी शामिल किया गया था।
मैंने एक टीम पर काम किया, जिसने एक हफ्ते में कुछ समीक्षाओं के दौरान परिवर्तन के आधार पर परिवर्तन की जाँच की गई कोड की समीक्षा की। इसका मतलब था कि हम हमेशा कोड समीक्षाओं के साथ अद्यतित नहीं थे, लेकिन इसने वह हासिल किया जो हमने हासिल करने के लिए निर्धारित किया था।
इसलिए पहले, यह पूछें कि आप कोड की समीक्षा करके क्या हासिल करना चाहते हैं। हमारे मामले में, यह बेवकूफ डेवलपर्स को पकड़ने के लिए नहीं था, अक्षमता की धारणा के बजाय क्षमता की धारणा थी। इसने टीम को सिस्टम के अन्य क्षेत्रों का अवलोकन करने की अनुमति दी, और पत्थर में सेट होने से पहले कुछ संदिग्ध डिजाइन निर्णयों को ठीक करने की अनुमति दी। संदिग्ध रूप से, मेरा मतलब है कि एक बिल्ली की त्वचा के लिए हमेशा एक से अधिक तरीके होते हैं, और हर कोई नहीं जानता है कि टूलबॉक्स में बिल्ली की चमड़ी का चाकू पहले से ही है, इसलिए बोलने के लिए।
जिस तरह से हमने कोड समीक्षाओं का सामना किया, वह यह था कि हमारे प्रोजेक्ट ट्रैकिंग सॉफ़्टवेयर के हर कार्य की समीक्षा की गई थी। उस समय हम मंटिस और एसवीएन का उपयोग कर रहे थे। हमारा प्रोजेक्ट कमिट दोनों प्रणालियों में बंधा हुआ था। हर कमिटमेंट को मंटिस में टास्क से बंधना पड़ता था। एक बार कार्य पूरा होने के बाद "रेडी फ़ॉर रिव्यू" का दर्जा दिया गया।
RFR आइटम तब या तो किसी के द्वारा उठाए गए थे जिनके पास समीक्षा के लिए कुछ खाली समय था या उन्हें समीक्षा के लिए किसी विशिष्ट व्यक्ति को सौंपा गया था। शुक्रवार को सभी RFR आइटमों की समीक्षा दिन के अंत से पहले की जानी थी ताकि अगले सप्ताह तक कैरीओवर न हो।
इस प्रक्रिया के साथ हम जिन समस्याओं में भाग लेते थे, उनमें बड़ी समस्या थी बड़ी मात्रा में फाइलें। इसे संभालने के लिए कोडर और समीक्षक एक साथ मिल जाएंगे और कोडर तब तक परिवर्तनों से चलेगा जब तक समीक्षक उन्हें समझ नहीं लेते। वे कोड की समीक्षा एक साथ करेंगे।
यह प्रक्रिया तब टूट गई जब प्रबंधन ने आदेश दिया कि यदि सहकर्मी प्रोग्रामिंग की गई तो एक अलग कोड समीक्षा अनावश्यक थी। डेवलपर्स प्रक्रिया के बारे में शिथिल हो गए और छोटे-छोटे बेवकूफ बग पेश किए जाने लगे। आखिरकार हम मूल प्रक्रिया में वापस चले गए और चीजें एक साथ वापस आईं।
मेरी टीम में हम पिछले एक साल से एक अभ्यास का उपयोग कर रहे हैं या ऐसा लगता है कि यह बहुत अच्छा काम कर रहा है।
हमारा संगठन संस्करण नियंत्रण के लिए पेरफोर्स का उपयोग करता है। Perforce (एक साल पहले तक) में एक सुविधा शामिल है, जिसे शेल्विंग कहा जाता है। ठंडे बस्ते में डालने के साथ, मैं एक विशेष मुद्दे के लिए अपने परिवर्तनों को "आश्रय" कर सकता हूं। उन्हें संस्करण नियंत्रण प्रणाली में संग्रहीत किया जाता है, लेकिन चेक इन नहीं किया जाता है। फिर मैं अपनी टीम के किसी अन्य डेवलपर से कोड की समीक्षा करने के लिए कहता हूं।
अन्य डेवलपर अपने कंप्यूटर से Perforce में मेरे लंबित परिवर्तनों को देख सकते हैं, और परिवर्तनों की तुलना सबसे हाल के संशोधनों से कर सकते हैं। यदि वह मेरे परिवर्तनों को आज़माना चाहता है, तो वह अपनी स्थानीय मशीन पर "अनशेल्व" भी कर सकता है। जब उन्होंने समीक्षा पूरी कर ली, तो उन्होंने मुझे बताया। मैं टिप्पणी के अंत में "समीक्षित बॉब द्वारा" के साथ अपने कोड में जांच करता हूं।
इसने हमारे लिए वास्तव में अच्छा काम किया है। सबसे पहले, सामान्य रूप से कोड समीक्षाएं बेहद मददगार साबित हुई हैं। इसके अतिरिक्त, पेरफोर्स की ठंडे बस्ते की सुविधा हमें समीक्षा या बिना किसी बड़ी कठिनाई के समीक्षा करने की अनुमति देती है, भले ही हमारी टीम भौगोलिक रूप से व्यापक हो - यह बहुत महत्वपूर्ण है। और यह बहुत अच्छा काम करता है।