आप अपनी टीम के साथ सहकर्मी कोड समीक्षा की संस्कृति को कैसे बढ़ावा देते हैं?

Question

ऐसे

• कोड समीक्षा से पहले चेक-इन (हार्ड लागू करने के लिए)
• मासिक कोड की समीक्षा सत्रों की आवश्यकता के रूप में हम कोशिश की है कई तरीके
(पक्ष ट्रैक, समय लेने वाली है, भी उच्च स्तर के लिए करते हैं) नि: शुल्क चक्र के साथ
• एक या दो devs changesets की समीक्षा के रूप में वे जुड़ जाते हैं (कम भागीदारी)

हम TFS का उपयोग करें और एपीआई का लाभ उठाने या एक कार्यप्रवाह कि साथियों के कोड की समीक्षा को बढ़ावा देने में मदद कर सकते हैं का निर्माण करने के लिए एक उपकरण लिख सकते हैं।

आप अपनी टीमों में सफल होने के लिए क्या पाया है?

मैं नकली और रिश्वत से ऊपर नहीं हूं और छड़ी पर गाजर पसंद करता हूं।

Answer 1

हमने कुछ चीजें अपनाई हैं जो कोड समीक्षाओं को और अधिक फायदेमंद बनाने में मदद करती हैं।

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

कई और, लेकिन शुरुआत करने के लिए एक अच्छी सूची!

संबंधित धागा: What is the best way to encourage communication in a team?

Answer 2

क्या आपने अपनी टीमों में सफल होने के लिए क्या पाया है? सबसे पहले:

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

अब:

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

Answer 3

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

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

Answer 4

आप इस प्रक्रिया के साथ कुछ करने के लिए देख रहे हैं, तो आप "कोड की समीक्षा में" राज्य शामिल करने के लिए अपने काम वस्तुओं के कार्यप्रवाह बदल सकते हैं। (यह एक वैकल्पिक या आवश्यक राज्य हो सकता है)

आपके पास कोड की समीक्षा करने के लिए कम से कम सभी आइटमों की सूची है। http://teamreview.codeplex.com/

Answer 5

बस एक डेटा बिंदु के रूप में, सॉफ्टवेयर सलाहकार फर्म मैं के लिए काम सामान्य विकास की प्रक्रिया के साथियों के कोड की समीक्षा हिस्सा बनाता है:

तुम भी codeplex पर TeamReview परियोजना पर एक नज़र हो सकता है। प्रत्येक पैच को मानक प्रारूप में, समीक्षा के लिए प्रोजेक्ट मेलिंग सूची में भेजा जाता है। पैच केवल तभी किया जा सकता है जब कोई इसे मंजूरी देता है।

मुझे लगता है कि यह अभ्यास हर जगह आदर्श होना चाहिए।

Answer 6

निम्नलिखित ने मेरी टीमों के लिए अच्छा काम किया।

1. कोड का प्रत्येक भाग 'का निर्माण' में जाने से पहले समीक्षा की गई।
2. समीक्षाएं सलाह प्रक्रिया (अन्य उत्तर में उल्लेख किया है), नहीं विरोधात्मक थे। उस से विचलन शिक्षा के अवसरों के रूप में माना जाता था।
3. हमारे पास स्रोत नियंत्रण से जुड़ा एक समीक्षा प्रणाली थी ताकि गैर अनुपालन की निगरानी की जा सके (अच्छी तरह से)।
4. समीक्षा प्रणाली ने हमें समीक्षाकर्ताओं और समीक्षाकर्ताओं के आंकड़े करने की अनुमति दी।
5. प्रति समीक्षा एक समीक्षाकर्ता, अक्सर एक 'वरिष्ठ' व्यक्ति के रूप में एक सहकर्मी।
6. साफ़ कोडिंग मानकों & अपेक्षाएं।
7. समीक्षा diffs संपूर्ण कोड नहीं - मौजूदा कोड को अलग करने से बचाता है।
8. कोड लेखक पहले उनके सामान की समीक्षा की उम्मीद थी और कहा कि सख्ती से लागू किया गया था। इसलिए हालांकि हमने अधिकांश भाग के लिए एक परामर्श प्रक्रिया को प्रोत्साहित किया, अगर कोडर ने दीवार पर कचरा फेंक दिया जो कि निर्माण नहीं करेगा, तो हमने इसे पीछे हटने के साथ फेंक दिया।
9. हम सब कुछ की समीक्षा की: कोड निर्मित, कोडिंग मानकों की जाँच की, नमूना इकाई परीक्षण की जाँच की है कि वे चलाने गया था देखने के लिए और आवश्यकताओं के माध्यम से भी चला गया।
10. टिप्पणियां डेटाबेस में दर्ज की गई थीं लेकिन हमने जोर दिया कि समीक्षा समीक्षा के माध्यम से केवल टिप्पणियों को छोड़ने के बजाय - और अक्सर मिसिनरप्रेटेड - बाद में। रिमोट डेवलपर्स के लिए फोन + चैट का प्रयोग करें।

महंगा लगता है? वास्तव में यह कम रखरखाव लागत में कई बार वापस भुगतान किया।

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