संक्षिप्त जवाब
क्या मुझे कोड स्वयं ठीक करना चाहिए?
नहीं।
क्या मुझे उन्हें समीक्षा प्रक्रिया पर प्रतिक्रिया देनी चाहिए और उन्हें मेरे निर्देशों के अनुसार सुधार करने देना चाहिए?
हाँ। आपके सुझावों के अनुसार , निर्देश नहीं । निर्देश ध्वनि भी आधिकारिक।
और यदि हां, तो मैं यह प्रतिक्रिया कैसे दूं, क्या मैं कुछ खाका दस्तावेज भरकर उन्हें भेज सकता हूं, या कोई ऐसा सॉफ्टवेयर है, जो मुझे कोड फाइलों के अंदर समस्याओं के साथ चीजों को चिह्नित करने में मदद करेगा जहां वे बाद में इसके लिए जांच कर सकते हैं? (मैं विजुअल स्टूडियो का उपयोग कर रहा हूं)।
प्रतिक्रिया देने के लिए एक उपकरण का उपयोग करें। आप Visual Studio का उपयोग कर सकते हैं।
लंबा जवाब
मैं विज़ुअल स्टूडियो का उपयोग करता था लेकिन मुझे लगातार अन्य डेवलपर्स से पूछना पड़ता था, "अरे क्या आप मुझे अपना काम भेज सकते हैं ताकि मैं इसकी समीक्षा कर सकूं?" मुझे यह पसंद नहीं आया और इसने वास्तव में कभी अच्छा काम नहीं किया। अब, मैं समीक्षा सहायक का उपयोग करता हूं क्योंकि मैं चेकइन को देखकर समीक्षा शुरू कर सकता हूं। मुझे किसी अन्य डेवलपर पर भरोसा करने की आवश्यकता नहीं है जो मुझे समीक्षा के लिए काम पर भेज रहा है। यह मुझे दोषों के रूप में वस्तुओं को चिह्नित करने में भी मदद करता है, या केवल लेखक द्वारा देखे जाने वाले आइटमों को चिह्नित करता है। यह हमारी टीम के लिए काम करता है क्योंकि एक बार जब हम एक समीक्षा शुरू करते हैं, तो यह समीक्षा बोर्ड में वहीं रहता है और अनुवाद में खो नहीं जाता है। यह विजुअल स्टूडियो के साथ एकीकृत है। जैसा कि मैंने उल्लेख किया, विज़ुअल स्टूडियो की अपनी मूल समीक्षा प्रक्रिया भी है, लेकिन मुझे लगता है कि इसकी सीमाएँ हैं और यह प्रक्रिया स्वाभाविक नहीं है; इसलिए, मैं समीक्षा सहायक का उपयोग करता हूं।
यह उपकरण आगे और पीछे की प्रक्रिया, चर्चा आदि में भी मदद करता है।
प्रक्रिया, कम या ज्यादा, निम्नानुसार है:
मैं कुछ समीक्षा करता हूं, फिर मैं इसे लेखक को भेजता हूं (आपके मामले में जूनियर देव)। वे परिवर्तन करते हैं और फिर वे इसे वापस भेजते हैं। मैं परिवर्तनों को देखता हूं और प्रतिक्रिया प्रदान करता हूं। यदि मैं परिवर्तनों के साथ अच्छा हूं, तो मैं समीक्षा बंद कर देता हूं। नहीं तो आगे-पीछे हो जाता है। कभी-कभी अगर बहुत आगे-पीछे होता है, तो मैं बस उनकी मेज पर चलूंगा और एक व्हाइटबोर्ड का उपयोग करूंगा - यह वास्तव में प्रक्रिया को तेज करता है।
कोड की समीक्षा एक संवेदनशील क्षेत्र है इसलिए शब्दों के चुनाव के साथ बहुत सावधान रहें। मैं कभी किसी को नहीं बताता
शब्द का खराब विकल्प
मैंने आपके कोड की समीक्षा की और कुछ आइटम हैं जिन्हें आपको बदलने की आवश्यकता है।
मैं इसके बजाय यह कहता हूं:
वरदान का बेहतर विकल्प
मैंने आपके कोड को देखा और मुझे कुछ मदद चाहिए। क्या आप कृपया मेरे द्वारा भेजे गए आइटमों की समीक्षा कर सकते हैं और देख सकते हैं कि क्या आप मेरे कुछ प्रश्नों को स्पष्ट कर सकते हैं?
यह लेखक को लगता है:
- मुझे मदद की ज़रूरत है ताकि वे एक रक्षात्मक मोड में न जाएं।
- ऐसा लगता है कि वे समीक्षक हैं, मैं नहीं। तकनीकी रूप से, चूंकि मैं उनसे एक और नज़र रखने और कुछ चीजों को बदलने के लिए कह रहा हूं, इसलिए वे समीक्षक की तरह हैं।
इन सरल शब्दों के विकल्पों ने मेरी बहुत मदद की है।
मैं कनिष्ठ देवों को कभी कम नहीं आंकता। मैंने कुछ वरिष्ठ डेवलपर्स (10 वर्ष से अधिक के अनुभव) के साथ काम किया है और वहां एक जूनियर सह-ऑप छात्र की तुलना में कोड खराब था। इसलिए सिर्फ इसलिए कि वे सीनियर हैं या जूनियर वे सभी महत्वपूर्ण नहीं हैं; उनका काम वास्तव में अनुभव के वर्षों की तुलना में जोर से बोलता है।
अक्सर, जूनियर देवों को प्रोत्साहित करने और उन्हें समीक्षाओं में भाग लेने के लिए, मैं उन्हें मेरे लिए समीक्षा करने के लिए कुछ भेजूंगा: कुछ वे समझ सकते हैं, कुछ वे चुनौतीपूर्ण पाएंगे लेकिन पूरी तरह से परे नहीं। मैं इसे नीचे जैसा शब्द दे सकता हूं:
क्या आप कृपया मेरे लिए कुछ कोड की समीक्षा कर सकते हैं क्योंकि मैं इसका पता नहीं लगा सकता।
यह मुझे फिर से बहुत मदद करता है। यह मदद करता है क्योंकि यह स्पष्ट रूप से दिखाता है कि मैं केवल वही नहीं हूं जो समीक्षा करता है, बल्कि वे समीक्षा भी करते हैं और वे प्रक्रिया का हिस्सा भी हैं। यह दिखाता है कि पूरा विचार अच्छा, साफ कोड बनाने और जरूरत पड़ने पर मदद मांगने का है। समीक्षा प्रक्रिया एक संस्कृति है इसलिए हमें वास्तव में इस पर काम करने की आवश्यकता है।
अब कुछ लोगों को यह चिंता हो सकती है कि यदि वे उपरोक्त कार्य करते हैं, तो जूनियर देवता सम्मान खो देंगे क्योंकि उन्होंने कुछ ऐसा किया जो आप नहीं कर सकते थे। लेकिन यह सच्चाई से बहुत दूर है: मदद माँगना विनम्रता दिखाता है। साथ ही ऐसी बहुत सी परिस्थितियाँ हैं जिनमें आप चमक सकते हैं। अंत में अगर वह आपका डर है, तो आपके पास आत्म-सम्मान के मुद्दे हैं। अंत में, शायद मैं वास्तव में यह नहीं जानता: मेरा मतलब है कि इन देवों में से कुछ के एल्गोरिदम उनके सिर में ताज़ा हैं क्योंकि उन्होंने अभी एक महीने पहले उनका अध्ययन किया था।
वैसे भी, जूनियर और समीक्षा पर वापस। आपको उनके चेहरों पर नज़र डालनी चाहिए जब वे इसका पता लगाते हैं और मुझे जवाब भेजते हैं। मैं फिर उन्हें बता सकता हूं, "ठीक है, मुझे बदलाव करने दें और यदि आप इससे खुश हैं, तो कृपया इस मुद्दे को बंद करें।"
वे मेरे काम को देखने की शक्ति के साथ भयानक महसूस करते हैं और कहते हैं: "हाँ, आपके परिवर्तन अच्छे हैं। मैंने इस मुद्दे को बंद कर दिया है।"
मैं कभी भी कोड को स्वयं ठीक नहीं करता क्योंकि:
- लेखक इससे सीख नहीं लेगा।
- यह मेरे जैसा है: "एक तरफ हटो, मैं तुम्हें दिखाता हूं कि यह कैसे किया जाता है। मेरा कोड तुमसे बेहतर है।"
- यही कारण है कि मैं? यह मेरे लिए और काम है।
लेकिन मैं लेखक की मदद करने के लिए अपनी टिप्पणियों में विचारों और कोड स्निपेट्स का सुझाव दूंगा। कृपया ध्यान दें कि कभी-कभी मेरी समीक्षा केवल लेखक से पूछती है कि मुझे उनके कोड की समझ नहीं है; उनके कोड में कुछ भी गलत नहीं हो सकता है। उन्हें चर नाम बदलने, टिप्पणी जोड़ने आदि की आवश्यकता हो सकती है। इस प्रकार, मुझे यह भी नहीं पता होगा कि उस मामले में क्या बदलना है; केवल वे ही करेंगे।
यदि आप समीक्षा करते रहते हैं, तो आप जल्दी या बाद में, टीम के प्रत्येक डेवलपर के ज्ञान के स्तर का वास्तव में अच्छा विचार रखेंगे। यह जानना वास्तव में उपयोगी है और आपको इसका लाभ उठाने और इसे दिलाने की आवश्यकता है। यहाँ बताया गया है कि: यदि मैं कुछ कोड की समीक्षा करता हूं और सुधार के लिए स्पष्ट क्षेत्र देखता हूं और मुझे पता है कि कोई अन्य डेवलपर उन्हें भी पकड़ सकता है, तो मैं उन्हें इसके बजाय समीक्षा करने के लिए प्राप्त करूंगा। कुछ ऐसा है "अरे, मुझे कुछ ऐसे क्षेत्र दिखाई देते हैं जिन्हें सुधारा जा सकता है। क्या आप कृपया इसकी अधिक विस्तार से समीक्षा कर सकते हैं और अपनी टिप्पणियाँ लेखक को भेज सकते हैं?" यह बहुत अच्छा काम करता है क्योंकि अब मेरे पास एक दूसरे के साथ काम करने वाले 2 अन्य देव हैं।
अगर मैं कुछ काम की समीक्षा कर रहा हूं और मैं कुछ ऐसा नोटिस करता हूं जिससे पूरी टीम को फायदा हो सकता है, तो मैं एक काल्पनिक परिदृश्य बनाऊंगा और एक बैठक में इस मुद्दे को समझाऊंगा। मैं परिदृश्य की व्याख्या करके शुरू करूंगा और सभी से पूछूंगा कि क्या वे इस मुद्दे को खोज सकते हैं या एक मुद्दा देख सकते हैं, उन्हें शामिल कर सकते हैं। सभी से सवाल पूछें। फिर अंत में एक बेहतर दृष्टिकोण प्रस्तुत करें। यदि किसी और के पास बेहतर दृष्टिकोण है, तो मैं उन्हें धन्यवाद देता हूं और टीम के सामने स्वीकार करता हूं कि उनका दृष्टिकोण बेहतर है। इससे पता चलता है कि मैं "मेरा रास्ता या राजमार्ग" व्यक्तित्व नहीं हूं। इसके अलावा, मैं कभी किसी के काम को नहीं खोलता और एक बैठक में मुद्दों को इंगित करना शुरू करता हूं, लेखक इसकी सराहना नहीं करेगा - चाहे मुझे लगता है कि मैं कितना अच्छा और हानिरहित हूं।
जब मैं समीक्षा करता हूं, तो मैं केवल अच्छे स्वच्छ कोड की तलाश नहीं करता हूं, बल्कि यह भी कि कोड क्या कर रहा है। यदि व्यवसाय की आवश्यकता है: यदि कोई कर्मचारी 10 वर्षों से अधिक समय से कंपनी के साथ है, तो उन्हें 5% की वृद्धि दें। अन्यथा, 2.5% । पहली चीज जो मैं जांचता हूं अगर वह वास्तव में ऐसा कर रही है। फिर मैं जांचता हूं कि क्या वह इसे साफ, सुसंगत और प्रदर्शनकारी तरीके से कर रहा है।
यदि मैं एक समीक्षा करता हूं, तो मैं इसका पालन करना सुनिश्चित करता हूं या कोई भी समीक्षा को गंभीरता से नहीं लेगा।
मैं वर्षों पहले किसी के साथ काम करता था जो एक समीक्षा करता था और देव प्रबंधक, और क्यूए प्रबंधक की प्रतिलिपि बनाता था, लेकिन दोनों प्रबंधक व्यावसायिक पृष्ठभूमि से आते थे या उन्हें विकास का बहुत कम अनुभव था। उन्हें प्रभावित करने के लिए ही उन्होंने ऐसा किया। किसी ने भी इसे पसंद नहीं किया और वह यह है कि जब मैंने खुद से कहा कि मैं कभी वह गलती नहीं करूंगा।
दूसरी चीज जो वह करते थे, वह प्रोग्रामिंग शैली पर आधारित थी और आश्वस्त थी कि उनकी शैली सबसे अच्छी है ("मेरी कुंगफू आपके बंदर शैली से बेहतर है ...")। मेरे लिए यह एक और सबक था: किसी समस्या को हल करने का हमेशा 1 से अधिक तरीका होता है।
आपके कुछ गिने-चुने सवालों के जवाब
1- क्या मुझे कोड खुद तय करना चाहिए?
नहीं, कृपया ऊपर बताए गए कारणों को देखें।
2- क्या मुझे उन्हें समीक्षा प्रक्रिया पर प्रतिक्रिया देनी चाहिए और उन्हें मेरे निर्देशों के अनुसार सुधार करने देना चाहिए?
हां, वाक्यों और एक टोन का उपयोग करने का प्रयास करें जो अनुकूल है लेकिन फिर भी ध्यान देने की आवश्यकता है। जितना हो सके उतना स्पष्ट रहें। राज्य को कोड के साथ समस्या क्या है, इसे कैसे सुधारें। बस इसे बदलने के लिए मत कहो। लेकिन कारण बताएं।
मैं यह फ़ीडबैक कैसे दूं, क्या मैं कुछ टेम्प्लेट डॉक्यूमेंट भरता हूं और उन्हें भेज देता हूं, या कुछ सॉफ्टवेयर है जो मुझे कोड फाइलों के अंदर समस्याओं के साथ चीजों को चिह्नित करने में मदद करेंगे जहां वे बाद में इसके लिए जांच कर सकते हैं? (मैं विजुअल स्टूडियो का उपयोग कर रहा हूं)।
जैसे मैंने कहा, आप मेरे द्वारा उपयोग किए जाने वाले उपकरण या किसी अन्य उपकरण का उपयोग कर सकते हैं। ईमेल या शब्द दस्तावेजों का उपयोग न करें क्योंकि वे खो जाते हैं और इसके बारे में जानकारी रखना मुश्किल है।
मैंने कोड की समीक्षा करने के बाद और फिक्स किया है, तो कुछ समय बीत चुका है और मैंने पिछले में समीक्षा की गई कोड के कुछ हिस्से बदल गए हैं, मैं पुन: समीक्षा प्रक्रिया कैसे करूं? क्या मुझे फिर से सभी कोड पुन: जांचने चाहिए?
अधिकतर मैं जो करता हूं वह डेल्टा (केवल परिवर्तन) की जांच करना है। लेकिन आपको यह सुनिश्चित करने के लिए समग्र तस्वीर की आवश्यकता है कि कुछ भी टूट न जाए और यह वास्तुकला का अनुसरण करता है।
अंतिम विचार
मुझे व्यक्तिगत रूप से लगता है कि शब्द "कोड समीक्षा" एक खराब विकल्प है और यह नहीं जानता कि यह कैसे शुरू हुआ। वे बहुत बेहतर और कम आधिकारिक शब्द चुन सकते थे।