कुशलतापूर्वक कोड समीक्षा की निगरानी कैसे करें?


28

मुझे अपनी टीम में प्रमुख कोड समीक्षा कवर पर संदेह है। बहुत सी कोड समीक्षाएं बिना किसी टिप्पणी के मर्ज हो जाती हैं।

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

मैं एक टीम के रूप में कैसे सही तरीके से मॉनिटर कर सकता हूं कि मेरी टीम एक उचित कोड समीक्षा प्रक्रिया कर रही है और मैं उन्हें प्रक्रिया के लाभों को अधिकतम करने में कैसे मदद कर सकता हूं?

अद्यतन करें

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

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

इसलिए मैंने कॉपी पेस्ट का पता लगाने के लिए "jscpd" नाम से एक लाइब्रेरी जोड़ी। कॉपी पेस्ट पर निर्माण विफल रहा। कि एक समस्या को तुरंत समाप्त कर दिया।

अगले हम codec की कोशिश करने जा रहे हैं।

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

सामान्य तौर पर ऐसा लगता है कि हम सही दिशा में आगे बढ़ रहे हैं।


1
यदि आप TFS का उपयोग कर रहे हैं, तो आप कोड समीक्षक का नाम शामिल करने के लिए इसे कॉन्फ़िगर कर सकते हैं।
कृष्णन्दु सरकार


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

3
क्या आप इनमें से किसी भी समीक्षा में भाग लेते हैं? शायद यह एक पर ड्रॉप करने का समय है? कुछ बातें खुद बताएं और प्रत्येक समीक्षक से व्यक्तिगत रूप से पूछें कि वह उन सभी से क्यों चूक गया?
मग

2
क्या आप पाते हैं कि समीक्षा द्वारा स्पष्ट समस्याओं को नहीं देखा गया है? क्या आपने (महत्वपूर्ण) टिप्पणियां जोड़ी होंगी?
usr

जवाबों:


70

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

लेकिन मेरे अनुभव में, मुझे संदेह है कि कुछ और चल रहा है।

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

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

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

एक टूटी हुई प्रक्रिया के शीर्ष पर एक उपकरण को मजबूर करने से प्रक्रिया बेहतर नहीं होगी।


5
इस (और कई अन्य!) समस्या के लिए सही दृष्टिकोण के लिए +1
ओलिवियर दुलक

7
अंतिम वाक्य के लिए +1। यह एक ऐसी चीज है जिसे लगभग कोई नहीं समझता है, लेकिन बेहद महत्वपूर्ण है।
जॉनएय

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

43

मुझे एक-पंक्ति के उत्तर पोस्ट करना पसंद है, लेकिन यह एक उचित लगता है:

प्रक्रिया में भाग लें।


15
मैं एक पंक्ति के उत्तर को भी नापसंद करता हूं। सौभाग्य से आपने दो लाइनें लीं - और मेरा उत्तर। +1
मग

1
मैं हूँ। लेकिन जब मैं नहीं हूँ .. सामान होता है। यह वही है जिसने मुझे पहली बार में संदिग्ध बना दिया है। मैंने दूसरे की समीक्षा फिर से शुरू की, और पता चला कि गंदा सामान है।
लड़का मोगरबाई

6

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


2

कुछ चीजें (ईमानदार होने के लिए, इनमें से अधिकांश उत्तर में शामिल हैं, लेकिन मैं उन्हें एक ही स्थान पर रखना चाहता था)

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

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

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

  • स्वचालित कोड-जाँच सॉफ़्टवेयर का उपयोग करें जैसे सोनारक्बी ताकि कोड-समीक्षाएं असंगत-कोड, तर्क त्रुटियों, दस्तावेज़ीकरण की कमी आदि जैसे मुद्दों पर ध्यान केंद्रित कर सकें, जिन्हें स्वचालित रूप से देखा नहीं जा सकता है।


2

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

  • जांचें कि कोड वह करता है जो उसे करना चाहिए यानी वह आवश्यकताओं को पूरा करता है

  • कोड शैली यह सुनिश्चित करने के लिए कि डेवलपर्स एक सुसंगत शैली के लिए कोडिंग कर रहे हैं

  • अनुकूलन जैसे फ़ंक्शन कॉल की संख्या

  • वास्तुकला और पुन: प्रयोज्यता

  • अपवाद हैंडलिंग और लॉगिंग

  • तकनीकी ऋण: एक बेहतर स्थिति में कोड है जब डेवलपर ने इस पर काम करना शुरू किया था

  • कोड देखें और बनाएं (मुझे यह उपयोगी लगता है लेकिन मेरी टीम के अन्य देवता इसे परीक्षकों को छोड़ना पसंद करते हैं)

  • एक स्वचालित उपकरण का उपयोग करना (मैंने सोनारक्यूब का उपयोग किया है )। मुझे अपनी बिल्ड प्रक्रिया में इसे एकीकृत करने के लिए उपयोगी बनाना चाहिए ताकि कोड में सुधार को लागू किया जा सके जैसे टेस्ट कवरेज बढ़ाना

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

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

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


क्या यह सोनारक्यूब का विज्ञापन है? मैंने इसे आजमाया - मैं इसकी सिफारिश नहीं करूँगा, जहाँ तक जाने के लिए बहुत दर्दनाक है और सभी उपयोगी बिट्स के लिए "ओपन सोर्स" लागत है।
gbjbaanb

यह मेरी वर्तमान टीम में ठीक चल रहा है और इसे सेटअप करना बहुत मुश्किल नहीं था और यह मदद कर रहा है - यह एक विज्ञापन नहीं है लेकिन यह इस तरह का एकमात्र उपकरण है जिसका मुझे अनुभव है। क्या आप Redmine कोडरेव और रिव्यूबर्ड के लिए भी ऐसा ही कहेंगे?
br3w5

हम अपनी टीमों में सोनारक्यूब का उपयोग कर रहे हैं, लगभग 70+ परियोजनाओं की सेवा कर रहे हैं, 10k से 3M LOC तक। हालांकि कुछ टीमें सिर्फ इसकी रिपोर्ट को नजरअंदाज करती हैं, ज्यादातर इसका इस्तेमाल रीफैक्टरिंग प्रक्रियाओं को निर्देशित करने के लिए करती हैं। यह अच्छा काम करता है, हालांकि व्यक्तिगत रूप से मैं सरल, गैर-एकीकृत उपकरण पसंद करता हूं, जैसे कि फाइंडबग्स।
डिबेके

और यहाँ मैं सोच रहा था कि कोड की जाँच में यह जाँच शामिल है कि क्या कोड डिज़ाइन दस्तावेज़ से मेल खाता है: - /
Mawg

1
धन्यवाद, यह मैं इस बीच कर रहा हूं। मैं कुछ हफ़्ते के भीतर अपडेट कर दूंगा कि यह कैसे प्रभावित हुआ।
आदमी मोगरबी

0

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

सबसे पहले, मैं आपसे एक प्रश्न करता हूं। क्या आप एक संस्करण नियंत्रण प्रणाली (जैसे मर्क्यूरियल, गिट) का उपयोग कर रहे हैं?

अगर आपका जवाब हां है, तो आगे बढ़ें।

  1. निषेध हर कोई मास्टर शाखा (ट्रंक) के लिए कुछ भी (यहां तक कि छोटे फिक्स) सीधे धकेलने से *
  2. अलग-अलग शाखाओं में नई सुविधाएँ (या सुधार) विकसित करें
  3. जब डेवलपर्स का मानना ​​है कि शाखा मास्टर में एकीकृत होने के लिए तैयार है, तो वे "पुल अनुरोध" बनाएंगे
  4. निषेध हर कोई अपने खुद के पुल अनुरोध विलय से *
  5. किसी अन्य डेवलपर ने पुल अनुरोध का मूल्यांकन किया और नए कोड की समीक्षा की
  6. यदि कोड समीक्षा पास करता है, तो अच्छा है, पुल अनुरोध को मर्ज किया जा सकता है, अन्यथा सुधार लागू किए जा सकते हैं
  7. चरण 6 को तब तक दोहराएं जब तक कोड पर्याप्त न हो जाए (शुरू किए बिना किया जा सकता है) **
  8. किया, आपके सभी नए कोड की समीक्षा की जाती है (कम से कम संक्षेप में), किसी के नाम से

अब आपके पास अपने वर्कफ़्लो में एक सटीक बिंदु है जहां कोड समीक्षा हो जाती है।

वहां कार्य करें।

* सर्वर-साइड हुक के साथ, स्वचालित रूप से लागू किया जा सकता है

** यह प्रक्रिया पूरी तरह से GitHub (दूसरों के बीच) द्वारा समर्थित है, और इसका उपयोग करना काफी आसान है, इसे देखें


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

1
@ Pa @loEbermann मैं देख रहा हूं। मुझे डर है कि परिस्थितियों का एक अपरिहार्य परिणाम है, अगर आपके पास सब कुछ करने के लिए पर्याप्त समय नहीं है, तो गुणवत्ता को नुकसान होगा, एक ही रास्ता या कोई अन्य। शील, अगर यह "कभी-कभी" काम नहीं करता है, तो इसका मतलब है कि यह "अधिकांश समय" काम करता है, नहीं?
एगोस्टिनो

1
हां, इसने केवल सीमित लोगों के लिए मर्ज की अनुमति देकर थोड़ी मदद की, जिनके पास यह जांचने का कार्य था कि क्या वास्तविक समीक्षा सही थी।
पाओलो एबरमन

मेरे पास एक समान निषेध था, और कहने की ज़रूरत नहीं थी: विकास लगभग बंद हो गया। यह नियम पूरे 2 सप्ताह तक चला, जिसके बाद प्रबंधकों को अपनी योजनाओं को समायोजित करना पड़ा।
B50овиЈ

@ B onовиЈ आपकी टीम नियमित रूप से पहले कोड की समीक्षा कर रही थी ? इस तकनीक का उपयोग कई लोग करते हैं, खासकर ओपन सोर्स इकोसिस्टम में। यह तथ्य कि यह आपकी टीम के लिए काम नहीं करता है, इसका मतलब यह नहीं है कि यदि आप दूसरों के लिए काम नहीं कर सकते हैं।
अगस्टिनो

-2

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

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