ट्रंक के लिए प्रतिबद्ध होने से पहले किसी कोड की समीक्षा करने का सबसे अच्छा तरीका क्या है? (SVN)

Question

SVN ट्रंक के लिए प्रतिबद्ध होने से पहले किसी कोड की समीक्षा करने का सबसे अच्छा तरीका क्या है? एक विचार जो मैं सोच रहा हूं, वह यह है कि डेवलपर अपने कोड को किसी शाखा में भेजने के लिए है और फिर शाखा में संशोधन को ट्रंक में विलय करते समय अपने कोड की समीक्षा कर रहा है। क्या यह अच्छा अभ्यास है? यदि नहीं, तो ट्रंक के लिए प्रतिबद्ध होने से पहले किसी कोड की समीक्षा करने के लिए और क्या किया जा सकता है?

Comments

आप क्रूसिबल जैसे कुछ औजारों में देख सकते हैं जो पूर्व-प्रतिबद्ध समीक्षाओं के लिए समर्थन प्रदान करते हैं।

— ज्ञान उर्फ ​​गैरी ब्यन

ट्रंक के लिए प्रतिबद्ध होने के बाद किसी कोड की समीक्षा नहीं करने का कोई कारण ?

— gnat

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

— मयसम

क्या आपने दूसरे तरीके की कोशिश की है या यह सिर्फ अनुमान है?

— gnat

Answer 1

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

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

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

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

Comments

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

— स्पेंसर कोरमोस

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

— स्टीफन सी। स्टील

Answer 2

1. पैच फ़ाइल उत्पन्न करने के लिए 'svn diff' रन करने से पहले।
2. समीक्षक को पैच फ़ाइल भेजें जो इसे ट्रंक की एक स्वच्छ प्रतिलिपि पर लागू करता है।
3. समीक्षक पसंद के अंतर दर्शक का उपयोग करके परिवर्तनों पर जाता है।
4. समीक्षक निर्माण और परीक्षण चलाता है।
5. अगर सभी अच्छी तरह से डेवलपर को बता देते हैं तो वे अपने परिवर्तनों की जांच कर सकते हैं। यदि
   समस्याएं हैं तो डेवलपर चरण 1 पर वापस जाता है।

Answer 3

वहाँ आदर्श दुनिया है, और फिर वहाँ असली दुनिया है।

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

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

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

Comments

साप्ताहिक समीक्षा विचार के लिए +1। मुझे यह एक कोशिश करनी पड़ सकती है

— जेमी टेलर

@JamieTaylor: ठीक है, यह थोड़ा समझौता है - जाहिर है, यदि आपके पास (और आपकी देव टीम) समय है, तो मैं इसके बजाय पूर्ण कोड समीक्षा की सिफारिश करूंगा। लेकिन यह टीम के भीतर ज्ञान साझा करने का एक अच्छा तरीका है।

— एमोस कारपेंटर

Answer 4

शाखाओं को ठीक काम करना चाहिए, उन्हें पूर्व नौकरी में समीक्षाओं का पूर्व-उपयोग करने के मेरे अनुभव के आधार पर।

_{वापस नोट करें, हम उत्पादन रिलीज उम्मीदवार कोड के लिए केवल महत्वपूर्ण पैच के लिए प्री-कमिट समीक्षाओं का उपयोग कर रहे थे, इसलिए बहुत अधिक शाखाएं नहीं थीं (नियमित बदलाव पोस्ट-कमिट समीक्षाओं के माध्यम से पारित किए गए थे)।}

चूंकि आप सभी परिवर्तनों के लिए पूर्व-समीक्षा समीक्षाओं का उपयोग करने जा रहे हैं, इसलिए आपको बड़ी मात्रा में शाखाओं का प्रबंधन करने की आवश्यकता हो सकती है। यदि आप डेवलपर से प्रति सप्ताह औसतन एक "समीक्षात्मक" परिवर्तन करने की उम्मीद करते हैं, तो आप टीम में हर डेवलपर के लिए हर साल लगभग 50 शाखाएँ समाप्त करेंगे। यदि आप काम के छोटे हिस्से का उपयोग कर रहे हैं - जैसे कि 1, 2, 3 ... दिन ले रहे हैं - 50 को 2, 3, 5 से गुणा करें ... तदनुसार।

यदि आप इसे सबसे अच्छा तरीका चाहते हैं, तो नीचे कुछ अन्य विचार हैं ।

1. अन्य टीम के सदस्यों के लिए आवश्यक समीक्षा ब्लॉक कोड में देरी होने पर मामलों को संभालना

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

_{तुलना के लिए, पोस्ट-कमिट समीक्षाओं में ये आवश्यकताएं बहुत अधिक आराम से हैं (मैं 2 सप्ताह की समय सीमा का उपयोग कर रहा हूं और 1 सप्ताह के बाद चिंता करना शुरू कर रहा हूं) - लेकिन चूंकि आप पूर्व-प्रतिबद्ध समीक्षाओं को लक्षित करते हैं, इसलिए यह संभवतः दिलचस्प नहीं है।}

2. समीक्षा किए गए कोड सबमिट करते समय टकराव को मर्ज करें

यदि समीक्षित कोड के लिए प्रतिबद्ध है तो किसी अन्य द्वारा किए गए विरोधाभासी बदलावों को रोक दिया जाता है, जबकि कोड समीक्षा के लिए इंतजार कर रहा था?

विकल्पों पर विचार करने के लिए कुछ कर रहे हैं

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

_{तुलना के लिए, पोस्ट-कमिट समीक्षाओं में उस तरह का कोई मुद्दा नहीं होगा (क्योंकि कोड के साथ ये सौदा जो पहले से ही परिभाषा में विलय हो चुका है) - लेकिन चूंकि आप पूर्व-प्रतिबद्ध समीक्षाओं को लक्षित करते हैं, यह संभवतः दिलचस्प नहीं है।}

3. लोड डेवलपर जो समीक्षा के लिए इंतजार कर रहा है

एक स्पष्ट नीति स्थापित करें कि क्या डेवलपर जिसने समीक्षा प्रस्तुत की है, उसे नए कार्य पर जाना चाहिए या कुछ और करना चाहिए (जैसे समीक्षा करने वाले का पीछा करना)।

_{तुलना के लिए, पोस्ट-कमेंट की समीक्षाओं में स्पष्ट नीति की आवश्यकता होती है (क्योंकि आपके द्वारा कोड किए जाने के बाद अगले कार्य के लिए आगे बढ़ना स्वाभाविक है और इस बात की समीक्षा करना कि समीक्षा की समय सीमा एक या दो सप्ताह है) - लेकिन जब से आप पूर्व-प्रतिबद्ध समीक्षाओं को लक्षित करते हैं, तो यह संभवतः है दिलचस्प नहीं।}

Answer 5

विकास के किसी भी हिस्से की समीक्षा की जरूरत होती है जो एक अलग शाखा में होना चाहिए। इसलिए, समीक्षा के लिए समय आने से पहले ही शाखा का अस्तित्व होना चाहिए। फिर कदम की जरूरत होगी:

1. समीक्षा
2. संशोधित (संभवतः)
3. पाश की समीक्षा करने के लिए (संभवतः)
4. ट्रंक में विलय

विलय मुश्किल सा है। शाखा जितनी लंबी स्वतंत्र रहेगी, उसे वापस ट्रंक में मिलाने में उतना ही मुश्किल होगा। (यह परीक्षण करना भी कठिन हो सकता है।)

क्रॉस-विलय एक संभव समाधान है। ट्रंक में विलय करने से पहले (चरण 4, या इससे भी पहले, चरण 3 या चरण 1 से पहले), ट्रंक को शाखा में मर्ज करें। डेवलपर इसे कर सकता है और इसका परीक्षण कर सकता है। फिर शाखा ट्रंक के साथ पकड़ती है और इसे ट्रंक में विलय करना आसान हो जाता है। ट्रंक में विलय करना आपके द्वारा सबसे अच्छा है, या जो भी ट्रंक का प्रभारी है।

कुछ लोग क्रॉस-मर्ज के बजाय रिबेट की कोशिश करते हैं। कुछ लोगों का तर्क है कि रिबास बुराई है। यह एक और बहस है।