कोड समीक्षा, क्या फायदे हैं? [बन्द है]

Question

मेरी टीम में, हम औपचारिक कोड समीक्षा नहीं करते हैं। हम सोचते हैं कि यह जोड़ी प्रोग्रामिंग और अक्सर जोड़े को घुमाने के साथ पर्याप्त है।

क्या हमें औपचारिक कोड समीक्षा करने पर विचार करना चाहिए? क्या होंगे फायदे?

Comments

संबंधित प्रश्न: programmers.stackexchange.com/questions/15874/… आपको वहां कुछ प्रतिक्रियाएँ दिलचस्प लग सकती हैं।

— केविन डी

लोग कोड समीक्षाओं के बारे में बात याद कर रहे हैं ... न केवल वे शुद्धता के लिए कोड की जांच करते हैं, लेकिन वे चारों ओर दोष फैलाते हैं यदि बाद में कुछ गलत हो जाता है। जोड़ी प्रोग्रामिंग के साथ यह आप या दूसरा लड़का है जो काट लेता है।

— जेम्स

Answer 1

हम कोड की समीक्षा थोड़ी अलग (शायद) करते हैं।

हम सभी प्रोग्रामर को एक साथ (प्रत्येक शुक्रवार) आते हैं और देखते हैं कि हमने एक सप्ताह की अवधि में क्या किया है। तब हमने चुना कि हम किन परियोजनाओं की समीक्षा करना चाहते हैं ताकि हर प्रगति / प्रगति परियोजना में कम से कम एक या कुछ लोग हों। फिर घंटे या तो हम उन बदलावों को देखते हैं, जो गलतियों की खोज करते हैं, अन्य परियोजनाएं कैसे काम करती हैं और आदि। इसके बाद हम चर्चा करते हैं, गलतियों को बताएं, यह कैसे किया जाना चाहिए (हम बग को ठीक नहीं करते हैं हम उन्हें इंगित करते हैं। और FIXME के ​​साथ कोड को स्पैम करें)। यह सब आम तौर पर हमारे लिए (10 प्रोग्रामर) लगभग 2 घंटे लगते हैं।

गुण:

• हर सदस्य को पता है कि कंपनी में क्या होता है
• कीड़े तेजी से पाए जाते हैं
• यह हमें पठनीय कोड लिखने के लिए मजबूर करता है (कोड जिसे बिना स्पष्टीकरण या परिचय के पढ़ा जा सकता है!)
• अनुकूलन के तरीके / ट्रिक्स / उत्पादक कार्यक्रम तेजी से फैलते हैं
• एक विशेषज्ञ के रूप में प्रोग्रामर "तेजी से विकसित"
• मजा आता है

जैसा कि मैंने उल्लेख किया है कि जोड़ी प्रोग्रामिंग के खिलाफ है (निश्चित रूप से यह केवल मेरी निजी राय है) यह है कि टीम जितनी देर तक काम करेगी - उतनी ही तेजी से इसे पूरा करेगी।

मुझे उम्मीद है कि यह विचार के लिए कुछ भोजन लाएगा। सौभाग्य।

Comments

जब आप कहते हैं कि "टीम जितनी देर तक काम करती है - उतनी ही तेज़ हो जाती है"? और वह बुरी चीज कैसे है?

— एडगर गोंजालेज

टीम को एक-दूसरे को पता चल जाता है कि वहां वे तेजी से काम पूरा कर सकते हैं। अगर आप लगातार जोड़े को मिलाते हैं तो आपको ऐसा नहीं मिलता।

— १२:१४ पर जैकलेओ

ओह, लेकिन आप पूरी टीम को बेहतर जानते हैं, और आपको समस्या डोमेन का बेहतर सामान्य ज्ञान भी प्राप्त होता है, साथ ही सभी टीम के सदस्यों से 3 या 4 अलग-अलग राय मिलती है और सिर्फ एक से नहीं :)

— एडगर गोंजालेज

आपको कोड समीक्षाओं के दौरान समान मिलता है। :) अधिक से अधिक आप हर कंपनी के प्रोग्रामर से हर मामले पर राय लेते हैं। बस कुछ दिनों का इंतजार करना होगा।

— जैकलेओ

Answer 2

आप इस मुफ्त पुस्तक के माध्यम से पढ़ना चाह सकते हैं:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

ज़रूर, उनके पास धक्का देने के लिए एक उत्पाद है, लेकिन वहां अभी भी बहुत सारी उपयोगी जानकारी है।

वे यह भी चर्चा करते हैं कि कैसे जोड़ी प्रोग्रामिंग कुछ समान लाभ प्रदान करती है, इसलिए यदि आप जोड़ी प्रोग्रामिंग हैं तो आपको कोड समीक्षा की आवश्यकता नहीं हो सकती है।

Answer 3

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

पहले 2 बिंदु जोड़ी प्रोग्रामिंग द्वारा काफी अच्छे से कवर किए गए हैं, तीसरा जोड़ी पर बहुत निर्भर है और एक औपचारिक कोड समीक्षा से बेहतर हो सकता है।

Answer 4

क्या आपको औपचारिक कोड समीक्षाएं करनी चाहिए?

पूर्ण रूप से

बस एक त्वरित पक्ष के रूप में, मेरे पास युग्मित प्रोग्रामिंग के साथ बहुत कम अनुभव है, लेकिन मुझे विश्वास नहीं है कि समीक्षा इन विधियों के साथ संघर्ष करेगी।

मैं कोड समीक्षाओं के दो रूप प्रस्तुत करूंगा:

सहकर्मी कोड समीक्षा

यहां तक ​​कि अगर युग्मित प्रोग्रामिंग आपके लिए काम करती है, तो कोड पर आंखों का एक और सेट प्राप्त करने के लिए कभी भी दर्द नहीं होता है। इससे होने वाले लाभ हैं:

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

पीयर कोड रिव्यू (मेरी दुनिया में) हर सबमिशन से पहले किए जाते हैं । यह युग्मित प्रोग्रामिंग की दुनिया में कैसे काम करता है, मैं अनिश्चित हूँ।

समूह कोड समीक्षाएँ

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

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

मैं कुछ अनौपचारिक रूप से कोड के माध्यम से जाऊंगा, किसी को भी कमरे में अलग-अलग समाधानों को इंगित करने देता हूं जो उनके पास हो सकते हैं या तर्क दोष हो सकते हैं। इसका मतलब एक समूह की चर्चा से अधिक है कि वहां बैठे नेता हर किसी को बताएं कि उन्हें कैसे कोड करना चाहिए।

मैंने पाया है कि इन दोनों विधियों को नियोजित करने से दर में वृद्धि होती है, जिस पर इंजीनियर प्रगति करते हैं और बग को बहुत कम करते हैं :)

Comments

"यह कभी दर्द नहीं होता"। खैर, हाँ यह कर सकते हैं। कोड समीक्षा महंगी हैं और समय की एक बड़ी बर्बादी हो सकती है, जो कि काम करने वाले सॉफ्टवेयर वितरित करने में बहुत बेहतर होगी।

— मार्टिन विकमन

@ फ्लिपकार्ट पर मार्टिन, सहकर्मी समीक्षा आपके ट्रक नंबर को बढ़ाती है। एकमात्र व्यक्ति जो जानता है कि X क्या मरता है, समय की एक बड़ी बर्बादी है क्योंकि आप एक प्रतिस्थापन को स्पिन करने की कोशिश करते हैं।

— फ्रैंक शीयर

@ फ्रेंक हां, लेकिन हम ट्रक नंबर मैनेज करने योग्य रखने के साथ जोड़ी प्रोग्रामिंग और पीपी वर्क्स जस्टा गुड (बेहतर इमो) के साथ औपचारिक समीक्षा की तुलना कर रहे हैं।

— मार्टिन विकमैन

@ मर्टिन: यदि आप ईमानदारी से मानते हैं कि, तो मैं शर्त लगाने को तैयार हूँ कि आप अप्रभावी कोड समीक्षाओं के अंत में हैं। आम तौर पर, मैंने सुना है कि कोड समीक्षाएं उसी लोगों से "समय की भारी बर्बादी" होती हैं जो जोर देकर कहते हैं कि तकनीकी डिजाइन विकास की आवश्यकता नहीं हैं। एक उच्च दबाव के वातावरण में विकसित होने के वर्षों के बाद , मैं आपको असमान रूप से बता सकता हूं कि कोड समीक्षाएं समय की बर्बादी नहीं हैं । कोड की गुणवत्ता बढ़ जाती है, बग मायने रखता है, ज्ञान हस्तांतरण / साझाकरण बढ़ता है।

— डेमियन ब्रेख्त

@ डेमियन, फिर से हम पीपी के साथ तुलना कर रहे हैं जो कोड की समीक्षा है, लेकिन यह लगातार होता है। यह मेरे अनुभव में औपचारिक कोड समीक्षाओं से बेहतर है। सहकर्मी की समीक्षा आवश्यक है, लेकिन उन्हें करने के कई तरीके हैं।

— मार्टिन विकमैन

Answer 5

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

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

हमने औसतन प्रति सप्ताह एक सत्र किया, जिसमें 3-5 व्यक्ति शामिल थे। प्रत्येक सत्र में प्रति व्यक्ति (तैयारी सहित) 3-4 घंटे का समय लगता था, और कोड की 200-300 पंक्तियों (LOC) * की समीक्षा करता था। इस गति में, 6 महीने से अधिक की अवधि के दौरान, हम लगभग 50K में से 5K LOC के बारे में समीक्षा करने में सफल रहे।

रेट्रोस्पेक्ट में, मुझे लगता है कि यह बहुत महंगा था। इस गति के साथ, हमें पूरी विरासत कोडबेस की समीक्षा करने में 5 साल लग गए होंगे। OTOH एक सप्ताह में एक से अधिक सत्र होने से संसाधनों को विकास से दूर ले जाया जाता। बेशक, यह विरासत कोड के साथ विशिष्ट दुविधा है। लेकिन यहां तक ​​कि औपचारिक रूप से सभी नए सिरे से लिखे गए कोड की समीक्षा करने में काफी समय लगेगा, जिससे विकास काफी धीमा हो जाएगा।

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

---

* यह औपचारिक कोड समीक्षाओं की सामान्य गति है।

विशिष्ट कोड समीक्षा दर प्रति घंटे कोड की लगभग 150 लाइनें हैं। महत्वपूर्ण सॉफ़्टवेयर (जैसे सुरक्षा महत्वपूर्ण एम्बेडेड सॉफ़्टवेयर) के लिए प्रति घंटे कोड की कुछ सौ से अधिक पंक्तियों का निरीक्षण और समीक्षा करना त्रुटियों को खोजने के लिए बहुत तेज़ हो सकता है।

विकिपीडिया से उद्धृत (मेरे द्वारा जोर)।

Answer 6

अंतर्निहित कारण कोड समीक्षाएं मौजूद हैं क्योंकि पृथक प्रोग्रामर को अपने कोड को पूरा करने और चर्चा करने और यह जांचने की आवश्यकता है कि यह उनके मानक के अनुरूप है।

आप किसी भी गुणवत्ता की समस्या का उल्लेख नहीं करते हैं, इसलिए ऐसा लगता है कि आपकी टीम उनकी जोड़ी प्रोग्रामिंग के माध्यम से पहले से ही पर्याप्त कोड समीक्षा कर रही है। बहुत बढ़िया!

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

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

Answer 7

शायद। कोड समीक्षा में समय लगता है। वे केवल तभी सार्थक होते हैं जब समीक्षा द्वारा लिया गया समय प्रक्रिया में किसी अन्य बिंदु पर सहेजा जाता है। कोड समीक्षा से आपको क्या बचत की उम्मीद है? क्या आप कठिनाइयों का सामना कर रहे हैं जिन्हें कोड समीक्षाओं द्वारा रोका जा सकता है?

Answer 8

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

क्या लाभ हैं? वैसे, बेहतर होगा कि आप इसे न करने के जोखिमों पर विचार करें।

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

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

Answer 9

मेरे लिए कोड समीक्षाओं का मुख्य लाभ यह है कि इससे लोग बेहतर कोड लिखते हैं।

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