कोड समीक्षाओं के लिए समय आवंटित किया गया

Question

यदि आप कोड समीक्षा कर रहे हैं

• कार्यान्वयन की तुलना में आप कोड समीक्षाओं पर कितना समय व्यतीत करते हैं?
• कोड समीक्षा में कितने परिवर्तन से गुजरना है?
• आपको लगता है कि यह बहुत होना चाहिए / अधिक होना चाहिए?

क्या प्रभावशीलता के बारे में कोई अध्ययन हैं?

[संपादित करें] उत्तर के लिए आप सभी का धन्यवाद, इस तरह के प्रश्न के लिए "विजेता" चुनना कठिन है, अन्य उत्तरों में भी बहुत सारी मूल्यवान जानकारी है।

Comments

उन तीन सवालों के मेरे जवाब "कोई नहीं", "उनमें से कोई नहीं" और "यह अधिक होना चाहिए।" :-)

— कार्सन63000

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

— केविन डी

अगला प्रश्न "क्यों" है - अधिकांश इसकी गुणवत्ता के बारे में सोचते हैं, लेकिन बड़ा लाभ तब होता है जब आप समझते हैं कि कोड का शैक्षिक मूल्य गुणवत्ता मूल्य से अधिक है।

— मटनज़

Answer 1

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

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

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

Comments

क्या आपके पास कोई विचार है कि यह कितना लेता है?

— पीटरचेन

Answer 2

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

Comments

मैंने अभी इस पुस्तक का आदेश दिया है। उम्मीद है कि एक दिलचस्प पढ़ना चाहिए।

— केविन डी

यह भी आदेश दिया। " फ्री " पुस्तक के लिए 20 दिनों तक इंतजार करना अजीब है - इंटरनेट पर सॉफ़्टवेयर बेचने वाली कंपनी से, कम नहीं।

— peterchen

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

— मटनज़

Answer 3

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

इसे परिमाणित करना कठिन है, क्योंकि सांसारिक परिवर्तन, जैसे नए विचार, पृष्ठ आदि की समीक्षा नहीं की जाती है। हम नए मॉड्यूल, प्रमुख अपडेट और रिफलेक्टरिंग की समीक्षा करते हैं। बड़े बदलावों के लिए, कोड समीक्षा 10% से 30% समय तक हो सकती है, लेकिन यह इसके लायक है।

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

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

हम टीम की बैठकें करते हैं जहां परिवर्तन और नई चीजों की घोषणा की जाती है, लेकिन वहां, हर कोई वास्तव में ध्यान नहीं देता है। संभवतः हमें कुछ अधिक कोड समीक्षा करनी चाहिए।

Answer 4

इसका कोई सही या गलत जवाब नहीं है। लेकिन जैसा कि मैंने पहले भी सुझाव दिया है - यदि कोड की समीक्षा किसी बाहरी टीम के सदस्य द्वारा की जाती है [अत्यधिक अनुशंसित विधि] तो यह विकास के प्रयास का लगभग 30% से 35% तक हो सकता है । लेकिन अगर यह एक आंतरिक परियोजना टीम के सदस्य द्वारा किया जाता है, जो विकास टीम का हिस्सा था [अनुशंसित नहीं] तो यह विकास के प्रयास के लिए लिए गए समय के लगभग 20% के भीतर पूरा किया जा सकता है ।

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

Comments

धन्यवाद - और कोई पसीना नहीं, मैं एक "कितना" प्रश्न के लिए संख्या देखकर सराहना करता हूं!

— पीटरचेन

Answer 5

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

एकमात्र चेतावनी यह है कि यह नौकरशाही बनना शुरू कर सकता है और संगठन संस्कृति पर निर्भर करता है।

Comments

मैं कुछ व्यावहारिक डेटा की तलाश कर रहा हूं, इसलिए मुझे उम्मीद की गई सीमा का कोई भी विचार मिलता है।

— पीटरचेन