ट्रैक: कोड समीक्षा प्लगइन

Question

मैं कोड समीक्षा प्लगइन हमारे trac स्थापना के लिए देख रहा हूं।

मैं

• PeerCodeReview
• CodeReview

मैं PeerCodeReview प्लगइन की ओर झुकाव रहा हूँ गूगल

पर " trac code review" क्वेरी के लिए शीर्ष परिणाम के रूप में इन दोनों पाया।

इन प्लगइन के बारे में इनपुट के लिए एसओ समुदाय का अनुरोध करने के लिए मुझे हमारी ट्रैक स्थापना के लिए एक का चयन करने में मदद करने के लिए।

यदि आप किसी अन्य प्लगइन के बारे में जानते हैं तो कृपया मुझे उन लोगों के बारे में भी बताएं। :)

क्या मैं प्लगइन

• में तलाश कर रहा हूँ एक रास्ता टिप्पणी के साथ कोड टिप्पणी करने के लिए।
• स्वीकृति दें/अस्वीकार करें; एक बटन की तरह यह सूचित करने के लिए कि कोड को बदलने की जरूरत है। शायद एक बग बनाया गया है।
• किसी व्यक्ति को कोड समीक्षा "कार्य" असाइन करने का एक तरीका।

पहली सुविधा आवश्यक है (मुझे लगता है कि यह पूरा बिंदु है); अन्य वैकल्पिक हैं। मैं उस वर्कफ़्लो में फिट होने के समान कुछ पाने के लिए ट्रैक हैक कर सकता हूं। उम्मीद है कि! ;)

Answer 1

पर हम एक ही स्थिति में थे।अंत में हमने ट्रैक के समानांतर में Review Board इंस्टॉल करने का विकल्प चुना। हालांकि यह एक ट्रैक प्लगइन नहीं है, यह एक उत्कृष्ट उपकरण है, और अब तक हम इससे बहुत खुश हैं।

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

Answer 2

मेरी कंपनी में, हमने ट्रैकहेक्स पर "peerreview" प्लगइन पर संक्षेप में देखा, और इससे बहुत निराश थे।

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

हमें किसी भी विवरण में अन्य प्लगइन (CodeReviewPlugin) की समीक्षा करने का मौका नहीं मिला है।

Answer 3

मुझे लगता है कि पीरकोड समीक्षा आपके इच्छित चीज़ों के लिए बेहतर है।

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

यह ठीक है अगर आपके पास कोई है (जैसे आर्किटेक्ट या लीड) जो कोड पर सक्रिय रूप से देख रहा है और समस्याग्रस्त हो सकता है जो पहचान कर रहा है।

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

आप कुछ है जो प्रतिबद्ध के साथ संबद्ध करेगा और डिफ संभालती के लिए देख रहे हैं, तो देखने के लिए ReviewBoard (a DJango app):

Answer 4

मैं पीरकोड समीक्षा के साथ भी निराश हूं। यह एक विशिष्ट संशोधन के लिए टिप्पणी करता है, और जब आप समीक्षा के लिए एक नया संशोधन "पुनः सबमिट" करते हैं, तो आप पुरानी समीक्षा बंद कर रहे हैं और एक नया खोल रहे हैं - लेकिन सभी टिप्पणियां केवल पुरानी समीक्षा पर ही रहती हैं! तो नए स्रोत के साथ एक टिप्पणी देखने के लिए कोई आसान तरीका नहीं है जो इसे संबोधित करता है। प्रतिबद्धताओं/diffs की समीक्षा के लिए समर्थन की कुल कमी के साथ, यह PeerCodeReview मेरे लिए अनुपयुक्त बनाता है।

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

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

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

• यह ट्रैक करना अच्छा होगा कि पाठ के कौन से हिस्सों की समीक्षा में संशोधन किया गया है।
  यह महत्वपूर्ण नहीं है, क्योंकि समीक्षा आमतौर पर एक समय में एक अनुभाग होती है और मैन्युअल रूप से ट्रैक करने के लिए यह आसान है।

• कई छोटी स्वतंत्र टिप्पणियां हैं। प्रत्येक टिप्पणी को स्वतंत्र रूप से ट्रैक किया जाना चाहिए, एक प्रतिबद्ध के लिए एक "स्वीकृति/अस्वीकार" संकल्प।

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

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

मैं अभ्यास में शायद क्या करूँगा स्रोत के अंदर TODO टिप्पणियां डाल दें और इसके लिए फैंसी ट्रैक इंटरफ़ेस का उपयोग न करें। संस्करण नियंत्रण यह सुनिश्चित करेगा कि टिप्पणियां रहें जहां वे संपादन के बीच हैं।

[LaTeX विशेष रूप से, मैं शायद अच्छी तरह से टिप्पणी प्रदर्शित करने के लिए todonotes और/या fixme संकुल का उपयोग करेंगे के लिए, और हो सकता है latexdiff दृश्य डिफ ​​के लिए।] मैं संपादित करेंगे इस पर बाद में रिपोर्ट करने के लिए कि यह कैसे हो गया ...

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