मानक कोड समीक्षा में क्या होता है?

19

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

code-reviews

— निकोल
स्रोत

10

यहाँ, जाहिरा तौर पर, हमारे पास कोड समीक्षाओं के लिए समय नहीं है, लेकिन परिणामी पेंच-अप से निपटने के लिए बहुत समय है। काश मैं मजाक कर रहा होता।

— मेटलमीकस्टर

12

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

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

— बेरिन लोरिट्श
स्रोत

LOL, यूनिट परीक्षणों की अच्छी समझ होना आवश्यक है। और अच्छी खबर यह है कि परीक्षण सिर्फ सामान्य ज्ञान है - कहने की तुलना में जानने के लिए कम समय लगता है ... एक नई भाषा चुनने में समय लगता है।

— जॉब

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

— ग्रेग बर्गार्ड्ट

6

यह मुद्दा क्या है के आधार पर भिन्न होता है। बहुत बार यह एक साधारण रबर-स्टैंप है। "यहाँ क्या समस्या थी, इस लाइन को यहाँ देखें, यह स्पष्ट है कि क्या गलत हो रहा है, और यहाँ है जहाँ मैंने इसे ठीक किया है।" "हाँ, यह बहुत स्पष्ट है। आगे बढ़ो और इसे जांचें।"

लेकिन जब कुछ अधिक शामिल होता है, तो यह आमतौर पर इस तरह होता है:

TortoiseSVN पर संशोधन के लिए जाँच करें और परिवर्तित फ़ाइलों की एक सूची प्राप्त करें।
अपने कार्यालय में समीक्षक लाओ।
संदर्भ के लिए खुले बग ट्रैकिंग सिस्टम से CR के साथ, समस्या के बारे में बताएं।
TortoiseSVN में फ़ाइलों की सूची नीचे जाएं, उनमें से प्रत्येक को परिवर्तनों को देखने के लिए BeyondCompare में खोलें ।
यदि समीक्षक परिवर्तनों को नहीं समझता है, तो बताएं कि आपने क्या किया और क्यों किया।
समीक्षक कुछ ऐसा देख सकता है जो अच्छा नहीं लगता है। यदि हां, तो इस पर चर्चा करें जब तक कि आप समझौते पर नहीं पहुंचते हैं या नहीं, इसे बदलना चाहिए। (यदि सरल परिवर्तन किए जाने की आवश्यकता है, तो आप BeyondCompare के अंदर फ़ाइल को संपादित भी कर सकते हैं।)
यदि आपने कोई परिवर्तन किया है, तो पुन: बनाएँ और सुनिश्चित करें कि यह बनाता है!
समीक्षक को प्रदर्शित करने के लिए प्रोग्राम चलाएं कि आपका फिक्स वास्तव में काम करता है।
इसमें जांच करें।

— मेसन व्हीलर
स्रोत

4

IMO, A कोड समीक्षा का फीचर या बग से कोई लेना-देना नहीं है, लेकिन कोड की गुणवत्ता और इसके लिए लिखे गए परीक्षणों पर ध्यान केंद्रित करता है।

तो, आप अपने सहकर्मी के पास बैठते हैं और उसे कोड समझाते हैं, या कोड लेते हैं और इसके माध्यम से जाते हैं, जो भी स्थिति के लिए कॉल करता है।

यह मदद करता है जब हर कोई समान मानकों के खिलाफ कार्यक्रम करता है और यदि आप प्रक्रिया के भाग को स्वचालित करने के लिए fxCop जैसे उपकरण नियोजित करते हैं।

— Syg
स्रोत

2

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

एक कोड समीक्षा में मानकों को लागू करना महत्वपूर्ण है, लेकिन उन्हें केवल ध्यान केंद्रित करने के लिए नहीं।

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

— HLGEM
स्रोत

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

— Joppe

0

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

समय की कमी के कारण तय नहीं किया जाना चाहिए
दिशानिर्देशों के लायक होने की तुलना में अधिक कष्टप्रद पाया गया

दिशानिर्देशों को समझ में आना चाहिए और उल्लंघन का पता लगाने और संभव के रूप में आसान करने के लिए रिफ्लेक्टर करने के लिए उचित उपकरण होना चाहिए। हमेशा दिशानिर्देशों के लक्ष्य और कोड की समीक्षा को देखें

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

मेरे दिमाग में दिशानिर्देश मौजूद हो सकते हैं:

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

उस जगह के साथ कोड की समीक्षा में दिशानिर्देशों के खिलाफ जाँच किए जा रहे सॉफ़्टवेयर शामिल हैं और:

प्रोग्रामर के साथ उल्लंघन पर चर्चा करें
अनावश्यक उल्लंघन ठीक करें
आवश्यक उल्लंघनों पर टिप्पणी करें

— KeesDijk
स्रोत