क्या मेरे सहयोगियों को स्रोत नियंत्रण प्रणाली से प्रत्येक अन्य कोड की समीक्षा करनी चाहिए?

Question

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

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

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

Answer 1

मैं हाँ कहूँगा!

इसके दो त्वरित कारण:

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

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

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

Answer 2

अगर कहा जाता है कि सहकर्मी अच्छी और रचनात्मक प्रतिक्रिया प्रदान करता है, तो यह एक शानदार बात है और आपको इसकी बहुत सराहना करनी चाहिए।

जब आप इसे लिखते हैं, तो ऐसा नहीं लगता कि यह कीड़े पकड़ेंगे । यह होगा आप बेहतर कोड लिखने में परिणाम क्योंकि आप जानते हैं कि दूसरों को इसे देखेंगे।

Answer 3

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

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

समय पहलू के बारे में, सिद्धांत यह है कि यह आपको समय बचाएगा। बाद के दोष अधिक महंगे पाए जाते हैं, वे तेजी से सिद्धांत को विफल करते हैं। सहकर्मी कोड समीक्षा काफी समस्याओं को पकड़ सकती है।

Comments

+1 पर सहमत हुए। सभी समीक्षा करने वाले एक व्यक्ति को टीम में बेचैनी हो सकती है। यह बुरी तरह से गलत हो सकता है और इसका उपयोग किया जा सकता है क्योंकि मेरा कोड आपके कोड से बेहतर है । यह एक टीमवर्क होना चाहिए।

— ऑड्रियस

@Andrius: उदास, मैं समझता हूं कि आपका क्या मतलब है।

— kizzx2

Answer 4

आपका सहयोगी एक मेहनती डेवलपर की तरह लगता है, आपको उसके उदाहरण का पालन करना चाहिए।

Answer 5

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

इस तरह की समीक्षा साप्ताहिक आधार पर बग को पकड़ने या चर्चा को आमंत्रित करती है। क्यूए करते समय समय बचाता है। चर्चा सर्वोत्तम प्रथाओं से एल्गोरिथ्म डिजाइन और अधिक तक होती है। इस मोर्चे की कुंजी यह है कि हर कोई इसे रचनात्मक मानता है।

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

Answer 6

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

IMHO अगर आपके कोड में कुछ गलत है, तो आपको इसे स्वीकार करना चाहिए और उनसे एक अच्छा कोड लिखना सीखना चाहिए

Answer 7

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

यह बहुत बुरा अभ्यास है । किसी दिन मुझे पता चला कि मजबूती के कारण मैं हर चीज पर कब्जा नहीं कर सकता। इसके विरूद्ध दूसरा तर्क यह है कि हर व्यक्ति गलत हो सकता है।

यह बेहतर है जब डेवलपर्स एक-दूसरे के कोड की समीक्षा करते हैं और अंतिम निर्णय लेने और दिशाओं को परिभाषित करने के लिए कोई अनुभवी होता है।

Answer 8

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

Answer 9

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

मुझे उम्मीद है कि आपके पास अधिक परिपक्व दर्शक होंगे।

Comments

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

— Joppe

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

— Geek

Answer 10

यह उद्योग में काफी मानक अभ्यास है। जिन कंपनियों में मैंने काम किया है, उनके पास बहुत कड़ी कोड समीक्षा दिशानिर्देश हैं। जब तक कोड की समीक्षा नहीं की गई थी, तब तक आप उसे प्रतिबद्ध नहीं होने देंगे।

अपमान मत करो, या देखा लग रहा है। इसे सुरक्षा जाल और सीखने के अनुभव के रूप में सोचें।

Answer 11

पिछली नौकरी में, वरिष्ठ डेवलपर ने सभी चेक-इन को देखा और समीक्षा की और मुझे अक्सर उत्कृष्ट प्रतिक्रिया मिली जिसने मुझे एक बेहतर डेवलपर बनाने में मदद की।

अपनी वर्तमान नौकरी में, मैं कई चेक-इन देखता हूं और तीन दिन पहले मुझे एक बग मिला और डेवलपर को सूचित किया।

यदि आप इसे गले लगाते हैं तो यह अभ्यास बिल्कुल कीड़े को पकड़ लेगा और आपकी पूरी टीम को बेहतर बना देगा।