कोड की समीक्षा कैसे करें जिसे आप नहीं समझते हैं?


25

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

हमारी कंपनी में 3 प्रोग्रामर हैं। मैं एक वेब प्रोग्रामर हूं, मेरी ज्ञात भाषाएं मुख्य रूप से PHP, ActionScript और JavaScript हैं। अन्य 2 डेवलपर्स VB.net में आंतरिक एप्लिकेशन लिखते हैं

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

यदि मुझे ऐसा कुछ दिखाई देता है जो गलत लगता है, तो मैं अपनी राय समझाता हूं और मैं समझाता हूं कि मैं इसे उन भाषाओं में कैसे संबोधित करूंगा, जिन्हें मैं जानता हूं।

कभी-कभी मेरे सुझावों का स्वागत किया जाता है लेकिन कई बार मुझे ऐसी बातें बताई जाती हैं जैसे "यह इस भाषा में करने का सबसे अच्छा तरीका है " या "जो इस भाषा पर लागू नहीं होता है " या उस प्रकृति की समान चीज़ों पर।

यह सच हो सकता है, लेकिन भाषा जाने बिना मुझे यकीन नहीं है कि इन दावों की पुष्टि या खंडन कैसे किया जाए।

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

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

मुझे लगता है कि यह भी संभावना है कि एक परामर्शदाता को काम पर रखने की जरूरत है और हमें कुछ कोड समीक्षाएँ दें।

आप इस स्थिति में मुझे क्या करने की सलाह देंगे।


6
आपको VB कोड समझना मुश्किल है? क्या आपको यकीन है? मुझे पूछने दो कि फिर से यकीन है! :)
Darknight

4
आपको VB सीखने में कोई दिलचस्पी नहीं है? तब आपको संभवतः VB कोड की कोड समीक्षा करने के कार्य को अस्वीकार कर देना चाहिए!
जैक्सबी

जवाबों:


22

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

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


5
+1 आप जो सीखना चाहते हैं, उसकी बजाय सीखने के लिए आपको क्या सीखना चाहिए। अधिमानतः, दोनों सीखना - भाषा सीखना एक त्वरित बात है।
परिक्रमा

1
+1: "उन्हें आपको दिखाने के लिए" के बारे में, gentler तरीका यह पूछना है कि क्या उनके पास कुछ किताबें हैं या जहां उन सिद्धांतों को समझाया गया है, इसलिए आप भी सीख सकते हैं। यह एक ही है, केवल कम आक्रमण। और लोग हमला करना पसंद नहीं करते।
जोरिस मेयस

@ जॉरिस मेय्स, हाँ, आप कर सकते हैं और इसे विनम्रता से करना चाहिए, लेकिन कोड पास को प्रमाणित करने से पहले आपको जवाब देने के लिए उन्हें धक्का देने की आवश्यकता होगी यदि वे "क्योंकि मैंने ऐसा कहा था"।
HLGEM

1
@ जेफ ओ: मैं राजनीति को हमेशा विशेषाधिकार नहीं मानता। काम के माहौल में, यह एक महत्वपूर्ण उपकरण है कि आप क्या चाहते हैं। या एक तरह से संदेश प्राप्त करने के लिए जिसका मुकाबला करना कठिन है। विनम्र होने के लिए कोई भी आपको नाम नहीं दे सकता ...
जोरिस मेयस

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

13

दरअसल, मैं उपरोक्त सभी से असहमत हूं। JS / PHP / ActiopnScript के साथ, आपको एक प्रोग्रामिंग भाषा क्या है और यह कैसे काम करती है, इसकी एक बुनियादी समझ है। वास्तव में, मैं तर्क दूंगा कि वीबी और जेएस के बीच काफी समानताएं हैं। हालाँकि, यह मेरी बात नहीं है। यहां तक ​​कि अगर आप भाषा के साथ बहुत सक्षम हैं, तो किसी और की सोच प्रक्रियाओं का पालन करने की कोशिश करते समय कुछ को अनदेखा करना आसान है, इसलिए समीक्षा क्या करनी चाहिए, इससे प्रोग्रामर को यह समझाने का अवसर मिलता है कि उसने क्या किया और क्यों किया।

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


4
+1 फॉर जनीटर थ्योरी - मैं आमतौर पर "साउंडिंग बोर्ड" के रूप में संदर्भित करता हूं, कोई भी व्यक्ति जो सवाल सुन सकता है और पूछ सकता है, वह अच्छा है, भले ही वे वहां खड़े हों।
परिक्रमा

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

7

लघु संस्करण

  1. याद रखें कि कोड समीक्षा समीक्षक और समीक्षक दोनों के लिए सीखने का एक मौका है ।
  2. सवाल के रूप में वाक्यांश प्रतिक्रिया।
  3. ज्ञान की कमी को प्रतिक्रिया देने से न रोकें (जब तक आप # 2 कर रहे हैं)।
  4. "वरीयता समीक्षाओं" से बचें या कम से कम यह स्पष्ट करने का प्रयास करें कि वे आपकी अपनी व्यक्तिगत प्राथमिकताएं हैं और उन्हें सहमत होने की आवश्यकता नहीं है।
  5. "आर्मचेयर कोड समीक्षक" होने के बजाय पैच सबमिट करने का प्रयास करें।

लंबा संस्करण

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

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

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

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

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


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

7

आपने समस्या पर ध्यान केंद्रित किया है और खराब समाधान के साथ आए हैं। आपको विकास में सुधार करने का काम दिया गया है और आपका समाधान एक व्यक्ति को कोड समीक्षा (खुद) के प्रभारी रखना है जो भाषा को नहीं समझता है। आपके कोड की समीक्षा कौन कर रहा है? जब तक आप भाषा नहीं सीख लेते वे एक-दूसरे की समीक्षा क्यों नहीं कर सकते?

अधिक तत्काल सुधार के लिए कुछ अन्य समस्या क्षेत्र का चयन किया जा सकता था। इस तरह वे सिर्फ आप पर धुआँ उड़ाते हैं और कुछ भी नहीं सुधरता है।

ऐसी भाषा में नए विकास को निर्देशित करना, जिसे आप में से कोई भी नहीं समझता (C #) विशेष रूप से भुगतान करने के लिए एक लंबा समय लेने जा रहा है, खासकर यदि आप हर कोई अपनी बुरी आदतों को अपने साथ लाता है।

डिजाइन पर ध्यान दें (यह उल्लेख किया गया है।)। यदि उन्हें वर्तमान कोड को बनाए रखने में कठिनाई हो रही है, तो VB के लिए कुछ रीफैक्टरिंग टूल देखें। बुनियादी प्रथाओं में से कई समान हैं।


5

आप उस सामग्री को 'प्रूफ़ रीड रीड' कर सकते हैं जिसे आप वास्तव में नहीं जानते हैं, लेकिन आप इसकी पर्याप्त समीक्षा नहीं कर सकते । मैं C में बहुत सक्षम हूं, C ++ को अच्छी तरह से जानता हूं, लेकिन मैं C # में कुछ की समीक्षा करने का सपना नहीं देखूंगा।

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

फिर भी, यह व्यक्तिगत डेवलपर पर निर्भर होगा जो परिणाम की व्याख्या करने के लिए भाषा जानता है। उदाहरण के लिए, यदि कोई कोड समीक्षक मुझे रिटर्न वैल्यू का उपयोग नहीं करने के लिए डिंग करता है printf(), तो मैं उन्हें अजीब तरीके से देखूंगा और उनकी संयमता पर सवाल उठाऊंगा, फिर पूछेंगे "ठीक है, महान, जब मैं सांत्वना के लिए कुछ भी नहीं छाप सकता तो मैं क्या कर सकता हूं?" सहायक बनें?"

आप जिन बातों पर विचार करना चाहते हैं, वे विभागों और टीम लीडों को स्थापित करने के बारे में अपने मालिकों से बात कर रहे हैं, ताकि आप अपने डोमेन में प्रभावी हो सकें, जबकि कोई और अपने डोमेन में प्रभावी हो।

फिर भी, मुझे लगता है कि आप ऑडिटिंग के लिए किसी तीसरे पक्ष का उपयोग करने में सक्षम हो सकते हैं। अपने नमक के लायक अधिकांश प्रोग्रामर वैध चिंताओं पर ध्यान देंगे , भले ही वे आधे फर्जी (जैसे मैं अपने printf()उदाहरण में हो) को खारिज कर दें ।


4

कुछ समझ में न आने पर मार्गदर्शन प्रदान करना अंधे के लिए अंधे के समान है जैसा कि आप अच्छी तरह से जानते हैं।

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

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


4

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

अच्छी खबर यह है कि एक बार जब आप यह कर लेते हैं, तो आपने जो कुछ सीखा है वह तब भी उपयोगी होगा जब आप C # पर चलते हैं।


9
VB पढ़ना, VB जानने के समान नहीं है । मैंने पुराने VB कोड को जावा में फिर से लिखने के लिए VB को अच्छी तरह से पढ़ा। मैं VB नहीं लिखता (और नहीं कर सकता)। मुझे लगता है कि पर्याप्त VB सीखने का एक मध्यम आधार है ।
एस.लॉट

1
@ S.Lott - अच्छी तरह से व्यक्त और किसी भी दो यादृच्छिक भाषाओं के लिए काफी लागू है।
टिम पोस्ट

2
@ S.Lott: आप जावा में यह पुनर्लेखन के लिए काफी अच्छी तरह से वीबी पढ़ सकते हैं, तो आप करते वीबी पता है, और यह लिख सकते हैं। जैसे ही आप जाते हैं आपको चीजों को देखना पड़ सकता है, लेकिन यह केवल कुछ हफ्तों तक चलेगा।
लैरी कोलमैन

@ लॉरी कोलमैन: मुझे लगता है कि आप वीबी को अच्छी तरह से जानते हैं। मैं इसे लिख नहीं सकता था। वास्तव में। मैं एक पायथन / जावा प्रोग्रामर हूं और वीबी की सीमाएं और अजीबता मुझे भ्रमित करती है। बहुत। मैं सिर्फ वाक्यविन्यास नहीं देख रहा हूँ। मैं उचित कार्यक्रमों को लिखने में बहुत असमर्थ होऊंगा क्योंकि मैं इस तरह नहीं सोचता।
S.Lott

@ एस.लॉट: मुझे पता है कि मेरे सबसे अच्छे प्रयासों को भूलने के बावजूद वीबी काफी अच्छा है। यदि VB की विचित्रता / सीमाएँ आपको भ्रमित कर रही हैं, तो कोड को दूसरी भाषा में पोर्ट करते समय क्या यह भी समस्या का कारण नहीं होगा?
लैरी कोलमैन

3

सहकर्मी की समीक्षा करते समय आपको हर समय यह विचार रखना चाहिए कि:

"मैं इस कोड को मुख्य करने के लिए एक हूँ!"

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

यदि आप VB में प्रोग्राम नहीं कर सकते हैं, तो आप कोड को बनाए नहीं रख सकते हैं, और आप सहकर्मी समीक्षक होने के लिए योग्य नहीं हैं।


1

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

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

मैं मौजूदा दिशा-निर्देशों को चुनने के साथ शुरू करूंगा (मुझे कोई VB.net कोडिंग मानकों की जानकारी नहीं है लेकिन Google ने मुझे दिया है:

VB .net के लिए टूल्सक जैसी स्टाइलकॉप का उपयोग करें

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

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


1

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

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

बेशक दोनों के बीच ओवरलैप है। VB.NET को जानने से आप इस बात की सलाह दे सकते हैं कि एक विशेष डिज़ाइन पैटर्न उदाहरण के लिए किसी विशेष स्थिति में एक अच्छा विकल्प क्यों नहीं है।

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


0

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

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


0

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

मान लीजिए कि आप इस बात से अवगत नहीं थे कि पायथन 2 में इनपुट () फ़ंक्शन वास्तव में इनपुट को वापस करने से पहले मूल्यांकन करता है, ताकि गैर-स्ट्रिंग इनपुट प्रकारों को पार्स करना आसान हो सके। तब कोड आर्बिट्राइवर्स कोड निष्पादन के लिए असुरक्षित होगा, जिससे उपयोगकर्ता को __import__('os').execl('/bin/sh', '/bin/sh')लिनक्स सिस्टम पर कुछ ऐसा दर्ज करने की अनुमति मिलती है, जो पायथन प्रक्रिया को खोल में बदल देता है। इसके बजाय, अपरिष्कृत इनपुट डेटा प्राप्त करने के लिए raw_input () का उपयोग किया जाना चाहिए।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.