क्या कोड अच्छे अभ्यास की समीक्षा कर रहा है?


32

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

मैंने सोचा कि यह बहुत अच्छा होगा: प्रत्येक डेवलपर कोड लिखते समय अधिक सावधान रहेगा और हम अपने अनुभव को बेहतर तरीके से साझा कर सकते हैं। लेकिन किसी तरह हम इस बारे में भूल गए और यह ऑफर सिर्फ एक प्रस्ताव बनकर रह गया।

इसके क्या लाभ हैं और क्या कोई कमियां हैं?


9
यह अनौपचारिक / आकस्मिक कोड समीक्षाओं की तरह लगता है, और कोड समीक्षा एक गुड थिंग (टीएम) है। हमारे पास कोड समीक्षाओं के लिए एक बहन साइट भी है ।
यानिस १३'१२ को

@ElYusubov, टिप्पणी ओड के जवाब के तहत होनी चाहिए, मुझे लगता है कि)))
सुपर मॉम

2
सीखने के माहौल का समर्थन करता है। यह दर्शकों के लिए उतना ही है जितना यह लेखकों के लिए है।
मैथअटैक

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

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

जवाबों:


52

कोड समीक्षा एक महान अभ्यास है।

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

कई कंपनियों में कोड समीक्षाएं होती हैं, हालांकि यह कहना मुश्किल है कि एक विशिष्ट प्रक्रिया है जो वे सभी का पालन करते हैं।

अधिक औपचारिक कोड समीक्षा में, एक वरिष्ठ (या कई वरिष्ठ) अपने कोड की समीक्षा करने के लिए एक डेवलपर के साथ एक साथ बैठेंगे, एक ही समय में सुझाव और शिक्षण की पेशकश करेंगे।

कोड समीक्षाओं के अतिरिक्त लाभ (जैसा कि इस प्रश्न के लिए टिप्पणी की गई है) में शामिल हैं:

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

1
हां, कोड समीक्षाएं अच्छी हैं। लेकिन क्या यह डेवलपर्स को धीमा नहीं करेगा?
रादु मर्ज़िया

4
@SoboLAN - ठीक है, अगर कोड समीक्षाओं का मतलब है कि कीड़े पहले पकड़े गए हैं और खराब डिजाइन तय किए गए हैं इससे पहले कि उन्हें उत्पादन में जाने का मौका मिले, तो आप क्या सोचते हैं?
ऊद

9
@SoboLAN: गुणवत्ता, गति, मूल्य - कोई भी दो उठाओ।
डेन

6
यह कोड आधार की निरंतरता को सुधारने और बनाए रखने का सबसे अच्छा तरीका है , अर्थात यह सुनिश्चित करना कि टीम के सदस्य परियोजना में पसंद किए गए कोडिंग मुहावरों को समझें और साझा करें, और उनका सही उपयोग करें।
Péter Török

4
@SoboLAN: मेरे अनुभव में कोड की समीक्षा डेवलपर्स को गति देती है। आप अधिक बग्स को पकड़ते हैं, तेजी से, और अपने समाधान के साथ तालमेल बिठाते हैं कि अन्य डेवलपर्स क्या कर रहे हैं।
१२:५२

15

कोड समीक्षाएं सीखने के लिए बहुत उपयोगी उपकरण हैं , खासकर जब आपके पास नई टीम के सदस्य हैं। खैर, यह सहकर्मी की समीक्षा प्रक्रिया के रूप में भी जाना जाता है :)

विभिन्न प्रकार की कोड समीक्षाएं हैं:

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

केवल एक ही जगह है associated disadvantageजहां औपचारिक कोड समीक्षा के लिए समीक्षा घटना और निष्पादन समय की तैयारी में काफी निवेश की आवश्यकता होती है

अधिक संदर्भ नीचे सूचीबद्ध हैं (अधिक गहरी गोता पढ़ने के लिए)


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

@DanNeely अच्छी टिप्पणी, मैं इसे सुनिश्चित करने के लिए शामिल करूंगा।
ईएल युसुबोव

11

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

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

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

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


मैं आपसे पूरी तरह सहमत हूं, लेकिन मुझे उम्मीद है कि हमारी टीम पेशेवर है, शर्मिंदा नहीं है बल्कि इसके बजाय सीखें।
सुपर

2
अंत में एक उचित जवाब। मैंने यह पाया कि समूह में करने की तुलना में सिर्फ डेवलपर और एक ही समीक्षक के साथ रिवाइव करना कहीं अधिक प्रभावी है। इस तरह दोनों पक्षों के लिए गलतियों से निपटना बहुत आसान है और आप समूह में दूसरों के समय को बर्बाद किए बिना जोड़ी-प्रोग्रामिंग में कभी-कभी स्लाइड कर सकते हैं।
174 में x4u

5
@superM, नियम "सार्वजनिक रूप से प्रशंसा, निजी में आलोचना" एक कारण से है।
HLGEM

टाइमिंग के लिए +1। सबसे अच्छा जोड़े में कोड है, परीक्षण-पहले। लेकिन किसी भी मामले में आप कोड की समीक्षा करना चाहते हैं जबकि आप इसे फिर से लिखना चाहते हैं। यदि आप बड़ी सफाई करने के लिए तैयार नहीं हैं तो कोड की समीक्षा करने का कोई मतलब नहीं है। मैं कोड समीक्षाओं में रहा हूं, जहां मूल डेवलपर ने लाइब्रेरी फ़ंक्शन को फिर से लागू करने के लिए कोड की 50+ लाइनें ली थीं। लेकिन जब से उस कोड का परीक्षण किया गया था, एक फ़ंक्शन के साथ 50 अनावश्यक लाइनों की जगह की अनुमति नहीं थी! यह 10,000 लाइन प्रोग्राम को चालू करता है जिसे आधे डेवलपर द्वारा 100,000 लाइन प्रोग्राम में बनाए रखा जा सकता है जिसमें चार की आवश्यकता होती है।
केविन क्लाइन

8

इस प्रकार की कोड समीक्षा के साथ समस्या, हर दो सप्ताह में एक डेवलपर, प्रगति धीमी होगी। यह महीनों पहले हो सकता है जब हर कोई सुर्खियों में आया हो।

जबकि कोड समीक्षाएं अच्छी हो सकती हैं, उनके पीछे एक कारण होना चाहिए, और उन्हें करने की प्रक्रिया के पीछे।

कई मुद्दों पर फैसला करना होगा:

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

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


3

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

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


2

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

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

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


1

हालांकि मैं इस बात से पूरी तरह सहमत हूं कि शिक्षण के लिए कोड समीक्षाएं बहुत ही रचनात्मक हैं, मैं उन पर प्रकाश डालना चाहता हूं, वैसे भी यह सुनिश्चित करना है कि टीम के डिजाइन पैटर्न का सही तरीके से पालन किया जा रहा है।

हम थोड़ा प्रोटोटाइप कार्य लिखते हैं और हम कोड के रिफ्लेक्टर बिट्स और जब हम अंत में उत्पाद के साथ सहज महसूस करते हैं तो पठनीयता खराब हो गई है - लोग इसे देख नहीं सकते हैं और स्पष्ट रूप से देख सकते हैं कि क्या चल रहा है।

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

हमारी टीम के लिए हम @ElYusubov का उल्लेख करते हैं और विशेष रूप से कोड समीक्षा - क्रूसिबल के लिए एक उपकरण का उपयोग करते हैं। लोग कोड पर समीक्षा करते हैं, टिप्पणी करते हैं और हस्ताक्षर करते हैं। हर हफ्ते हम बैठते हैं और कोड के दिलचस्प और / या जटिल टुकड़ों का सामना करने के लिए चेहरे की समीक्षा करते हैं।


+1 हम सभी इसे 'काम कर सकते हैं' लेकिन यह सुनिश्चित करने के बारे में अधिक है कि कोड पठनीय और रखरखाव योग्य है, विशेष रूप से सम्मेलनों का पालन करके। सबसे रोमांचक काम नहीं लेकिन बहुत मूल्यवान है।
कर्क ब्राडहर्स्ट

1

एक सॉफ्टवेयर इंजीनियरिंग इंटर्न के रूप में, मुझे कोड समीक्षाएं बेहद मददगार लगी हैं।

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

वास्तव में, मुझे लगता है कि यह केवल थोड़े से कम विकास के साथ थोड़ा धीमा विकास समय के साथ बहुत बेहतर कोड का उत्पादन करता है (जो कि मेरी राय में, लंबी दौड़ में इसके लायक है जब आपको बहुत डिज़ाइन कोड को ठीक / विस्तारित नहीं करना पड़ता)। इसके अलावा, मुझे लगता है कि अगर आपके पास टीम में जूनियर / इंटर्न हैं, तो वे बहुमूल्य प्रतिक्रिया के लिए मौके की सराहना करेंगे। मुझे पता है कि मैं करता हूँ!


मैं केवल / पहले से ही 1.5 साल के लिए काम कर रहा हूं, और मैं समान कारणों से उन कोड समीक्षाओं को चाहता हूं। ))
सुपरमून जूल

1

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

दुर्भाग्य से यह बहुत अच्छा लगता है लेकिन अधिकांश कंपनियों में इसे लागू करना वास्तव में कठिन है। आपकी टीम को "स्वायत्तता" की बहुत आवश्यकता है। अपने प्रबंधकों या वित्तीय विभाग को आश्वस्त करना कि नई सुविधा नहीं बनाना लाभदायक है।

मेरी कंपनी में हम कुछ कोड समीक्षा करने की कोशिश कर रहे हैं। लेकिन बहुत अधिक समय 'खरगोश का पीछा करने' (सुविधाएँ बनाने) के साथ बिताया जाता है।


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

1

इन दिनों टूल (एफएक्सकॉप आदि) का उपयोग करके बहुत सी स्टाइल और बेसिक सिंटैक्स टाइप चेक पकड़े जाते हैं।

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

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

मुझे यह भी लगता है कि गैर-लागू कोड समीक्षाएं - जैसे किसी शेयर पर कोड डालना या उसे इस उम्मीद में ईमेल करना कि कोई इसके माध्यम से जाने के लिए अपने दोपहर के भोजन के समय को छोड़ देता है - समय की बर्बादी है।

लिस्टिंग के ढेर के साथ बैठो, कॉफी क्षेत्र में एक मार्कर और कॉफी का एक कप इसके लिए बहुत अच्छा है।


0

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


-2

कोड समीक्षा "संपूर्ण" देखने में मदद करती है। अलग-अलग डेवलपर्स में सिर्फ अपनी आवश्यकताओं / समस्याओं को देखने की प्रवृत्ति होती है। सीआर पूरे दृष्टिकोण से विचारों और समाधानों का पता लगाता है। सीआर मुख्य रूप से अनावश्यक काम की बर्बादी को खत्म करने में मदद करता है। पूरा उत्पाद सस्ता और बेहतर गुणवत्ता में है।


1
स्पष्टीकरण के बिना, यह जवाब उस स्थिति में बेकार हो सकता है जब कोई अन्य व्यक्ति एक विपरीत राय पोस्ट करता है। उदाहरण के लिए, यदि कोई review कोड की समीक्षा ’ जैसी चीजों का दावा करता है, जिससे“ संपूर्ण ”को देखना कठिन हो जाता है , तो यह उत्तर पाठक को दो विरोधी राय लेने में कैसे मदद करेगा? विचार को बेहतर तरीके से संपादित करने पर विचार करें , उत्तर दिशा निर्देशों को पूरा करने के लिए
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.