कोड समीक्षा टर्मिनेटर। समीक्षा करें जिसके लिए आपको धन्यवाद दिया जाएगा


अदरक मुझे कोड की समीक्षा करने में मदद करता है। और जब वह कुछ पसंद नहीं करता है - एक वास्तविक टर्मिनेटर,

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

काम के परिवर्तन के बाद, सहकर्मियों को भी बदल दिया। लेकिन एक नई जगह में, वे भी समीक्षा के लिए धन्यवाद करने लगे। मैंने यह पता लगाने का फैसला किया कि क्यों, और इसे अलमारियों पर रख दिया। यह 11 सिफारिशें निकलीं।

1. समीक्षा को मुख्य गतिविधियों में से एक मानें


"और फिर पर्याप्त शून्य जाँच नहीं है" जैसी कुछ टिप्पणियों को छोड़ देना पर्याप्त नहीं है। यह आवश्यक है:

  • यह पता लगाने के लिए कि क्या किया जाना चाहिए
  • समझें कि यह कैसे किया गया था
  • . ( , , )?
  • , , . — , .

2.


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

आपका सहकर्मी आपके इरादों को गलत समझ सकता है - और इससे आक्रोश, टीम में तनाव और आम तौर पर बेकार हो जाता है।

अपने जीवन को आसान बनाएं: वाक्यांश को नरम करें, इसे एक प्रश्न में बदल दें, या शायद एक स्माइली चेहरा जोड़ें।



3. समय आवंटित करें


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

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

4. धारणा मत बनाओ; पूछना


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



5. ऐसी स्थितियों को पकड़ें जब आपको सीधे संपर्क करने की आवश्यकता हो


आमतौर पर, समीक्षा एसिंक्रोनस रूप से की जाती है। इसलिए आप अपने आप को कोड में डुबो सकते हैं और अपने सहयोगी को कम विचलित कर सकते हैं। लेकिन कुछ स्थितियों में, सीधे संपर्क करना बेहतर होता है (ऊपर जाकर या कॉल करके):

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

खैर, समीक्षा प्रणाली में वार्तालाप सारांश जोड़ना एक अच्छा विचार है।

6. पहले टिकट पढ़ें


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



7. अपने सुझावों को सही ठहराएं


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

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

8. अच्छे फैसलों की प्रशंसा करें


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



9. विनम्र बनो


संकेत: " क्या हम कृपया मस्तिष्क-क्षतिग्रस्त बेवकूफ नेटवर्किंग टिप्पणी वाक्यविन्यास शैली से छुटकारा पा सकते हैं? " शिष्टाचार के लिए, "कृपया") जोड़ने के लिए एक निश्चित प्रकार की टिप्पणियां।



10. मदद


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

11. सुझाव दें, संकेत न करें


जब आप समीक्षा के लिए एक अलग दृष्टिकोण प्रस्तावित करते हैं - तो अपने विकल्प का उपयोग करने के लिए, अपने सहकर्मी को न बताएं। तर्क और अपने सहयोगी को निर्णय लेने दें। सबसे अधिक संभावना है, वह आपकी सलाह लेगा। और यदि नहीं, तो इसका क्या कारण हो सकता है?

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



बस इतना ही। संक्षेप:

अपने आसपास की दुनिया को थोड़ा बेहतर बनाएं। अच्छी समीक्षा करें।



युपीडी। यह लेख अंग्रेजी में मेरे मूल का एक नि: शुल्क अनुवाद है "अनुवाद" से "लेख" में परिवर्तित किया ताकि पाठकों को भ्रमित न किया जा सके।

All Articles