कोड कमिट से पहले या बाद में समीक्षा करें, जो बेहतर है?

Question

परंपरागत रूप से हमने प्रतिबद्ध होने से पहले कोड की समीक्षा की, मेरे पास आज अपने सहकर्मी के साथ एक तर्क था, जिसने प्रतिबद्ध के बाद कोड की समीक्षा को प्राथमिकता दी।

सबसे पहले, यहाँ कुछ पृष्ठभूमि है,

1. हमारे पास कुछ अनुभवी डेवलपर्स हैं और हमारे पास लगभग शून्य प्रोग्रामिंग अनुभव के साथ नए हायर भी हैं।
2. हम अपने उत्पाद को जारी करने के लिए तेजी से और कम पुनरावृत्तियों करना चाहते हैं।
3. सभी टीम के सदस्य एक ही साइट पर स्थित हैं।

कोड समीक्षा के फायदे इससे पहले कि मैंने सीखा है:

1. मेंटर नई हायर
2. विकास चक्र में त्रुटियों, विफलताओं, बुरे डिजाइनों को रोकने की कोशिश करें
3. दूसरों से सीखें
4. अगर कोई क्विट करता है तो नॉलेज बैकअप

लेकिन मुझे कुछ बुरे अनुभव भी हुए:

1. कम दक्षता, कुछ बदलावों की समीक्षा की जा सकती है
2. विशेष रूप से newbies के लिए गति और गुणवत्ता को संतुलित करना मुश्किल है
3. एक टीम के सदस्य ने अविश्वास महसूस किया

जैसा कि पोस्ट-कमिट की समीक्षा के बाद, मैं इस बारे में बहुत कम जानता हूं, लेकिन जिस चीज को लेकर मैं सबसे ज्यादा चिंतित हूं, वह है समीक्षा की कमी के कारण नियंत्रण खोने का जोखिम। कोई राय?

अपडेट करें:

1. हम VCS के लिए Perforce का उपयोग कर रहे हैं
2. हम एक ही शाखाओं (ट्रंक या बग फिक्सिंग शाखाओं) में कोड और कमिट करते हैं
3. दक्षता में सुधार के लिए, हमने कोड को छोटे परिवर्तनों में विभाजित करने का प्रयास किया है। हमने कुछ लाइव संवाद समीक्षा की भी कोशिश की है, लेकिन सभी ने नियम का पालन नहीं किया है। हालांकि यह एक और समस्या है।

Comments

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

— साइमन व्हाइटहेड

इसके बजाय समीक्षा सबसे अच्छा विकल्प है

— shabunc

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

— HABO

इसमें डुप्लिकेट किया गया: programmers.stackexchange.com/questions/121664/… और programmers.stackexchange.com/questions/158243/…

— gnat

Answer 1

जैसा साइमन व्हाइटहेड उसकी टिप्पणी में उल्लेख है , यह आपके शाखाओं में रणनीति पर निर्भर करता है।

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

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

Comments

यदि डेवलपर्स की अपनी शाखाएं हैं और आपके पास एक उचित कोड-समीक्षा उपकरण है, तो आप नियंत्रण बनाए रख सकते हैं। समीक्षकों को उपकरण में रिकॉर्ड करना है कि उन्होंने समीक्षा की है या नहीं।

— मार्कजे सेप

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

— वाब

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

— पांचवां

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

— इज़काता

@ThomasOwens: Perforce ब्रांचिंग का समर्थन करता है, लेकिन SVN, GIT, या Mercurial की आसानी के साथ नहीं।

— केविन क्लाइन

Answer 2

एक मंत्र है कि किसी को अभी तक उद्धृत नहीं किया गया लगता है: जल्दी और अक्सर जाँच करें :

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

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

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

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

... यदि आप जल्दी में जाँच करना सीखते हैं और अक्सर जाँच करते हैं, तो आपके पास प्रतिक्रिया, एकीकरण और समीक्षा के लिए पर्याप्त समय होगा ...

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

जेफ एटवुड का कथन भी है: चीजों को तोड़ने से मत डरो :

एक सॉफ्टवेयर डेवलपर के रूप में सुधार करने का सबसे सीधा तरीका यह है कि जब आपका कोड बदलने की बात हो तो वह बिल्कुल निडर हो। जो डेवलपर्स टूटे हुए कोड से डरते हैं वे डेवलपर्स हैं जो कभी भी पेशेवरों में परिपक्व नहीं होंगे।

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

Comments

मुझे यह उत्तर पसंद है - मुझे लगता है कि यह बाउंटी में उल्लिखित शेष विषयों को अच्छी तरह से भर देता है।

— जोरिस टिम्मरमैन

— समीक्षकों

यह काफी बेहतर है। यह एक उद्यम की तरह विकास ध्वनि बनाना शुरू करता है जो टीम के भीतर संचार को एक यंत्रवत दोष परिहार प्रणाली के विपरीत मानता है।

— इयान

Answer 3

मैंने हाल ही में एक प्रोजेक्ट में प्री-कमिटमेंट रिव्यू करना शुरू किया है और मुझे कहना होगा कि मुझे इस बात पर सुखद आश्चर्य हो रहा है कि यह कितना अस्वाभाविक है।

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

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

Comments

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

— एंड्रयू

Answer 4

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

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

Comments

क्या यह लाइव संवाद समीक्षाओं के लिए समय लिया गया था? क्या आपकी टीम ने सभी कोड की समीक्षा की?

— पांचवां

हम सभी कोडों की समीक्षा नहीं करते हैं, लेकिन बहुत कुछ ऐसा है जो कम से कम मामूली जटिल है।

— गुरिल्ला

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

— कुब्बी k

Answer 5

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

इसके अलावा, आप जोड़ी कोडिंग (जूनियर के साथ वरिष्ठ जोड़े) को एक अंतर्निहित कोड समीक्षा प्रदान करने का एक और तरीका मान सकते हैं। कार के लुढ़कने के बजाय इसे असेंबली लाइन पर गुणवत्ता निरीक्षण के रूप में देखें।

Comments

मुझे जोड़ी कोडिंग बहुत पसंद है, लेकिन माइक, एक सीनियर और एक जूनियर जोड़ीदार कोडिंग नहीं है, यह सलाह है। मैं दृढ़ता से सलाह देने का सुझाव देता हूं, लेकिन इन दो चीजों को / के खिलाफ कारणों के रूप में प्रतिष्ठित किया जाना चाहिए, और परिणाम, मेंटरिंग और जोड़ी प्रोग्रामिंग के बीच पूरी तरह से अलग हैं। पर 4 पद का संदर्भ लें: c2.com/cgi/wiki?PairProgrammingDoubts भी c2.com/cgi/wiki?PairProgrammingIsDoneByPeers

— जिमी हौफा

हर बार नहीं। जूनियर व्यक्ति के पास इनपुट हो सकता है। या "बेवकूफ त्रुटियों" को नोटिस करें।

— १५:०५ पर जीन बॉयर्सकी

@JeanneBoyarsky मैं ऐसा नहीं करने के लिए कह रहा था, बस गतिशील अलग है और परिणाम अलग हैं (कोड नहीं, मेरा मतलब है कि पूरी प्रक्रिया के परिणामी लाभ हैं)। इसके अलावा अगर "कनिष्ठ" व्यक्ति को समान रूप से लाभकारी डिज़ाइन इनपुट या समान रूप से अधिक मात्रा में हो रहा है, जब किसी के वरिष्ठ के साथ जोड़ा जाता है, तो मैं "जूनियर" प्रस्तुत करूँगा इतना कनिष्ठ या "वरिष्ठ" कोई वरिष्ठ नहीं है।

— जिमी हॉफा

आप सही हैं ... लेकिन मुझे लगता है कि यह ज्ञान साझा करने का सबसे प्रभावी साधन है।

— माइकल ब्राउन

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

— oवद्रालो

Answer 6

दोनों करो :

• प्री कमिटमेंट - इस तरह की समीक्षा तब करें जब यह बहुत महत्वपूर्ण हो, जैसे एक बहुत ही पुन: प्रयोज्य कोड टुकड़ा, या प्रमुख डिजाइन निर्णय
• पोस्ट कमिट - इस तरह की समीक्षा तब करें जब आप उस कोड के टुकड़े पर राय प्राप्त करना चाहते हैं जिसे बेहतर बनाया जा सकता है

Answer 7

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

यह किसी भी तरह से बचा जाता है "आपको नवीनतम फ़ाइल नहीं मिली है" प्रकार के तर्क, और यह सुनिश्चित करता है कि हर कोई स्रोत-कोड की एक ही प्रतिलिपि की समीक्षा कर रहा है।

इसका यह भी अर्थ है कि, क्या किसी भी समीक्षा के बाद सुधार की आवश्यकता होनी चाहिए, इतिहास को इस तथ्य के साथ व्याख्या किया जा सकता है।

Answer 8

कोड की समीक्षा के लिए, प्रतिबद्ध के दौरान मेरा वोट 'के लिए' है।

गेरिट या क्लोवर (मुझे लगता है) जैसी प्रणाली एक बदलाव को चरणबद्ध कर सकती है और फिर समीक्षक इसे स्रोत नियंत्रण के लिए प्रतिबद्ध कर सकता है (यदि यह अच्छा है तो धक्का दें)। यह दोनों दुनिया के लिए सबसे अच्छा है।

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

जो डिजाइन की समीक्षा की ओर जाता है - जबकि आप इसे कोड समीक्षा समय पर कर सकते हैं (या ग्राहक की तैनाती के समय में इस मामले के लिए), डिजाइन के मुद्दों को खोजना इससे पहले किया जाना चाहिए - इससे पहले कि कोड वास्तव में लिखा जाए।

Answer 9

सहकर्मी समीक्षा के साथ नियंत्रण खोने का कम से कम जोखिम है। हर समय दो लोगों को एक ही कोड के बारे में ज्ञान होता है। उन्हें कभी-कभी स्विच करना पड़ता है, इसलिए कोड का ट्रैक रखने के लिए उन्हें हर समय चौकस रहना पड़ता है।

यह एक कुशल डेवलपर और एक नौसिखिया एक साथ काम करने के लिए समझ में आता है। पहली नज़र में यह अक्षम लगता है, लेकिन ऐसा नहीं है। वास्तव में, कम कीड़े हैं, और उन्हें ठीक करने में कम समय लगता है। इसके अलावा, newbies बहुत तेजी से सीखेंगे।

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

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

Answer 10

पूर्व और बाद दोनों से लाभ की समीक्षा करता है।

पूर्व-समीक्षा प्रतिबद्ध

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

समीक्षा के दौरान कोई रनिंग कमिट नहीं

मैंने एटलसियन टूल्स का इस्तेमाल किया है और समीक्षा के दौरान कमिट्स को चलाते देखा है। यह समीक्षकों को भ्रमित कर रहा है, इसलिए मैं इसके खिलाफ सलाह देता हूं।

समीक्षा के बाद संशोधन

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

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

समीक्षा के बाद की प्रतिबद्धता

• प्री-रिव्यू कमेटी के खिलाफ तुलना करने के लिए मॉडरेटर और अन्य समीक्षकों को डेटा पॉइंट देता है।
• दोष हटाने और कोड सुधार में समीक्षा के मूल्य और सफलता दोनों का न्याय करने के लिए मैट्रिक्स प्रदान करता है।

Answer 11

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

उन पंक्तियों के साथ, एक अच्छी CI प्रक्रिया और / या गेटेड चेक-इन करने से पहले समीक्षा की आवश्यकता कम हो जाती है (और उनमें से कई के लिए यकीनन पोस्ट कमिट)।

Answer 12

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

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

इनमें से, हमने निम्नलिखित अनुमानी नियम निकाले हैं:

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

पूरा शोध पत्र यहां उपलब्ध है: http://dx.doi.org/10.1145/2904354.2904362 या मेरी वेबसाइट पर: http://tobias-baum.de

Comments

क्या इस मॉडल को किसी वास्तविक विश्व डेटा से सत्यापित किया गया है?

— पीटर

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

— तोबियास बी।

धन्यवाद, जो उत्तर को परिप्रेक्ष्य में रखता है और इस तरह इसे अधिक मूल्यवान बनाता है। +1

— पीटर

Answer 13

मेरी राय में, अगर पोस्ट-कमिट किया जाए तो कोड पीयर रिव्यू सबसे अच्छा काम करता है।

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

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

http://www.atlassian.com/software/crucible/overview

उपयोगकर्ता / सुविधा शाखाओं के कुछ अन्य लाभ:

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

अनुभवहीन डेवलपर्स के लिए, एक संरक्षक और / या जोड़ी प्रोग्रामिंग के साथ नियमित परामर्श एक अच्छा विचार है, लेकिन मैं इसे "कोड समीक्षा" नहीं मानूंगा।

Comments

क्रूसिबल शानदार है, और इसे शुरू करने के लिए केवल $ 10 का खर्च आता है। (हालांकि $ 10 संस्करण केवल 5 रिपॉजिटरी का प्रबंधन करेगा, जिसका अर्थ है कि आप इसे जल्दी से आगे बढ़ा सकते हैं, और वहां से अगला कदम बहुत अधिक महंगा है। $ 1k IIRC जैसा कुछ।)

— मार्क ई। हासे

Answer 14

दोनों। (एक प्रकार का।)

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

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

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

संपादित करें: मुझे यह भी जोड़ना चाहिए कि आपको परीक्षण के बाद कोड की समीक्षा करनी चाहिए, जो पहले कोड करने के पक्ष में एक और तर्क है। आप नहीं चाहते हैं कि आपका परीक्षण समूह दर्जनों प्रोग्रामर से भिन्न हो / सभी प्रोग्रामर से भिन्न हो, फिर बग दर्ज करें क्योंकि वे गलत स्थान पर गलत पैच लागू करते हैं।

Answer 15

100% युग्मित प्रोग्रामिंग (चाहे आप कितने भी वरिष्ठ हों आपको) बहुत से छोटे-छोटे कमिट्स और एक CI सिस्टम है जो EVERY कमिट पर बनाता है (जहां संभव हो यूनिट्स, इंटीग्रेशन और फंक्शनल सहित स्वचालित परीक्षण के साथ)। बड़े या जोखिम भरे बदलावों के लिए पोस्ट-कमिट समीक्षा। यदि आपके पास किसी प्रकार की gated / पूर्व-प्रतिबद्ध समीक्षा होनी चाहिए, तो Gerrit कार्य करता है।

Answer 16

कोड (बड़े चेक) पर चेक रिव्यू का फायदा तत्काल फीडबैक होता है, इससे पहले कि कोड के बड़े टुकड़े पूरे हो चुके हों।

चेक में कोड समीक्षा का नुकसान यह है कि यह लोगों को चेक करने से हतोत्साहित कर सकता है जब तक कि कोड के लंबे खंड पूरे नहीं हो जाते। यदि ऐसा होता है, तो यह पूरी तरह से लाभ को नकार देता है।

जो बात इसे और कठिन बनाती है, वह यह नहीं कि हर डेवलपर एक जैसा हो। सरल समाधान सभी प्रोग्रामर के लिए काम नहीं करते हैं । सरल उपाय हैं:

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

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

• प्रत्येक चेक-इन की समीक्षा करें, जो लगातार समीक्षा की गारंटी देता है। कुछ डेवलपर्स भुलक्कड़ हैं और बहुत बार चेक इन पर भरोसा करते हैं, जिसका अर्थ है कि दूसरों को हर 15 मिनट में कोड समीक्षा करनी होती है।

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

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

• काम उन कार्यों में टूट जाता है जिन्हें एक दिन से कम समय लेना चाहिए।
• यदि कोड (यदि कोई है) की जाँच नहीं की गई है तो एक कार्य समाप्त नहीं हुआ है।
• यदि कोड (यदि कोई है) की समीक्षा नहीं की गई है तो एक कार्य समाप्त नहीं हुआ है।

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

Answer 17

हम वास्तव में LedgerSMB पर एक हाइब्रिड करते हैं। कमिटर्स उन परिवर्तनों को करते हैं जिनकी समीक्षा की जाती है। गैर-कमिटर्स पहले समीक्षा की जाने वाली कमिटर्स के लिए बदलाव प्रस्तुत करते हैं। यह समीक्षा के दो स्तरों का मतलब है। पहले आपको समीक्षा करने और आपको सलाह देने के लिए एक संरक्षक मिलता है। फिर उस संरक्षक को कोड की समीक्षा करने के बाद दूसरी बार उसके पास जाने पर या उस पर हस्ताक्षर करने के बाद फीडबैक मिलता है। आम तौर पर नए लोग पहली बार दूसरे लोगों के आवागमन की समीक्षा करने में बहुत समय बिताते हैं।

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

Answer 18

प्रतिबद्ध कहाँ? एक शाखा है जिसे मैंने कुछ काम करने के लिए बनाया है। जब भी मुझे ऐसा लगता है मैं उस शाखा के लिए प्रतिबद्ध हूं। यह किसी का व्यवसाय नहीं है। फिर किसी बिंदु पर उस शाखा को एक विकास शाखा में एकीकृत किया जाता है। और कहीं बीच में एक कोड समीक्षा है।

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

Answer 19

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

स्वचालित प्रक्रिया होनी चाहिए, इसमें शामिल होने वाले मनुष्य सिर्फ बेकार हैं।

Comments

दुर्भाग्य से, सवाल यह था कि पहले या बाद में समीक्षा करना है या नहीं - उन्हें करना है या नहीं। यदि आपके पास पहले / बाद के बारे में कोई राय है, तो कृपया उसे जोड़ें।

— मार्को