सभी को क्या करना चाहिए: कोड की समीक्षा

Google कोड को इतना अच्छा बनाने वाली सबसे महत्वपूर्ण बात सरल है - कोड समीक्षा (इसके बाद CR)। Google केवल CR का उपयोग करने वाली कंपनी नहीं है। हर कोई जानता है कि यह एक अच्छा विचार है और कई डेवलपर्स इसे करते हैं। लेकिन मैंने ऐसी कोई बड़ी कंपनी नहीं देखी है जिसमें सीआर इतनी सक्षमता से लागू हो। Google पर, कोड की एक भी पंक्ति तब तक उत्पादन में नहीं जाती है जब तक कि यह एक सकारात्मक सीआर स्कोर प्राप्त न कर ले।

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

सीआर का उपयोग करने से आपको क्या मिलता है?

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

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

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

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

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

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

दूसरा सबसे महत्वपूर्ण नुकसान यह है कि लोगों को कुछ कहने की ज़रूरत महसूस होती है। आप जानते हैं कि लेखक ने कोड पर काम करने के लिए पर्याप्त समय और प्रयास किया है और ऐसा लगता है कि आपको अपनी राय व्यक्त करनी चाहिए।

नहीं, आपको नहीं करना चाहिए।

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



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

अतिरिक्त सामग्री:

• Google कोड की समीक्षा कैसे करता है
• कोड रिव्यू लाइक यू मीन इट