सहकर्मी / कोड समीक्षा कुंठाएं

Question

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

इसे प्राप्त करने के लिए, मैंने अपनी टीम को सहकर्मी समीक्षा की अवधारणा से परिचित कराया है। मथ के लिए गिथब पुल-अनुरोध में दो अंगूठे। महान - लेकिन हिचकी के बिना मेरी राय में नहीं।

मैं अक्सर एक ही सहकर्मी की सहकर्मी समीक्षा टिप्पणियां देखता हूं जैसे -

• के बाद एक स्थान जोड़ने के लिए अच्छा होगा <INSERT SOMETHING HERE>
• विधियों के बीच अवांछित लाइन
• पूर्ण विराम का उपयोग डॉकब्लॉक में टिप्पणियों के अंत में किया जाना चाहिए।

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

• आप द्वारा चक्रवाती जटिलता को कम कर सकते हैं ...
• जल्दी बाहर निकलें और अगर / से बचें
• अपनी DB क्वेरी को एक रिपॉजिटरी में सार करें
• यह तर्क वास्तव में यहाँ नहीं है
• अपने आप को दोहराना नहीं है - अमूर्त और पुन: उपयोग
• यदि Xविधि के तर्क के रूप में पारित किया गया तो क्या होगा Y?
• इसके लिए इकाई परीक्षण कहाँ है?

मुझे लगता है कि यह हमेशा उसी तरह के लोग हैं जो कॉस्मेटिक प्रकार की समीक्षा देते हैं, और उसी प्रकार के लोग जो मेरी राय में "गुणवत्ता और तर्क आधारित" सहकर्मी समीक्षा देते हैं।

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

यदि मैं सही हूं - तो मैं कॉस्मेटिक टच-अप के सुझाव के साथ सहकर्मियों को वास्तव में कोड में दोषों को देखने के लिए प्रोत्साहित करने के बारे में कैसे जाऊंगा?

अगर मैं गलत हूं - कृपया मुझे बताएं। क्या वास्तव में एक अच्छे कोड की समीक्षा के लिए अंगूठे के कोई नियम हैं? क्या मैं इस बात से चूक गया कि कोड समीक्षाएँ क्या हैं?

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

जब मैं कोड की समीक्षा करता हूं, तो मैं शायद 500-500 मिनट प्रति 500 ​​लोको के बीच खर्च करता हूं। मैं इन उथले समीक्षाओं की कभी भी 10 मिनट से अधिक समय तक कल्पना नहीं कर सकता अगर यह समीक्षा की गहराई है जो वे प्रदर्शन कर रहे हैं। इसके अलावा, उथले समीक्षक से अंगूठे का मूल्य कितना है? निश्चित रूप से इसका मतलब है कि सभी अंगूठे समान वजन के नहीं हैं और शायद 2-पास की समीक्षा प्रक्रिया होने की आवश्यकता है। गहन समीक्षा के लिए एक अंगूठा और "चमकाने" के लिए दूसरा अंगूठा?

Comments

क्या आपने उस व्यक्ति का उल्लेख करने की कोशिश की है?

— ब्रायन ओकले

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

— ब्रायन ओकले

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

— रॉबर्ट हार्वे

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

— जूलिनरॉज

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

— कनाडाई कोडर

Answer 1

समीक्षाओं के प्रकार

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

समीक्षकों के प्रकार

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

सहकर्मी समीक्षा सहयोग है, टैग का खेल नहीं है

मुझे यकीन नहीं है कि आपको यह बताने का अधिकार है कि उन्हें अपना काम कैसे करना है। जब तक आप निश्चित रूप से नहीं जानते हैं, तब तक यह मान लें कि यह व्यक्ति उस तरह से योगदान करने की कोशिश कर रहा है जैसा वह फिट देखता है। हालाँकि, यदि आप सुधार के लिए कमरा देखते हैं, या संदेह करते हैं, तो वे समझ नहीं पाते हैं कि सहकर्मी की समीक्षा में क्या अपेक्षित है, उनसे बात करें ।

एक सहकर्मी की समीक्षा का बिंदु अपने साथियों को शामिल करना है । इन्वॉल्वमेंट एक दीवार पर कोड नहीं फेंक रहा है और एक प्रतिक्रिया का इंतजार कर रहा है। बेहतर कोड बनाने के लिए इन्वॉल्वमेंट एक साथ काम कर रहा है। उनसे बातचीत में व्यस्त रहें।

सलाह

आपके द्वारा लिखे गए प्रश्न के अंत की ओर:

मैं सहयोगियों को प्रोत्साहित करने के बारे में वास्तव में आकर्षक सौंदर्य त्रुटियों के साथ संतुलन में दोष के लिए कैसे देखूंगा?

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

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

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

समीक्षा के बाद क्या करें

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

Comments

एक उत्कृष्ट उत्तर के लिए धन्यवाद। मुझे लगता है कि मेरी कुंठाएँ झूठ हैं जहाँ biggerमुद्दों पर ध्यान नहीं दिया जा रहा है। जैसे कि DB टेबल पर लापता इंडेक्स। या तर्क को समझे बिना और गलत तरीके से ऐसा करने के लिए एक पद्धति या एल्गोरिथ्म का उपयोग करने का प्रयास करना। मेरे लिए - ये अधिक महत्वपूर्ण हैं और इन्हें संबोधित किया जाना चाहिए और मुख्य रूप से हल किया जाना चाहिए - सौंदर्यशास्त्र एक माध्यमिक चिंता का विषय है।

— ग्रेवी

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

— ब्रायन ओकले

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

— ग्रेवी

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

— डेडुप्लिकेटर

अधिकांश लोग सराहना करते हैं जब भाषा में त्रुटियों को इंगित किया जाता है ताकि वे सुधार कर सकें।

— gnasher729

Answer 2

लोग कोड फ़ॉर्मेटिंग और टाइपोस पर टिप्पणी करते हैं क्योंकि वे स्पॉट करना आसान होते हैं और उनसे बहुत प्रयास की आवश्यकता नहीं होती है।

इस भाग को ठीक करना आसान है - लगभग किसी भी भाषा में एक लाइनर या स्टाइल चेकर टूल है। आप इसे प्लग इन करें, प्रक्रिया का निर्माण करें, ताकि बेमानी जगह होने पर यह निर्माण विफल हो जाए। परिणामस्वरूप टिप्पणी करने के लिए कोई स्टाइल मुद्दे नहीं होंगे।

वास्तविक समस्याओं को खोजने के लिए उन्हें प्राप्त करना काफी चुनौती भरा हो सकता है। इसके लिए न केवल एक विशेष जिज्ञासु और विस्तार-उन्मुख मानसिकता की आवश्यकता है, बल्कि एक महत्वपूर्ण प्रेरणा भी है।

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

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

Comments

मैं आपकी टिप्पणियों पर आपसे सहमत हूं। और अगर आप ocean of shitमेरे द्वारा लिखा गया देखें - तो मैं आपको फिर से लिखने का सुझाव देने के लिए प्रोत्साहित करूंगा। लेकिन अगर आप उपेक्षा करते हैं, shitलेकिन मुझे कॉस्मेटिक सामान को ठीक करने के लिए कहते हैं - तो इससे मुझे निराशा होती है।

— ग्रेवी

Answer 3

यहाँ व्यावहारिक उत्तर आता है:

परिदृश्य 1 : आप वरिष्ठ सदस्य हैं और कोई व्यक्ति जो अभ्यास का निर्णय ले सकता है

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

परिदृश्य 2 : आप कोई ऐसा व्यक्ति नहीं हैं जो अभ्यास का निर्णय करता है या आप टीम में एक अपेक्षाकृत जूनियर सदस्य हैं

जब तक आप परिदृश्य 1 तक पहुंचने का प्रबंधन नहीं करते, तब तक आपकी सबसे अच्छी शर्त कोड समीक्षा मुद्दों को हल करना है ।

Answer 4

"तुच्छ" कोड की समीक्षा टिप्पणियों को रोकने के लिए सरल उत्तर जोर देकर कहते हैं (दक्षता के लिए) कि समीक्षक को उन्हें ठीक करने के लिए होना चाहिए। इसलिए यदि समीक्षक को पता चलता है कि आपने (हॉरर!) फुलस्टॉप मिस कर दिया है या गलत तरीके से टिप्पणी की है, तो उन्हें इसे ठीक करना चाहिए और आगे बढ़ना चाहिए।

मेरे अनुभव में इसका मतलब है कि:

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

किसी भी तरह से, यह एक लाभ है। एक असफल समीक्षा की लागत एक डेवलपर को रोकने के संदर्भ में अधिक है कि वह क्या काम कर रहा है और अपने कोड को फिर से देखें, और बाद की अनुवर्ती समीक्षा करें। यदि एक समीक्षा वास्तविक कोड गुणवत्ता या वास्तु संबंधी मुद्दों को ढूंढती है तो यह लागत हर पैसे के लायक है, लेकिन सामान्य लागत के लिए इस लागत का भुगतान करना नहीं है।

Answer 5

समीक्षा प्रक्रिया की समीक्षा करें

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

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

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

Answer 6

जैसा कि कोई है जो इस के दोनों किनारों पर है (दूसरों द्वारा लिखे गए कोड की समीक्षा कर रहा है, साथ ही साथ कोड को मैंने समीक्षा की है), मैं कहूंगा कि मेरी तीन श्रेणियां हैं जो किसी भी प्रतिक्रिया में आती हैं। खैर, चार, "सब ठीक है" का रमणीय मामला भी है।

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

• वाक्यों के अंत में पूर्ण विराम (डॉक स्ट्रिंग्स या टिप्पणियों में)। किसी भी तरह से अनाड़ी व्याकरण, जो उपयोगकर्ताओं को किसी भी तरह से आकार या रूप में उत्सर्जित नहीं करता है (फिर से, डॉक्टर के तार और टिप्पणियां)
• ऐसा कोड जिसके पास एक और अधिक सुंदर तरीका है, लेकिन जो कुछ समझ में आता है और मुहावरेदार है (मैं शायद अपना सुझाव भी रखूंगा, इसलिए इसे छोड़ना या ठीक करना आसान है)

"जिन चीजों को ठीक करने की आवश्यकता है, लेकिन मैं आपको ऐसा करने के लिए भरोसा करूंगा" (यदि सभी चीजें इस या पिछली श्रेणी में आती हैं, तो मैं "इनको ठीक करूँगा, जब आप मुझे बताएंगे तो मैं विलीन हो जाऊंगा" पुनः किया "(और उस बिंदु पर मैं शायद यह देखने के लिए जल्दी से स्कैन करूँगा कि कुछ और नहीं हुआ)):

• माइनर क्विबल्स ("आप एक बूलियन की तुलना कर रहे हैं true, यह थोड़ा पागल है ...", ...)
• मामूली शैली का उल्लंघन, ("स्टाइल गाइड एक्स कहता है, जो आपने किया है वह बाहर है; मैं वाई या जेड करूंगा, इस पर निर्भर करता है कि आप किस रास्ते पर जाना चाहते हैं")
• कुछ लापता परीक्षण मामले, जिन्हें लिखना कठिन नहीं होना चाहिए

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

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

Answer 7

ऐसा लगता है कि कुछ लोग सबसे महत्वपूर्ण सवाल भूल गए हैं: यह क्या है कि आप वास्तव में कोड समीक्षाओं के साथ प्राप्त करना चाहते हैं?

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

यदि आप समीक्षा प्रक्रिया को अपने सहयोगियों को नीचे रखने, या उनके लिए काम करने के अवसर के रूप में देखते हैं, तो आप इसे गलत कर रहे हैं।