सभी डेवलपर्स कोड समीक्षा करते हैं


13

मैं 7-8 डेवलपर्स टीम में एक सॉफ्टवेयर डेवलपर हूं। हम काफी समय से कोड की समीक्षा कर रहे हैं और समय के साथ कोड की गुणवत्ता में सुधार हुआ है।

हालांकि मैंने हाल ही में देखा कि कुछ डेवलपर्स को दूसरों की तुलना में अधिक कोड समीक्षा के लिए कहा जा रहा है। मुझे डर है कि उनके लचीले रवैये के कारण।

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

आप अपनी टीम में इस मुद्दे से कैसे निपटेंगे?

क्या आपने कोड समीक्षकों को चुनने के लिए नियम स्थापित किए हैं?

क्या आपको लगता है कि कोड समीक्षकों को उस समय के लिए पुरस्कृत किया जाना चाहिए जो वे (अच्छी) कोड समीक्षा कर रहे हैं? और उन्हें कैसे पुरस्कृत किया जाना चाहिए?

आपके उत्तर / विचारों के लिए धन्यवाद।


7
क्या आपने एक राउंड रॉबिन सिस्टम बनाने पर विचार किया है, जहां दोनों कोडर अंधेरे में बचे हैं कि कौन समीक्षा कर रहा है और समीक्षक अंधेरे में बचा है कि कोडर कौन है?
नील

1
मैंने नहीं किया है, लेकिन मुझे यह विचार पसंद है! धन्यवाद!
गुरिल्लामेगलोइस

1
प्रभारी कौन है और वे अपना काम क्यों नहीं करते हैं, जिसमें यह सुनिश्चित करना चाहिए कि बाकी सभी लोग अपना काम करें?
जेफ

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

जवाबों:


12

हम समीक्षक नहीं चुनते हैं।

हमारी टीम में:

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

कोड समीक्षा असाइन नहीं की गई हैं, जब लोग उनके लिए काम करते हैं तो उन्हें उठा लेते हैं। समझ यह है कि हम पाइपलाइन के माध्यम से कहानियों को आगे नहीं बढ़ा सकते हैं। इस अवसर पर कोई उल्लेख करेगा कि वे स्टैंडअप में सीआर का इंतजार कर रहे हैं, लेकिन इसके बारे में है।

मुझे यह मॉडल पसंद है, यह लोगों को वह लेने के लिए देता है जो वे कर सकते हैं और "लोगों को नौकरी देने" से बचते हैं।


6

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

से संबंधित,

क्या आपको लगता है कि कोड समीक्षकों को उस समय के लिए पुरस्कृत किया जाना चाहिए जो वे (अच्छी) कोड समीक्षा कर रहे हैं?

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


2
यह एक दिलचस्प विचार है, लेकिन बहुत बार जब एक बग सामने आता है, तो 90% काम यह पता लगाता है कि बग क्या है, और 10% काम इसे ठीक कर रहा है। पोस्टमार्टम करने से पता चलता है कि बग की शुरुआत में क्या बदलाव आया है, जब तक कि यह पता नहीं चल जाता है कि क्या हो रहा है, या कैसे एक सुरक्षित समाधान करना है।
डेवग

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

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

5
यह उत्तर मानता है कि कोड समीक्षाओं के लिए लक्ष्य बग ढूंढना है। ऐसा नहीं है, प्राथमिक लक्ष्य कोड को बनाए रखने योग्य और बेकार स्थिति में रखना है (और यदि आप भाग्यशाली हैं, तो कुछ कीड़े भी पाए जाते हैं)।
डॉक ब्राउन

@DocBrown बग को रोकने के लिए और यह भी सुनिश्चित करने के लिए कि बग का भविष्य तय करना तेज होगा (कोड के साथ अन्य डेवलपर को परिचित करके और यह सुनिश्चित करके कि कोड अच्छी तरह से लिखा गया है)
अधिकतम

4

आपके पास मुख्य समस्या तकनीकी नहीं है, लेकिन कुछ उपकरण प्रयास की मात्रा को कम कर सकते हैं जो कोड समीक्षा करते हैं। दूर करने के लिए कुछ चुनौतियां हैं:

  • समझ क्या परिवर्तन है। सुविधा शाखाओं पर गिट पुल अनुरोध वास्तव में इस प्रक्रिया में मदद करते हैं।
  • कोड को एक घटना की समीक्षा करना जहां लोगों को एक ही कमरे में होना है। यह शेड्यूलिंग, मीटिंग रिसोर्सेज, आदि GitHub, GitLab, और BitBucket के तनाव को जोड़ता है, अतुल्यकालिक समीक्षाओं की अनुमति देता है ताकि वे सहकर्मी के तैयार होने पर हो सकें।
  • कोड को देखते समय सार्थक प्रतिक्रिया प्रदान करने की क्षमता। ईमानदार होने के लिए, GitHub, GitLab, Bitbucket पुल अनुरोधों में लाइन-बाय-लाइन टिप्पणी सुविधा वास्तव में एक आमने-सामने की बैठक से अधिक उपयोगी है। यह कम राजनीतिक लगता है।

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

टूलींग के बाहर, आपको अधिक सामाजिक चुनौतियों को देखने की जरूरत है:

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

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


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

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

2

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

जाहिर है कि कभी-कभी अवकाश जैसे अपवाद होंगे जहां चोटियां और कुंड होंगे।

जूनियर्स और सीनियर्स / लीड्स के बीच कोई अंतर नहीं होना चाहिए। कोड की समीक्षा सभी के कोड के लिए की जानी चाहिए - चाहे वे कितने भी वरिष्ठ हों। यह घर्षण को कम करता है और विभिन्न दृष्टिकोणों को साझा करने में मदद करता है।

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

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


0

ऐसा लगता है कि टीम को कोड समीक्षाओं के लिए एक औपचारिक प्रक्रिया का अभाव है।

मैं एक 350 पृष्ठ वर्ड दस्तावेज़ बनाने के बारे में बात नहीं कर रहा हूँ, लेकिन प्रक्रिया क्या होती है, इस पर सिर्फ कुछ सरल बुलेट बिंदु।

महत्वपूर्ण बिट्स:

  1. समीक्षकों के एक कोर सेट को परिभाषित करें। कोई सामान्य कथन नहीं। लोगों के नाम बताइए।

    ये आपके वरिष्ठ डेवलपर्स होने चाहिए।

  2. समीक्षा पर हस्ताक्षर करने के लिए 1 से अधिक कोर समीक्षक की आवश्यकता होती है।

  3. प्रत्येक स्प्रिंट या रिलीज़ को कम से कम 1 अन्य गैर कोर समीक्षक पहचानें जो एक अस्थायी कोर समीक्षक है। इस समय के दौरान सभी कोड समीक्षाओं पर उनके साइन ऑफ की आवश्यकता होती है।

आइटम # 3 कोर समीक्षक समूह को अन्य देवों को घुमाने की अनुमति देता है। कुछ सप्ताह वे दूसरों की तुलना में समीक्षाओं पर अधिक समय बिताएंगे। यह एक संतुलनकारी कार्य है।

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

जब संदेह होता है, तो प्रक्रिया को परिभाषित करें और टीम को बताएं कि उन्हें इससे चिपके रहने की जरूरत है।

और एक आखिरी चीज है जिसे आप कोशिश कर सकते हैं - विवादास्पद जैसा कि यह हो सकता है: यदि मैं एक मुहावरे का उपयोग कर सकता हूं, तो @ # $% प्रशंसक को मार दें।

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

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

कभी-कभी आपको सिर्फ टाइटैनिक को बर्फ की चपेट में आने देना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.