2009-09-21 7 views
7

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

पहली 5000 या तो लाइनों के बाद कोड पर ध्यान केंद्रित करना असंभव हो जाता है, खासकर जब से यह व्यवसाय उपकरण है और इस प्रकार सबसे दिलचस्प समाधान नहीं है। तो कोड समीक्षा के दौरान कोड पर ध्यान केंद्रित करने के लिए उनके क्या सुझाव हैं?

+9

कॉफी, कॉफी, कॉफी प्रति दिन कॉफी के –

+5

अधिक 2 से कप अनुशंसित नहीं है - स्वास्थ्य के लिए अच्छा नहीं। –

+5

@ शहर में नया: अन्य लोगों के कोड की समीक्षा करना स्वास्थ्य के लिए अच्छा नहीं है। – MusiGenesis

उत्तर

17
  • यदि इसमें कोड चलाना शामिल है तो यह कोड समीक्षा नहीं है।
  • यदि यह कोड की 1000 से अधिक पंक्तियां है तो यह कोड समीक्षा नहीं है।
  • यदि इसे तैयारी के 20 मिनट से अधिक समय लगता है तो यह कोड समीक्षा नहीं है।
  • यदि समीक्षा में एक घंटे से अधिक समय लगता है तो यह कोड समीक्षा नहीं है।

हो सकता है कि आपकी कंपनी कोड समीक्षा प्रक्रिया ठीक करना चाहिए ...

3

अब तक मैं निम्नलिखित

  • उपयोग कर रहा हूँ मेरा ईमेल & आरएसएस इतनी बार हर खिलाती जाँच हो रही है - लेकिन इस रूप में और अधिक कोड समीक्षा की जाती है बढ़ जाती है।
  • कॉफी - अधिक से अधिक
  • प्रश्न या पोस्ट सवालों के जवाब देने के लिए जा रहे Stackoverflow पीने;)
+2

+1 _ प्रश्नों का उत्तर देने या प्रश्न पोस्ट करने के लिए StackOverflow पर जा रहे हैं;) _ –

1

सचमुच एक कठिन समस्या है कि। मुझे लगता है कि आपसे मेरा प्रश्न होगा: आप इसे और अधिक संभावना बनाने के लिए क्या कर सकते हैं कि आपके द्वारा देखे जाने वाले कोड की पहली 5000 लाइनें सही हैं?

दूसरे शब्दों में, जब आपका ध्यान उच्चतम होता है तो हिरन के लिए सबसे अधिक धमाके प्राप्त करें। इसे समझने के लिए आपको चिड़िया के आंखों के दृश्य से कोड देखना होगा।

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

1

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

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

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

और निश्चित रूप से, कैफीन;)

11

आप भली-भांति समझ कोड के प्रत्येक ब्लॉक (कोड के हजार लाइनों प्रति 20 situps, या ऐसा ही कुछ की तरह) के लिए अभ्यास की एक निश्चित संख्या है। आप जो भी बेकार टिप्पणी देखते हैं, या आपके द्वारा पाये जाने वाले प्रत्येक डुप्लिकेट फ़ंक्शन के लिए 10 चिनअप के लिए 5 पुशअप करने जैसी छोटी चीजें जोड़ सकते हैं। शारीरिक गतिविधि दिमाग को ध्यान में रखती है, और दुनिया में अधिकांश कोड की स्थिति दी जाती है, तो आप किसी भी समय गंभीरता से फट जाएंगे।

चेतावनी: क्लासिक एएसपी के लिए अनुशंसित नहीं है। दिल का दौरा और स्ट्रोक अपरिहार्य होगा।

+7

अच्छा विचार, चेतावनी से प्यार किया;) –

+2

जबकि मुझे मजाकिया जवाब मिला, यह ओपी प्रश्न का असली जवाब नहीं है - उन्होंने कहा: "मैं अक्सर उन साइटों पर भेजा जाए जहां मुझे एक सिस्टम की कोड समीक्षा करने की आवश्यकता है, जिसमें मैं शामिल नहीं हूं "... आप संभवत: किसी ग्राहक की साइट पर ऐसा नहीं कर सकते ...: पी – eglasius

+0

फ्रेडी: जब तक कि आप परामर्शदाता न हों शिक्षण फोकस तकनीकें। –

1

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

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

इससे आपको 100% व्यस्त और केंद्रित बना दिया जाएगा। और यह आपकी प्रगति को भी देखेगा और आपको खुश करेगा!

1

मैं चाहता हूं कि आपके पास एक ही समय में सह-समीक्षक हो। यह गति और दक्षता दोनों में सुधार करता है।

+0

जोड़ना मदद करता है। पंद्रह पात्र भी! – gmoore

3

जब तक आप बहुत भाग्यशाली नहीं होते हैं, तो आपको कोड की पहली 5k पंक्तियों में पहले से ही बहुत सारी प्रतिक्रियाएं होनी चाहिए।

ठोस पर this ईबुक देखें।

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

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

1

क्या आप शीर्ष-डाउन फैशन में समीक्षा कर सकते हैं? शीर्ष स्तर (मुख्य विधि?) की समीक्षा करें और उस पर टिप्पणियां लिखें। फिर प्रत्येक अमूर्त परत में एक कदम नीचे ड्रिल करें और उस पर टिप्पणी करें। कभी-कभी मैं सीधे 14 स्तरों के तरीकों को ड्रिल करता हूं और जब मैं बैक अप करता हूं तो पूरी तरह से खो जाता है। आपकी समीक्षा को व्यापक रखने में मदद मिल सकती है।

शायद इसे आईडीई में करना सबसे अच्छा होगा ताकि आप कोड के माध्यम से उछाल सकें।

ऐसा कुछ नहीं जो मैं ईर्ष्या करता हूं। मुझे पास के डेवलपर्स के साथ समीक्षा करना पसंद नहीं है।

समय प्रबंधन के लिए, Pomodoro विधि आज़माएं। जब मैं मैराथन कोडिंग सत्र का सामना कर रहा हूं तो यह वास्तव में मेरी मदद करता है।

2

मेरा मानना ​​है कि जब यह इस तरह आगे बढ़ता है सबसे अच्छा कोड की समीक्षा है:

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

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

2

मैं आमतौर पर एक सुविधा के माध्यम से एक समय में नीचे db से/reporsitory परत पार, जीयूआई।

यदि टिप्पणियां नहीं हैं, तो मैं जो सोच रहा हूं उसकी टिप्पणियां जोड़ूंगा।

मैं सिस्टम की मेरी समझ का एक दिमाग/विकी रखूंगा। एक ब्रेक लेने के बाद पिकअप लेने के लिए एक मस्तिष्क आसान हो जाता है।

मैं अन्य टीम के साथियों के साथ अपने निष्कर्षों के बारे में बात करूंगा।

2

मुझे संदेह है कि कोई भी व्यक्ति दिन में 5000 लाइनों को कोड पढ़ने से सार्थक कुछ भी निकाल सकता है।

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

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

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

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

0

आपके पास अपनी कोड समीक्षाओं में किसी प्रकार की संरचना होनी चाहिए क्योंकि एक समय में एक पंक्ति कोड को पढ़ना असंभव है।

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

आप समीक्षा प्रभावी होने के लिए के लिए समीक्षा की कोड के आकार को सीमित करना चाहिए - मेरे कार्यस्थल पर हम कोड स्रोत नियंत्रण करने के लिए वापस करने से पहले की समीक्षा करने और क्योंकि हम अपने प्रतिबद्ध छोटे हम रखने के समीक्षा अवधि को भी सीमित करें।

समीक्षा मैं सवाल है कि कोड में दिलचस्प/समस्याग्रस्त स्थानों पर मुझे निर्देशित करेंगे पूछने के दौरान:

  • क्या निर्णय आपके द्वारा किए गए जब एक विशिष्ट कार्यान्वयन चुनने?
  • किए गए एक विशिष्ट निर्णय के क्या फायदे हैं?
  • आपका कोड किस डिजाइन पैटर्न/डिज़ाइन सिद्धांतों का पालन करता है?

कोड समीक्षा में सुधार करके सीखने और सिखाने के लिए कोड समीक्षा का मतलब था। बस कोड की 5000 लाइनों को पढ़ना सीधे गलत लगता है ...

0

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

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

से-रेडियो पर कोड पढ़ने की समस्या पर एक बहुत अच्छा पॉडकास्ट है: link। यह डेव थॉमस ("द प्रोगैमैटिक प्रोग्रामर" के लेखक) के साथ एक साक्षात्कार है। मुझे लगता है कि यह उस पर लागू होता है जो आप करने की कोशिश कर रहे हैं।

1

हाँ कोड समीक्षा में आपको कोड पढ़ने की आवश्यकता है। लेकिन कोई उद्देश्य या योजना के साथ सीधे 5K लाइनें नहीं। कोई आश्चर्य नहीं कि आप ध्यान केंद्रित नहीं कर सकते हैं।

मेट्रिक्स का उत्पादन करने वाले विश्लेषण उपकरण वे हैं जो आपको केंद्रित कर सकते हैं। विश्लेषण उपकरण चलाएं और परिणामों को उनके मीट्रिक पर सॉर्ट करें। प्रत्येक उपकरण आपको "शीर्ष 5 फ़ाइलें, या कार्यों" की समस्याओं के साथ किसी दिए गए मुद्दे पर बता देंगे:

  • लंबे फ़ाइलों
  • लंबे कार्यों
  • बड़े प्रशंसक-इन या पंखे की बाहर
  • जटिलता
  • फाहा उल्लंघन

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

मेट्रिक्स, टूल और अवधारणाओं के संदर्भ, और कोडबेस में प्रत्येक प्रकार की समस्या के उदाहरणों के साथ अपनी रिपोर्ट तैयार करें।

सब कुछ किया गया और वे आपको यह बताने के लिए बड़े रुपये का भुगतान करते हैं कि वे शायद पहले ही जानते थे लेकिन खुद को स्वीकार नहीं करना चाहते थे।

1
  1. Outsource your own job। सम्मेलन कक्ष में
  2. प्ले पोर्टेबल वीडियो गेम
  3. कलेक्ट पेचेक
  4. जीवन अच्छा है