कोड रिव्यू कब करें

Question

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

हम वीएस और टीएफएस 2010 का उपयोग कर रहे हैं और हम 6 की टीम हैं।

हम वर्तमान में सुविधाओं के लिए शाखा करते हैं लेकिन स्क्रैम के लिए शाखा में बदलने पर काम कर रहे हैं।

हम वर्तमान में अलमारियों का उपयोग नहीं करते हैं और अन्य तकनीकों के उपलब्ध होने पर वास्तव में लागू नहीं करना चाहते हैं।

आप अनुशंसा करते हैं कि हम प्रति उपयोगकर्ता कहानी पर कोड समीक्षा कैसे लागू करें?

Answer 1

यह उपयोगकर्ता की कहानियों की प्रकृति पर निर्भर करता है।

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

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

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

स्प्रिंट के अंत में आप अपनी देव शाखा को एकीकरण / उत्पादन आदि में मिला देते हैं।

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

Answer 2

कोड की समीक्षा करने का सबसे प्रभावी तरीका है कि आप खड़े हों, किसी को खोजें, और उन्हें अपने ऊपर आने वाले कोड पर चर्चा करने के लिए कहें।

जब तक आप किसी को अपने कोड की स्थानीय स्तर पर समीक्षा करने के लिए नहीं पा सकते, तब तक किसी उपकरण का उपयोग न करें।

आप पूरी तरह से जोड़कर कोड समीक्षाओं से बच सकते हैं।

Comments

मैं सोच रहा था कि कब कोई जोड़ी बनाने का जिक्र करेगा। उस और इकाई परीक्षण के बीच आपको बहुत समीक्षा मिलती है।

— 21:39 पर जेएफओ

मैंने इसे "खड़े हो जाओ, किसी को आग लगाओ, और अपने ऊपर आने वाले कोड पर चर्चा करने के लिए कहा"। मेरा दिन बनाने के लिए धन्यवाद।

— मॉर्गन

Answer 3

क्या टीम में सभी लोग स्थानीय हैं? यदि हां, तो किसी को कोड में चेक करने से पहले एक बार आने के लिए कहें और स्थानीय नहीं। अपने पसंदीदा स्क्रीन-शेयरिंग प्रोग्राम को फायर करें और किसी को कॉल करें। मैं व्यक्तिगत रूप से अक्सर ऐसा करता हूं। कभी-कभी मैं सिर्फ यह कहने के लिए "अरे, देखो मैंने क्या किया!"

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

Answer 4

मेरा मानना ​​है कि कोड की समीक्षा SCRUM का औपचारिक हिस्सा नहीं है, फिर भी गुणवत्ता हासिल करने और अपनी परियोजनाओं / टीम को बेहतर बनाने के लिए संशोधन एक स्वतंत्र रणनीति है।

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

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

इसलिए, आपके प्रश्न का उत्तर देने के लिए, मेरा मानना ​​है कि आप SCRUM से बहुत अधिक पुश करने का प्रयास कर रहे हैं, और आपको केवल संशोधन के बारे में बेहतर विचार करना चाहिए।

Comments

स्क्रम अनुसूची के संबंध में कुछ भी नहीं कहता या सलाह नहीं देता है। यह आपको नियमित आधार पर मूल्य प्रदान करने की उम्मीद करता है। यह ऐसे क्षण भी प्रदान करता है जिसमें आप अपनी प्रक्रिया का निरीक्षण और अनुकूलन कर सकते हैं ताकि बेहतर हो (बेहतर जरूरी नहीं कि इसका अर्थ तेजी से हो)।

— रयान क्रॉमवेल

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

— रॉन-डेमन

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

— रॉन-डेमन

एक तरफ अनुबंध, स्क्रम टीम मूल्य नहीं सेवाएं प्रदान करते हैं। हम उस मूल्य को वितरित करने के साधन के रूप में विकसित / कार्यक्रम करते हैं।

— रयान क्रॉमवेल

मुझे विश्वास नहीं है कि आप शब्द "मूल्य" और "सेवा" मित्र को अलग कर सकते हैं। मेरा यह भी मानना ​​है कि यह अब बहुत ही विषय है।

— रॉन-डेमन

Answer 5

क्या आपके कोड में जाँच करने से पहले कोड समीक्षा करना स्पष्ट नहीं है?

टीएफएस जीआईटी की तरह काम नहीं करता है, इसलिए जब भी आप किसी शाखा या ट्रंक में कोड की जांच करते हैं, तो यह सभी के लिए उपलब्ध होता है।

इसका मतलब यह है कि समीक्षा चेक-इन पर होनी चाहिए ताकि बुरे लोग कॉपी कार्य करने वाले प्रत्येक व्यक्ति के लिए प्रचारित न हों।

Comments

मुझे लगता है कि, सामान्य तौर पर, इकाई परीक्षण ऐसे होते हैं जो बुरे बदलावों को रोकते हैं।

— जॉन सॉन्डर्स

@ जॉन सौन्डर्स: एक अन्य प्रकार के यूनिट टेस्ट के रूप में कोड समीक्षाओं पर विचार करें।

— गिल्बर्ट ले ब्लैंक

@ गिल्बर्ट: मैं ऐसा कर सकता था, लेकिन फिर मुझे प्रतिगमन परीक्षण के लिए उनका लाभ नहीं मिला। मैं अधिक और बेहतर इकाई परीक्षण लिखने पर समय बिताना पसंद करूँगा।

— जॉन सॉन्डर्स

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

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

— जॉन सॉन्डर्स