क्या मुझे पता नहीं है कि भाषा में कोड की समीक्षा करना प्रभावी है?

108

मैं एक अनुभवी डेवलपर हूं, लेकिन कई कोड समीक्षाएं नहीं की हैं। मुझे पायथन में लिखे गए कोड की समीक्षा करने के लिए कहा जा रहा है लेकिन मैं पायथन को नहीं जानता।

क्या मुझे किसी ऐसी भाषा में कोड की समीक्षा करने का कोई मतलब नहीं है जो मैं नहीं जानता?

code-reviews

— हीथ स्मिथ
स्रोत

62

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

10

इसके अलावा संबंधित: वरिष्ठ प्रोग्रामर की परियोजनाओं में जूनियर प्रोग्रामर कोड समीक्षकों के रूप में शामिल होना चाहिए?

14

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

— डेन पिकेलमैन

9

@ रॉबीडी बिल्कुल! किसी को अपना कोड समझाना अक्सर सार्थक होता है भले ही वह सिर्फ एक टेडी बियर हो ।

— किलन फ़ॉथ

34

आप कहते हैं कि आपको ऐसा करने के लिए कहा जा रहा है। आपसे पूछने वाला व्यक्ति सोचता है कि आप इस कार्य को कर रहे हैं, आपके संगठन में मूल्य बढ़ेगा। यदि आप जानना चाहते हैं कि उस व्यक्ति का स्वभाव उस व्यक्ति से क्या पूछना है , न कि इंटरनेट पर अजनबी! हम नहीं जानते कि उस व्यक्ति के सिर के अंदर क्या चल रहा है। शायद कोड इतनी कम गुणवत्ता का है कि यहां तक कि नौसिखियों को भी समस्याएं मिल सकती हैं। शायद कोड इतनी उच्च गुणवत्ता का है कि आप इससे अच्छी आदतें सीखेंगे। कौन कह सकता है? किसी को लगता है कि यह मूल्य का है; उस व्यक्ति से पूछें कि मूल्य क्या है।

— एरिक लिपर्ट

120

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

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

— किलियन फोथ
स्रोत

50

कुछ कोड समीक्षाएं करना एक मॉड्यूल, फ्रेमवर्क या यहां तक कि भाषा जानने के लिए एक शानदार तरीका है, इसलिए यह आपके समय के लायक हो सकता है (और शायद आप इसे संकेत दिया जा रहा है ...)। मैं इस तरह की समीक्षा पर हस्ताक्षर नहीं करूंगा, बिना किसी ऐसे व्यक्ति के बिना जो भाषा और कोड दोनों से परिचित हो।

— साधारण

8

यदि आपके पास अच्छा डोमेन ज्ञान है और कोड बहुत अच्छी तरह से नामित / टिप्पणी करता है, तो आप अभी भी उच्च स्तर पर गलत / गलतफहमी / लापता कार्यक्षमता का पता लगा सकते हैं (हालांकि आप वाक्यविन्यास के मुद्दों के कारण गलतियों को हाजिर नहीं कर सकते हैं)

— दान

4

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

— KlaymenDK

2

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

— jpmc26

1

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

— अरोठ

59

कोड समीक्षा स्टैक एक्सचेंज में नियमित योगदानकर्ता के रूप में , मैं उदाहरण के लिए, भाषा-अज्ञेय मुद्दों से पीड़ित बहुत सारे सवालों का सामना करता हूं:

स्वरूपण, इंडेंटेशन
क्षेत्र
लूप्स
ऑपरेशन टाइप करें

और सूची खत्म ही नहीं होती। हालाँकि, जब मुझे भाषा जानने की आवश्यकता नहीं है, तब भी मैं उन मुद्दों / बिंदुओं की समीक्षा कर सकता हूँ।

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

मैं यह भी कहूंगा कि यह किसी के छद्म कोड की समीक्षा करने के समान होगा। जब तक आप उन चीजों पर ध्यान दे सकते हैं और उन चीजों पर टिप्पणी कर सकते हैं जिन्हें आप समझते हैं, तो आप ठीक होंगे, और यह प्रासंगिक होगी।

— मोड़ना
स्रोत

2

मैंने भी एक PHP प्रोग्राम का उत्तर लिखा । यह सबसे बड़ा जवाब नहीं है, लेकिन मैं अभी भी बनाए रखता हूं कि मूल लूप घोषणा बदसूरत है।

— होशे २५०

4

मैंने C # की समीक्षा के संयोजन के माध्यम से, इसे लिखा, और जो मैंने लिखा है उसकी समीक्षा की।

— रबरडक

5

यदि आप पायथन को नहीं जानते हैं, तो आप भाषा में इंडेंटेशन के महत्व की सराहना करने की संभावना नहीं रखते हैं ...

— फ्लोरिस

2

आपके शीर्ष उत्तर के बारे में 2/10 भाषाओं में आप नहीं जानते हैं। मतदाताओं का कहना है कि उन्हें उनके बारे में कुछ भी पता है?

— मार्टिन स्मिथ

हालांकि मैं भाषाओं को नहीं जानता, फिर भी मैं अपने बयानों की जांच करता हूं, और अगर मैंने गड़बड़ की है ... मेरा विश्वास करो, मैं इसके बारे में सुनूंगा

— Quill

44

सामान्य सलाह

यहाँ नीचे पंक्ति है, मेरी राय में:

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

पायथन विशिष्ट विचार और उदाहरण

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

आइए एक साधारण उदाहरण देखें। यह कोड लें:

f = open('/home/me/something.txt')
try:
    content = f.read()
finally:
    f.close()

इस कोड के साथ समस्या देखें? यदि आपने पायथन के साथ काम नहीं किया है, तो आप शायद नहीं करते। समस्या यह है कि पाइथन में बहुत पसंदीदा शैली है जो बिल्कुल एक ही काम करती है:

with open('/home/me/something.txt') as f:
    content = f.read()

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

आइए एक और उदाहरण देखें।

def add_fifty(other_list):
   result = list()
   for i in other_list:
       result.append(i + 50)
   return result

x = range(10)
y = add_fifty(x)

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

x = range(10)
y = [i + 50 for i in x]

यदि आप यह नहीं देखते हैं, तो आप पायथन की विशेषताओं और मुहावरों से परिचित नहीं हैं।

— jpmc26
स्रोत

1

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

— gnasher729

1

@ gnasher729 "वास्तव में, मुझे लगता है कि पायथन ने जिन चीजों पर जोर दिया है, उन्होंने मेरे कोड को अन्य भाषाओं में बेहतर बनाया है, न कि अन्य तरीके से।" =) अन्य भाषाओं में मैं केवल इतना ही जानता हूं कि यह दूर से भी समान है। .NET का LINQ और Java 8 का स्ट्रीम s है। रूबी के पास कुछ हो सकता है, और मुझे यकीन है कि कार्यात्मक भाषाएं कुछ के साथ करीब आती हैं। उदाहरण के साथ मेरी बात यह है कि आप शायद यह करना भी नहीं जानते हैं कि यदि आप पायथन से परिचित नहीं हैं, हालाँकि, तो आप "खराब" संस्करण को चुनौती देना भी नहीं जानते होंगे।

— jpmc26

@x = 1 .. 10; @ आपका = नक्शा {$ _ + 50} @x;

— पाइप

2

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

— phyrfox

3

@phyrfox यह केवल सच नहीं है। तर्क त्रुटियां पाई जा सकती हैं, लेकिन सर्वोत्तम प्रथाओं, सुरक्षा, प्रदर्शन, विश्वसनीयता, पठनीयता / स्थिरता आदि के बारे में कोड समीक्षा भी (या मुख्य रूप से) है, इससे पहले कि कुछ की समीक्षा की जाती है, यह वास्तव में परीक्षण किया जाना चाहिए। कोड समीक्षा की StackExchange की परिभाषा पर बहुत अच्छी जगह है, imo। पायथन में, मैंने जिन उदाहरणों का उल्लेख किया है, वे "छोटे अनुकूलन" नहीं हैं। एक पायथन डेवलपर जो इन पैटर्नों का उपयोग नहीं करता है, समय के पीछे या अक्षम होने पर बहुत अनुभवहीन है। ये भाषा के मूल तत्व हैं।

— jpmc26

21

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

आप पाइथन को नहीं जानते हैं, इसलिए पाइथन कोडर्स के लिए जो आपको साधारण लग सकता है वह आपको अजीब लग सकता है। आप एक सुधार का सुझाव दे सकते हैं जिसे टीम ने कभी नहीं माना था।

— user2023861
स्रोत

1

यह मेरा जवाब होना था। मैं बस इतना ही कहना चाहता हूं कि किसी भी दिन पायथन रूटीन और किसी भी समूह के अजगर गुरुओं के साथ ... उस कोड GARBAGE है।

— dwoz

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

— ट्रिपहाउंड

21

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

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

चूंकि मैं सी ++ में कार्यक्रम करता हूं , और मैं अजगर को अच्छी तरह से नहीं जानता, इसलिए मैं पायथन कोड की समीक्षा करने की हिम्मत नहीं करूंगा। हालाँकि मैं जावा कोड की समीक्षा में मदद कर सकता हूं।

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

— BЈовић
स्रोत

23

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

— वद्रालो १३'१६

1

@ Davor Javadralo बल्ले से मुझे पता है कि जावा में चेकस्टाइल है। अधिक औपचारिक स्थैतिक विश्लेषण उपकरण कई भाषाओं के लिए सामान्य हैं, और उन्हें एक कोडिंग मानक लागू करना आमतौर पर उनके कर्तव्यों में से सबसे कम है।

— शेज

9

मुझे लगता है कि यहां कोड समीक्षा की परिभाषाओं में थोड़ा अंतर है, थोड़े ने सीआर मेटा पर इस प्रश्न की याद दिला दी: कोड रिव्यू क्या है? । मैं कुछ विशेष को बाहर नहीं करूंगा और कहूंगा कि "कोड समीक्षा XYZ के बारे में नहीं है"। यह भी लगता है कि आप कह रहे हैं कि अनुभवी प्रोग्रामर को अपने कोड की समीक्षा करने की आवश्यकता नहीं है, कुछ ऐसा है जिससे मैं बहुत असहमत हूं।

— साइमन फोर्सबर्ग

3

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

— B31овиЈ

2

@ B worstовиЈ नहींं, यह सबसे बुरा नहीं है जिसे आप पा सकते हैं, लेकिन यह "सबसे छोटी चीज जो अभी भी योग्य है," के करीब है।

— वेटिन

11

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

टीम लीडर के दृष्टिकोण से एक कोड की समीक्षा को देखें: वहाँ कोई है जो समझता है कि आवेदन क्या करना चाहिए (व्यापार तर्क), वहाँ कोई है जो समझता है कि कोड कर रहा है (कार्यान्वयन तर्क), और संभवतः कई अन्य लोग वहाँ जो एक विचार है कि कैसे सब एक साथ फिट बैठता है की जरूरत है।

— एडम ज़करमैन
स्रोत

7

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

कुछ विशेषज्ञता आप भाषा जाने बिना साझा कर सकते हैं:

डोमेन की जानकारी।
सामान्य वस्तु उन्मुख डिजाइन।
सामान्य प्रोग्रामिंग प्रथाओं: नामकरण, स्पष्टता, और इसके आगे।

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

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

— कार्ल बेवफेल्ड
स्रोत

5

यह एक जीत की स्थिति हो सकती है। मैं यह कहना चाहूंगा कि आप एक विशेष रूप से मूल्यवान समीक्षक हो सकते हैं क्योंकि आप एक पायथन कुंवारी हैं, जो ज्ञान के अभिशाप से प्रभावित नहीं हुई हैं ।

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

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

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

— 200_success
स्रोत

2

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

— माइकल के
स्रोत

1

कुछ अवलोकन:

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

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

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

— टॉम औ
स्रोत

1

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

— Esoteric स्क्रीन का नाम

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

— जेएफओ

0

यह इस बात पर निर्भर करता है कि समीक्षा का लक्ष्य क्या है; यानी क्या तुम मतलब प्रभावी ।

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

लेकिन आप कई अन्य समस्याओं का पता लगाने की संभावना नहीं रखेंगे। इसलिए यदि वे आपकी समीक्षा करने का इरादा रखते हैं कि यह एक अच्छी तरह से बनाया / काम करने योग्य कार्यक्रम है या नहीं, तो वे निराश होंगे।

वह परिणाम आपके द्वारा किए जाने के समय के लायक है या नहीं, यह काफी हद तक परियोजना पर निर्भर करता है।

— जिमबो जॉनी
स्रोत