धीरे-धीरे कोड समीक्षा कैसे शुरू करें?


26

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

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

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


मैंने इस प्रश्न पर पर्याप्त जोर नहीं दिया, लेकिन "धीरे-धीरे" यहाँ प्रमुख तत्व था। मुझे नहीं लगता कि 100% परिवर्तनों की समीक्षा करना संभव है। फिर भी यदि केवल एक भाग की समीक्षा की जाती है, तो कोई भाग कैसे चुन सकता है? बस "पसंदीदा परिवर्तन" चुनें? कुछ बेतरतीब? लीड चुनता है? यहाँ उत्तर बहुत अच्छे हैं, लेकिन मेरे दिमाग में "क्रमिक" भाग पर वास्तव में हिट नहीं हुआ।
फिलिप

जवाबों:


16

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

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

यह कठिन काम है।


38

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

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


10
"अरे, मैं इस डिज़ाइन से खुश नहीं हूं, क्या मुझे नेत्रगोलक का दूसरा सेट मिल सकता है?" एक महान पहला कदम है। ++
रबरडुक

4

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

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

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

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


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

4

क्या समीक्षाओं को पेश करने का एक अच्छा तरीका है?

आपकी टीम और समीक्षाओं से आपको मिलने वाले लाभों के आधार पर संभवतः कई अच्छे तरीके हैं, लेकिन किसी भी दृष्टिकोण में कुछ सामान्य विशेषताएं होंगी:

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

  • प्रक्रिया को परिभाषित करें: प्रक्रिया के माध्यम से उन लोगों को वॉक करें जिन्हें आप चाहते हैं कि वे कोड की समीक्षा करने, परिवर्तनों पर चर्चा करने, आदि का पालन करें, ताकि टीम के सभी लोगों को पता हो कि कैसे आगे बढ़ना है।

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

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

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

उपरोक्त सभी और टीम के सदस्यों की चिंताओं को समझाने के लिए एक किकऑफ बैठक आयोजित करके शुरू करें। ई-मेल के साथ पालन करें जो प्रक्रिया को दस्तावेज करता है।

मुझे टीम की बड़ी अनिच्छा का एहसास है, क्योंकि यह सिर्फ एक और चीज है, और बातचीत दर्दनाक हो सकती है।

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

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

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


-2

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

यह दृष्टिकोण काम करता है, लेकिन यह सही नहीं है।

अंतिम लक्ष्य कोड को मास्टर में वापस मर्ज करने या शाखा का विकास करने के लिए पुल अनुरोध का उपयोग करना होगा जहां कोड की प्रत्येक पंक्ति की समीक्षा की जानी है।


3
अपने ओवर (और वैध रूप से बहुत देर से) के बाद एक पुनरावृत्ति के दौरान उत्पन्न सभी कोड की समीक्षा करने के लिए हर किसी को घंटों तक बैठना हर किसी को कोड समीक्षा के विचार से नफरत करने का एक शानदार तरीका लगता है।
रबरडुक

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

7 की मेरी टीम ~ दो दर्जन से अधिक कोड की कई हजार लाइनों को प्रत्येक दो सप्ताह में जोड़ती / हटाती है / संशोधित करती है। एक पीआर की गुणवत्ता की समीक्षा में लगभग 15-60 मिनट लगते हैं। औसत पीआर 3-4 है। तो हाँ। अगर हम एक टीम के रूप में यह सब करते तो टीम में फैले 8 घंटे के बजाय 8 घंटे X 7 देव होते। मुझे आपकी जिद पर नाराजगी है कि हम कुछ गलत कर रहे हैं। हम सप्ताह में कई बार ठेस पर जाते हैं । क्या आप?
रबरडुक

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