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

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

कोड समीक्षा रणनीतियाँ

यहां कुछ कारणों को ध्यान में रखते हुए कुछ रणनीतियों को ध्यान में रखा जाना चाहिए, जिन्हें आप (एक अनुचर के रूप में) पसंद नहीं करते हैं:

1. एक प्रश्न के रूप में आपत्ति को फिर से लिखें

• बुरा: "यह परिवर्तन XXX को असंभव बना देगा" (यह एक अतिशयोक्ति है; क्या यह वास्तव में असंभव है?)
  
• अच्छा: "हम आपके परिवर्तन के बाद XXX कैसे करेंगे?"

2. अतिशयोक्ति से बचें

बस अपनी चिंताओं को व्यक्त करें और अपने वांछित परिणाम प्राप्त करने में मदद करने के लिए प्रश्न पूछें।

• बुरा: "यह परिवर्तन उत्पादकता को नष्ट कर देगा।"
  
• अच्छा: “ऐसा लगता है कि X मौजूदा Y की तुलना में धीमा हो सकता है; "क्या आपने यह दिखाने के लिए माप लिया / डेटा एकत्र किया कि ऐसा नहीं है?"
  
• बेहतर (यदि आपके पास समय है): "अभी के लिए, मैं डेटा एकत्र कर रहा हूं। मैं यह सत्यापित करने का प्रयास करूंगा कि X, Y की तुलना में धीमा नहीं है। "
  
• यह भी अच्छा है: “यह परिवर्तन एक एकल O (n) चक्र को डबल-नेस्टेड O (n²) चक्र में बदलता है; क्या यह प्रदर्शन को प्रभावित करेगा? ”

3. अपने ऊपर दुर्भावनापूर्ण टिप्पणी छोड़ें

कुछ विचार आपके साथ सबसे अच्छे रखे जाते हैं। यदि आप विनम्रता से नहीं कह सकते, तो बेहतर है चुप रहें।

• बुरा: "मुझे लगता है कि यह एक बुरा बदलाव है जो सब कुछ बर्बाद कर देगा।"
  
• खराब: "क्या आप सुनिश्चित हैं कि सॉफ्टवेयर विकास आपके लिए सही कैरियर विकल्प है?"

4. सकारात्मक रूप से कार्य करें

हो सकता है कि आपके पास समस्या को हल करने के तरीके पर एक अलग विचार था? यदि आप सकारात्मक रूप से कार्य करते हैं, तो आप अंततः एक ऐसा समाधान पाएंगे जो किसी भी मूल विकल्प से बेहतर है।

• बुरा: "यह परिवर्तन बेकार है, मेरा संस्करण बेहतर है।"
  
• अच्छा: "मेरे पास इस जगह के लिए एक बदलाव भी है: शायद हम विचारों की तुलना और / या संयोजन कर सकते हैं।"
  
• यह भी अच्छा है। "मेरे काम में एक समान परिवर्तन है, लेकिन मैंने एक्स बनाने का फैसला किया, क्योंकि जेडजेडजेड; आपने वाई को क्यों चुना? "

5. याद रखें कि हर किसी का अनुभव अलग होता है।

अन्य सभी मामलों में, एक बिल्कुल सक्षम इंजीनियर कुछ वर्षों तक कुछ तथ्यों के बारे में नहीं जान सकता है जिन्हें आप सामान्य ज्ञान के रूप में लेते हैं। स्पष्ट बात कहने में कुछ भी गलत नहीं है, जब तक कि आप संरक्षण या दुर्भावना से नहीं करते।

• बुरा: "क्या आप नहीं देख सकते कि यह स्पष्ट रूप से गलत है?"
  
• अच्छा: "यह सच नहीं है क्योंकि यह एक शून्य सूचक अपवाद फेंकता है जब एक्स वाई है।"

6. जो स्पष्ट नहीं है उसकी जटिलता को कम मत करो

याद रखें कि चीजें जो आपके लिए स्पष्ट हैं वे सभी के लिए स्पष्ट नहीं हो सकती हैं। वैकल्पिक तरीकों का सुझाव देकर और उपयोगी उदाहरणों को इंगित करके, आप सभी को सिंक करने में मदद कर सकते हैं।

• बुरा: "क्यों न सिर्फ कुरूपता को कुचलने?"
  
• अच्छा: "यदि आप ग्नोसिस को कुचलते हैं, तो यह हिस्सा आसान हो सकता है (उदाहरण के लिए XXX देखें)।"

7. सम्मान

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

• बुरा: "यह एक बेवकूफ व्यक्ति द्वारा लिखा गया बेवकूफ कोड है।"
  
• अच्छा: “आपके इनपुट के लिए धन्यवाद। हालाँकि, इसे अपनाया नहीं जा सकता क्योंकि यह खड़ा है; कई समस्याएं हैं (जैसा कि ऊपर बताया गया है)। ”
  
• यह भी अच्छा है: “जैसा कि ऊपर कहा गया है, इस मुद्दे के साथ कई मुद्दे हैं। शायद वापस कदम और उपयोग परिदृश्यों के बारे में बात करते हैं? यह रास्ता खोजने में मदद करेगा। ”

8. अपनी उम्मीदों (और अपने समय का प्रबंधन)

यदि कमिट बहुत बड़ी है और उस पर जल्दी विचार नहीं किया जा सकता है, तो तुरंत यह कहना सामान्य है। फिर एक समाधान के लिए देखो।

• बुरा: "मैं इसे स्वीकार नहीं करता, यह बहुत बड़ा है।"
  
• इसके अलावा बुरा: जब तक यह गायब न हो जाए, तब तक कमिट को अनदेखा करें
  
• अच्छा: “क्या आप इसे छोटे-छोटे कामों में विभाजित कर सकते हैं? कोड समीक्षा के लिए मेरे पास बहुत अधिक समय नहीं है, लेकिन यह एक समीक्षा के लिए बहुत बड़ी / जटिल प्रतिबद्धता है। "

9. "कृपया" कहें (सौजन्य दिखाएं)

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

• "क्या आप किसी अन्य पूल अनुरोध में अंतराल में परिवर्तन का दस्तावेजीकरण कर सकते हैं?"
  
• "क्या आप इन चर परिभाषाओं को उन्हें पढ़ने में आसान बनाने के लिए संरेखित कर सकते हैं?"

10. बातचीत शुरू करें

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

योग्य और अनुभवी इंजीनियरों को भी यह कहने में सक्षम होना चाहिए, "मुझे समझ में नहीं आता कि मैं ऐसा क्यों नहीं करता।" यह समीक्षक की स्थिति पर हमला करने का निमंत्रण नहीं है, बल्कि ज्ञान के लिए एक ईमानदार खोज है।

सारांश

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