क्या एक कोड समीक्षा जो केवल कोड टिप्पणियों का उपयोग करता है एक अच्छा विचार है?

पूर्व शर्त

टीम DVCS का उपयोग करती है
आईडीई टिप्पणी पार्सिंग का समर्थन करता है (TODO और आदि की तरह)
CodeCollaborator जैसे उपकरण बजट के लिए महंगे हैं
जेरिट जैसे उपकरण स्थापित करने या उपयोग करने योग्य नहीं के लिए बहुत जटिल हैं

कार्यप्रवाह

लेखक केंद्रीय रेपो सुविधा शाखा पर कहीं प्रकाशित करता है
समीक्षक इसे प्राप्त करते हैं और समीक्षा शुरू करते हैं
कुछ प्रश्न / मुद्दा समीक्षक के मामले में विशेष लेबल के साथ टिप्पणी करें, जैसे "आरईवी"। इस तरह का लेबल उत्पादन कोड में नहीं होना चाहिए - केवल समीक्षा चरण पर:
```
$somevar = 123;
// REV Why do echo this here?
echo $somevar;
```
जब समीक्षक पोस्ट टिप्पणियाँ समाप्त करता है - यह सिर्फ बेवकूफ संदेश "टिप्पणियों" के साथ होता है और पीछे धकेलता है
लेखक फीचर शाखा को वापस खींचता है और उसी तरह से टिप्पणियों का जवाब देता है या कोड में सुधार करता है और इसे वापस धक्का देता है
जब "आरईवी" टिप्पणी चली गई तो हम सोच सकते हैं, कि समीक्षा सफलतापूर्वक समाप्त हो गई है।
लेखक अंतःक्रियात्मक रूप से सुविधा शाखा को तोड़ता है, उन "टिप्पणी" को हटाने के लिए इसे स्क्वाश करता है और अब किसी भी कार्रवाई को विकसित करने या बनाने के लिए फीचर को मर्ज करने के लिए तैयार है जो सामान्य रूप से सफल आंतरिक समीक्षा के बाद हो सकता है

आईडीई समर्थन करते हैं

मुझे पता है, कि कस्टम टिप्पणी टैग ग्रहण और netbeans में संभव हैं। यकीन है कि यह भी blablaStorm परिवार में होना चाहिए।

ग्रहण में कस्टम फ़िल्टर किए गए कार्य-टिप्पणियों का उदाहरण

प्रशन

क्या आपको लगता है कि यह पद्धति व्यवहार्य है?
क्या आप भी कुछ ऐसा ही जानते हैं?
इसमें क्या सुधार किया जा सकता है?

— gaRex
स्रोत

अच्छा सवाल है, लेकिन नैपकिन के साथ इसका कोई लेना देना नहीं है - एक महान शीर्षक नहीं।

— MarkJ

@MarkJ इसे नाम कैसे दिया जाए? मेरा मतलब है कि हस्तकला, कुटीर, घर-निर्मित। रूसी में हमारे पास "на коленке" वाक्यांश है। कुछ स्थिर नहीं, आदर्श नहीं, गैर-ठोस जैसा, लेकिन वह काम करता है।

— गैलेक्स

@MarkJ, gaRex: इस नए शीर्षक के बारे में क्या? यदि आप इसे इस प्रश्न के लिए उपयुक्त नहीं पाते हैं, तो उल्टा महसूस करें।

— आर्सेनी मूरज़ेंको

@ मेनमा, यह ठीक है

— गैरेक्स

एटलसियन क्रूसिबल अनिवार्य रूप से 10 डेवलपर्स के लिए मुफ्त है। यह मेरे द्वारा उपयोग किए जाने वाले सर्वोत्तम कोड समीक्षा टूल भी होता है। टिप्पणियों का दृष्टिकोण व्यवहार्य है, लेकिन राज्य को ट्रैक करना कठिन बना सकता है।

— एंड्रयू टी फिनेल

जवाबों:

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

अभी भी कुछ कमियां हैं:

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

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

ऐलिस एक वैकल्पिक वाक्यविन्यास का सुझाव देता है, और कोड को एरिक पर वापस भेजता है। वह इस वैकल्पिक वाक्यविन्यास का उपयोग करके कोड को फिर से लिखता है जिसे वह सही ढंग से समझने में विश्वास करता है, और संबंधित // BLAटिप्पणी को हटा देता है ।

अगले हफ्ते, वह दूसरी समीक्षा के लिए कोड प्राप्त करती है। क्या वह वास्तव में यह याद रख पाएगी कि उसने अपनी पहली समीक्षा के दौरान यह टिप्पणी की थी कि एरिक ने इसे कैसे हल किया?

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

बेशक, वही समस्या किसी अन्य टिप्पणी के साथ मौजूद है; उदाहरण के लिए उत्पादन में TODO टिप्पणियों के बहुत सारे हैं (सबसे उपयोगी एक सहित: "TODO: नीचे दिए गए कोड को टिप्पणी करें"), और बहुत सारी टिप्पणियाँ जो कि संबंधित कोड होने पर अपडेट नहीं की गई थीं।

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

विशेष रूप से, यदि मूल समीक्षा में स्पष्टीकरण की आवश्यकता होती है, तो समीक्षक और समीक्षक एक चर्चा शुरू करेंगे । न केवल आप अपने आप को बड़े बीएलए टिप्पणियों के साथ पाएंगे, बल्कि उन चर्चाओं से संस्करण नियंत्रण के लॉग को भी दूषित किया जाएगा ।
आप वाक्यविन्यास (जो TODO टिप्पणियों के लिए भी मौजूद हैं) के साथ छोटे मुद्दों का सामना कर सकते हैं । उदाहरण के लिए, क्या होगा यदि एक लंबी "// बीएलए" टिप्पणी कई पंक्तियों पर हो, और कोई इसे इस तरह से लिखने का फैसला करता है:
```
// BLA This is a very long comment which is way beyond 80 characters, so it actually
// fills more then one line. Since the next lines start with slashes, but not "BLA"
// keyword, the IDE may not be able to show those lines, and display only the first one.
```
और अंत में एक छोटे और बहुत ही व्यक्तिगत नोट के रूप में: एक कीवर्ड के रूप में "बीएलए" का चयन न करें। यह बदसूरत लगता है। ;)

— आर्सेनी मूरज़ेंको
स्रोत

"यह जानने के लिए कि वास्तव में समीक्षित बिंदु कैसे लागू किए गए" हां :) केवल समीक्षक की ईमानदारी। यहां हमारे पास टूल से अधिक पॉलिसी है।

— गै्रक्स

"लोग लोग हैं" हां :( हमारे पास पहले से ही इन TODOs के लाखों लोग हैं। आईडीई में इस तरह की सुविधा के लिए सिर्फ इनकार किया जा सकता है?

— gaRex

"संस्करण नियंत्रण के लॉग को प्रदूषित करें" इसके लिए सभी कार्य स्टैंडअलोन सुविधा शाखा में हैं, जिसे बाद में स्क्वैश और विलय में विकसित किया जा रहा है। हो सकता है कि यह डीवीसीएस में साधारण हुक द्वारा किया जा सकता है। लेकिन जैसा कि मुझे कोड-समीक्षा टूल से लेकर IDEs और DVCS तक सभी जटिलताएं दिखाई देती हैं।

— गै्रक्स

"वाक्यविन्यास के साथ मामूली समस्याएं" क्या यह मुद्दा नहीं हो सकता है? वे REV`s केवल कुछ मार्करों के रूप में हैं जो जल्दी से पैनल से इसमें जाते हैं।

— गैरेक्स

@gaRex: तब आपकी टीम के सदस्यों को आमने-सामने की बैठक की तारीख के बारे में सहमत होने के लिए ईमेल का उपयोग करना चाहिए ;-)

— Doc Brown

मैं एक साथी दस्तावेज़ के साथ कोड में टिप्पणियों को पूरक करूंगा। यह निष्कर्षों को संक्षेप में प्रस्तुत करेगा और टिप्पणियों को हटाए जाने के बाद जीवित रहेगा। इस के फायदे होंगे:

सघनता। यदि व्यक्ति नियमित रूप से यह जांचने में विफल रहता है कि एक पॉइंटर पास नहीं है (तो या जिस भाषा का आप उपयोग कर रहे हैं, उसमें कोई अन्य सामान्य शुरुआती त्रुटि) तो समीक्षक उस प्रभाव के दर्जनों REV टिप्पणियाँ छोड़ सकता है, और दस्तावेज़ में कह सकता है " मुझे 37 स्थान मिले जहां बिंदुओं को पहले सूचीबद्ध नहीं किया गया था "उन सभी को सूचीबद्ध किए बिना
प्रशंसा के लिए जगह। एक टिप्पणी की तरह REV this is a nice designसिर्फ अजीब लगता है, लेकिन मेरी कोड समीक्षाओं में अक्सर अनुमोदन के साथ-साथ सुधार भी शामिल होते हैं
अन्तरक्रियाशीलता। आपका नमूना टिप्पणी है "आपने ऐसा क्यों किया?" और यह एक बहुत ही विशिष्ट है। एक टिप्पणी-केवल दृष्टिकोण एक बातचीत का समर्थन नहीं करता है। व्यक्ति अपना कोड बदल सकता है और टिप्पणी को हटा सकता है, या टिप्पणी को हटा सकता है। लेकिन "आपने ऐसा क्यों किया?" और "कृपया इसे बदल दें, यह गलत है" एक ही बात नहीं है।
कीर्तिमान बना रहे। बाद में समीक्षक यह जाँच सकते हैं कि कोड वास्तव में बदला गया था, या टिप्पणियों को हटा दिया गया था। वे यह भी जांच सकते हैं कि टिप्पणियों को "बोर्ड पर लिया गया है" और डेवलपर अब बाद की समीक्षा में समान गलतियां नहीं कर रहा है।

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

— केट ग्रेगरी
स्रोत

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

— गैलेक्स

"कॉम्पैक्टनेस" - मुझे लगता है कि यह एक टिप्पणी द्वारा किया जा सकता है जैसे "// आरईवी ड्यूड, हमारे पास 37 स्थान हैं जहां पॉइंटर्स को पहले चेक नहीं किया गया था, जिसमें यह भी शामिल है। कृपया

— आरटीएफएम

"स्तुति के लिए जगह" - यह भी संभव है, लेकिन स्क्वैश के बाद खो जाएगा :( मैं पहले से ही एक मुद्दा देखता हूं - जब हम

— स्क्वैश

"अन्तरक्रियाशीलता" - लेखक प्रारंभिक के नीचे एक और टिप्पणी में जवाब दे सकता है। जैसे विकिपीडिया शैली में।

— गैलेक्स

"व्यक्ति कर सकता है ... टिप्पणी हटाएं" - यह एक मुद्दा है। +1

— गॉरेक्स

दूसरों ने इस दृष्टिकोण की सीमाओं के बारे में बात की है। आपने उल्लेख किया कि जेरिट जैसे उपकरण स्थापित करना कठिन था - मेरा सुझाव है कि आप phabricator (http://www.phabricator.com) पर एक नज़र डालें। यह कोड समीक्षा प्रणाली है जिसे फेसबुक ने वर्षों से उपयोग किया है, और हाल ही में खुला हुआ था। यह स्थापित करना मुश्किल नहीं है, उत्कृष्ट वर्कफ़्लोज़ हैं, और अन्य टिप्पणियों में उल्लिखित सभी मुद्दों को हल करता है।

— एडम हप्प
स्रोत

वाह! हमें अपनी प्यारी रेडमाइन के बजाय इसे आजमाने की जरूरत है।

— 1

"जेरिट" मैंने इसे स्थापित किया - यह इतना कठिन नहीं था। मैं इसका उपयोग करने में विफल हूं! और इसमें बदसूरत UI और वर्कफ़्लो भी हैं।

— 1

@gaRex हम Redmine के साथ समानांतर में Reviewboard ( reviewboard.org ) का उपयोग करते हैं । वे विभिन्न उद्देश्यों की सेवा करते हैं ताकि ठीक हो। और आप RB को Redmine मुद्दों से लिंक करने के लिए सेटअप कर सकते हैं ...

— जोहान्स एस।

@JohannesS। आप किस vcs का उपयोग कर रहे हैं? इसके अलावा क्या आपके पास उनके एकीकरण के बारे में कुछ तैयार है या विकि है? इस तरह के एक के लिए अच्छा है।

— गॉरेक्स

@gaRex देर से उत्तर के लिए क्षमा करें। हम SVN का उपयोग करते हैं, लेकिन RB git का समर्थन करता है (वास्तव में, RB लोग स्वयं git का उपयोग करते हैं)। मेरा सुझाव है कि आरबी की वेबसाइट पर एक नज़र डालें। एक ऑनलाइन डेमो उपलब्ध है (उदाहरण के लिए check.reviewboard.org/r/101 देखें )

— जोहान्स एस।