चुस्त प्रथाएँ: कोड समीक्षा - समीक्षा विफल करें या कोई मुद्दा उठाए?


53

एक 2 सप्ताह के स्प्रिंट के अंत में और एक कार्य की एक कोड समीक्षा होती है, समीक्षा में हम एक फ़ंक्शन की खोज करते हैं जो काम करता है, पठनीय है, लेकिन यह काफी लंबा है और इसमें कुछ कोड बदबू आ रही है। आसान रिफैक्टर का काम।

अन्यथा कार्य किए गए की परिभाषा फिट बैठता है।

हमारे पास दो विकल्प हैं।

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

मेरा सवाल यह है: क्या किसी भी तरह की अंतर्निहित समस्याएं या विचार हैं, जो असफल होने के बजाय समीक्षा की पीठ से टिकट काटते हैं?

जिन संसाधनों को मैं पा सकता हूं और आमतौर पर 100% या कुछ नहीं के रूप में डिटेल कोड समीक्षाएँ पढ़ता हूं, लेकिन मुझे लगता है कि आमतौर पर यथार्थवादी नहीं है।


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

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

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

9
@ErdrikIronrose: आह, इसलिए समीक्षा के तहत कहानी पर काम करते समय कोड गंध तरीका नहीं बनाया गया है , लेकिन पहले से ही अस्तित्व में है? यह एक महत्वपूर्ण अंतर है - प्रश्न को संपादित करने पर विचार करें।
स्लेजके

1
@vlaz आपको अपनी टिप्पणी से एक उत्तर देना चाहिए
Ister

जवाबों:


67

क्या किसी असफल समस्या या विचार की समीक्षा के पीछे एक असफलता के बजाय एक टिकट को बढ़ाने के साथ-साथ असफलता है?

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

समीक्षा में हम एक फ़ंक्शन की खोज करते हैं

हालाँकि, मुझे लगता है कि यहाँ फ़ंक्शन कुछ ऐसा है जो वर्तमान परिवर्तन द्वारा जोड़ा गया था। इस मामले में, टिकट विफल होना चाहिए क्योंकि कोड ने गंध परीक्षण पास नहीं किया था।

यदि आप पहले से ही इसे तैयार नहीं करते हैं, तो आप कहां रेखा खींचेंगे? आपको स्पष्ट रूप से नहीं लगता कि यह कोड अपने मौजूदा रूप में कोडबेस में रहने के लिए पर्याप्त रूप से साफ है; तो आप टिकट को पास देने पर विचार क्यों करेंगे?

कोड समीक्षा में विफल, ताकि टिकट इस स्प्रिंट में बंद न हो, और हम मनोबल पर थोड़ा प्रहार करें, क्योंकि हम टिकट को पास नहीं कर सकते।

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

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

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

यदि मूल टिकट के कार्यान्वयन में कोड की गंध होती है, तो इसे मूल टिकट में संबोधित किया जाना चाहिए। आपको केवल एक नया टिकट बनाना चाहिए, यदि कोड की गंध को मूल टिकट के लिए सीधे जिम्मेदार नहीं ठहराया जा सकता है (उदाहरण के लिए, एक "पुआल जिसने ऊंट की पीठ को तोड़ दिया" परिदृश्य)।

जिन संसाधनों को मैं पा सकता हूं और आमतौर पर 100% या कुछ नहीं के रूप में डिटेल कोड समीक्षाएँ पढ़ता हूं, लेकिन मुझे लगता है कि आमतौर पर यथार्थवादी नहीं है।

पास / असफल स्वाभाविक रूप से एक द्विआधारी राज्य है , जो स्वाभाविक रूप से सभी या कुछ भी नहीं है।

आप यहाँ जिस बात का जिक्र कर रहे हैं, मुझे लगता है, यह अधिक है कि आप कोड समीक्षाओं की व्याख्या सही कोड की आवश्यकता के रूप में करते हैं या अन्यथा इसे विफल कर रहे हैं, और ऐसा नहीं है।

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

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

अन्यथा कार्य किए गए की परिभाषा फिट बैठता है।

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


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

11
शानदार जवाब - दृढ़ लेकिन कठोर नहीं। एक स्पर्शरेखा बिंदु यह भी हो सकता है: हमें स्प्रिंट में इतनी देर से कोड समीक्षाएं कैसे मिलीं कि पूरे स्प्रिंट के विफल होने के बिना एक आसान रिफ्लेक्टर नहीं किया जा सकता है?
डैनियल

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

8
+1 प्रोग्रामर अच्छा महसूस कर सकते हैं जब उन्होंने अच्छा कोड लिखा हो। अपने गुणवत्ता नियंत्रण को दरकिनार करना मनोबल को सुधारने का जवाब नहीं है। मामूली मुद्दों के लिए एक सामयिक अस्वीकृति वैसे भी मनोबल को नुकसान पहुंचाने की संभावना नहीं है। यदि आपका मनोबल गुणवत्ता नियंत्रण को नियमित रूप से विफल करने के कारण पीड़ित है, तो इसका उत्तर यह है कि हर समय क्यूसी को विफल करने के बारे में कुछ किया जाए, मानकों को नहीं छोड़ा जाए।
jpmc26

1
@GregBurghardt: क्योंकि मैंने कई कंपनियों में समय सीमा के तर्क का दुरुपयोग होते देखा है, मैं केवल एक खराब समीक्षा पारित करने के लिए सहमत हूं, यदि केवल और इसके तत्काल रिफैक्टरिंग के लिए एक कार्य बनाया गया है और पहले रिलीज के बाद स्प्रिंट के लिए योजना बनाई गई है। जोड़ा समय लागत कोड गुणवत्ता को दरकिनार करने के लिए एक सार्थक प्रवेश बाधा जोड़ता है।
Flater

38

2 सप्ताह के स्प्रिंट के अंत में और एक कार्य में एक कोड की समीक्षा होती है [...] आसान रिफ्लेक्टर कार्य।

स्प्रिंट के अंत में पॉप क्यों होता है? जैसे ही आपको लगता है कि कोड हो गया है (या पहले भी) एक कोड समीक्षा होनी चाहिए । आपको अपनी प्रत्येक कहानी पूरी होने के साथ अपनी परिभाषा की जांच करनी चाहिए।

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

तो यह योग करने के लिए: हाँ, DoD द्विआधारी है। सफल या असफल। एक कोड समीक्षा बाइनरी नहीं है, यह एक चल रहे कार्य की तरह होना चाहिए। आप असफल नहीं हो सकते । यह एक प्रक्रिया है और अंत में यह किया जाता है। लेकिन अगर आप ठीक से योजना नहीं बनाते हैं, तो आप समय में उस "किए गए" चरण में नहीं पहुंचेंगे और स्प्रिंट छोर पर "नहीं किया गया" क्षेत्र में फंस गए हैं। यह मनोबल के लिए अच्छा नहीं है, लेकिन इसके लिए आपको योजना बनाने की आवश्यकता है।


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

20

सरल: आप परिवर्तन की समीक्षा करें । आप अन्यथा कार्यक्रम की स्थिति की समीक्षा नहीं करते हैं। यदि मैं 3,000 लाइन फ़ंक्शन में बग को ठीक करता हूं, तो आप जांचते हैं कि मेरे परिवर्तन बग को ठीक करते हैं या नहीं। और अगर मेरा परिवर्तन बग को ठीक करता है, तो आप परिवर्तन को स्वीकार करते हैं।

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

यह हास्यास्पद होगा यदि आप एक कोड समीक्षा के दौरान विकास प्राथमिकताओं को तय कर सकते हैं, और उस कारण के लिए मेरे बदलाव को अस्वीकार करना विकास प्राथमिकताओं को तय करने का प्रयास होगा।

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


4
मैं इस मामले परिवर्तन में लगता था ज्यादा से कार्य - यदि आप एक 3000 लाइन समारोह है कि वहाँ पहले से नहीं था (या पहले से एक 10 लाइन समारोह था) शुरू की है।
user3067860

3
सिद्धांत रूप में यह उत्तर बिल्कुल सही है। व्यवहार में ..... यदि सभी डेवलपर्स विश्वास करते हैं और प्रयास के खिलाफ संतुलित कोडिंग प्रथाओं का अभ्यास करते हैं, तो संभवतः आप इस मुद्दे पर बहुत बार नहीं चलेंगे और फिर यह उत्तर हाजिर होगा। हालाँकि .... ऐसा लगता है कि हमेशा एक या दो डेवलपर्स हैं जो अब 5 मिनट बचाने के लिए सब कुछ जल्दी और गंदा करते हैं; जबकि वे घंटों को दिनों या महीनों में अनदेखा करते हैं जो वे काम में जोड़ रहे हैं जो बाद में होगा। उन मामलों में, यह उत्तर केवल एक फिसलन ढलान है, जिससे पूरे सिस्टम को शुरू करना और फिर से डिज़ाइन करना है।
डंक

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

@ user3067860 यदि आपने 10 लाइन फ़ंक्शन को 3000 लाइन फ़ंक्शन में बदल दिया है - तो स्पष्ट रूप से विफल। यदि आपने 3000 लाइन फ़ंक्शन को 3010 में बदल दिया है - तो संभवतः पास करें। लेकिन क्या होगा अगर आपने 300 लाइन फ़ंक्शन ( निश्चित रूप से बहुत बड़ा) में 100 लाइन फ़ंक्शन (आमतौर पर थोड़ा बहुत बड़ा) बदल दिया है ?
मार्टिन बोनर

9

कोड समीक्षा में विफल, ताकि टिकट इस स्प्रिंट में बंद न हो, और हम मनोबल पर थोड़ा प्रहार करें, क्योंकि हम टिकट को पास नहीं कर सकते।

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

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


"प्रिय ग्राहक आपके पास एक और 2-3 सप्ताह के लिए आपकी सुविधा नहीं हो सकती है क्योंकि हमारे कोड ने काम किया है, लेकिन हमें यह पसंद नहीं आया कि यह कैसा दिखता है", ... कृपया हमारे प्रतियोगी पर न जाएं ... या सीईओ को बताएं !
RandomUs1r

6
@ RandomUs1r ग्राहकों के पास उस तरह की जानकारी नहीं होनी चाहिए। यह नहीं किया गया था क्योंकि इसके लिए पर्याप्त समय नहीं था और यही है। क्या ग्राहक तय करते हैं कि कोड कैसे लिखा जाना चाहिए? यदि आप अपने घर पर तारों को ठीक करने के लिए एक इलेक्ट्रीशियन को बुलाते हैं, तो क्या आप "केबल को बदलते हैं लेकिन जाँचने में परेशान नहीं होते हैं कि क्या वे सही केबल हैं"? या क्या आप अपने डॉक्टर से कहते हैं "मैं बीमार हूं - मुझे कुछ गोलियां दें लेकिन मुझे पहले निदान न करें"? कोड समीक्षा काम का एक अंतर्निहित हिस्सा होना चाहिए, न कि कुछ ग्राहक द्वारा निर्देशित।
वीएलजी

1
@ RandomUs1r: "" प्रिय डेवलपर, सुविधा पूर्ण क्यों नहीं हुई? " - उत्तर होना चाहिए" क्योंकि हमारे पास इसे स्वीकार्य स्तर तक बनाने के लिए पर्याप्त समय नहीं था ", हो सकता है कि इसके बाद" हम इसे दे सकें। अगर आप गुणवत्ता से समझौता करने को तैयार हैं तो आप। "
ब्रायन ओकले

1
@ RandomUs1r तो मूल रूप से आप कोड की गुणवत्ता का त्याग करना चाहते हैं, संभवत: बाद में सुविधाओं को लागू करने के लिए इसे और अधिक कठिन बना देगा। 2 दिन का फिक्स अब बहुत अच्छी तरह से आपको बचा सकता है 4 सप्ताह के बाद में। तो फिर यह "प्रिय ग्राहक, आपके पास एक और 2-3 सप्ताह के लिए अपनी सुविधा नहीं हो सकती है क्योंकि अब एक छोटी सी सुविधा को लागू करने में लंबा समय लगता है"। यह भी एक प्रेत का अंत है या यह एक प्रमुख समय सीमा है? यदि यह एक प्रमुख समय सीमा है, तो मैं अब विलय कर सकता हूं, अगले 2 दिनों में एक फिक्स लिख रहा हूं और समय सीमा के बाद पीआर को बढ़ा सकता हूं।
xyious

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

5

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

जब कोड समीक्षा के मुद्दों की बात आती है, तो कुछ तरीके हैं जिनसे आप इसे संभाल सकते हैं, और सही विकल्प कुछ कारकों पर निर्भर करता है।

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

लब्बोलुआब यह है कि जब आपको काम के साथ किया जाता है तो आपको इसके साथ किया जाना चाहिए। अगर डेवलपर ने जो काम किया है उससे बड़ी समस्याएं हैं, तो झंडा उठाएं और आगे बढ़ें। लेकिन आपको ऐसी स्थिति में नहीं होना चाहिए जहां स्प्रिंट के अंत से पहले घंटे हैं और आप अभी केवल समीक्षा कर रहे हैं। अपने संसाधनों को ओवर-कमिट करने या सहकर्मी की समीक्षा करने जैसी गंध आती है। (एक प्रक्रिया गंध)।


4

कोड समीक्षा मुद्दों को चित्रित करने में कोई अंतर्निहित समस्याएं नहीं हैं, लेकिन यह उन मुख्य मुद्दों की तरह लगता है, जिन पर आपको एक टीम के रूप में सहमत होने की आवश्यकता है:

  1. आपकी कोड समीक्षा का उद्देश्य क्या है?
  2. किसी कार्य मद के लिए कोड की समीक्षा का परिणाम परिभाषा से कैसे संबंधित है?
  3. यदि कोड समीक्षा एक गेटिंग टेस्ट के रूप में लागू होती है, तो कौन से मुद्दों को 'ब्लॉकर्स' माना जाता है?

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

यह वैसा ही है जैसे इकाई परीक्षण के दौरान एक इकाई परीक्षण विफल हो गया। आप बग को ठीक करेंगे, यूनिट टेस्ट को नजरअंदाज न करें, अगर यूनिट टेस्ट पास करना जरूरी हो गया हो।

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

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


1

यहाँ के उच्च मतदान वाले उत्तर बहुत अच्छे हैं; यह एक रिफैक्टरिंग कोण को संबोधित करता है।

ज्यादातर मामलों में, जब रिफैक्टरिंग मौजूदा कोड को समझ रहा है, तो अधिकांश काम; उसके बाद इसे बदलना आम तौर पर दो कारणों में से एक काम का छोटा हिस्सा है:

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

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

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

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

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

इस मामले में कि आप रिफैक्टरिंग के लिए एक अलग कहानी बनाने की सोच रहे हैं, कई मोर्चों पर चेतावनी संकेत है:

  1. आप कोडिंग के एक हिस्से के रूप में, लेकिन एक अलग ऑपरेशन के रूप में फिर से निर्माण करने के बारे में नहीं सोच रहे हैं, जिससे बदले में दबाव में आने की संभावना है।

  2. आप ऐसा कोड विकसित कर रहे हैं जो अगली बार किसी को इसके साथ काम करने की आवश्यकता को समझने के लिए अधिक काम आएगा, जिससे कहानियों को अधिक समय लगेगा।

  3. आप समय और ऊर्जा को बर्बाद करने वाली चीजें हो सकते हैं, जिनसे आपको ज्यादा फायदा नहीं होता है। (यदि कोई परिवर्तन बहुत बाद में होता है, तो किसी को अभी भी कोड को फिर से समझना होगा, वैसे भी; यह अधिक कुशलता से रिफैक्टरिंग जॉब के साथ संयुक्त है। यदि बाद में कोई परिवर्तन नहीं होता है, तो रिफैक्टरिंग किसी भी काम नहीं करता है। उद्देश्य पर सभी, शायद एक सौंदर्य को छोड़कर।)

तो इसका उत्तर यह है कि आइटम को विफल करने के लिए यह स्पष्ट करें कि आपकी प्रक्रिया में कुछ विफल हो गया है (इस मामले में, डेवलपर या टीम समीक्षा के लिए समय का आवंटन नहीं कर रही है और उन परिवर्तनों को लागू करने के लिए जो समीक्षा से बाहर आते हैं) और डेवलपर तुरंत काम जारी रखें आइटम पर।

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


1

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

आपका प्रश्न स्पष्ट रूप से "चुस्त प्रथाओं" पर कॉल करता है, इसलिए चलो चुस्त घोषणा पत्र (जोर मेरा) पर फिर से विचार करें:

हम सॉफ्टवेयर के विकास के बेहतर तरीकों को उजागर कर रहे हैं और इसे करने में दूसरों की मदद कर रहे हैं। इस काम के माध्यम से हम मूल्य पर आए हैं:

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
  • व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
  • अनुबंध बातचीत पर ग्राहक सहयोग
  • एक योजना के बाद बदलने का जवाब

यही है, जबकि दाईं ओर की वस्तुओं में मूल्य है, हम बाईं ओर की वस्तुओं को अधिक महत्व देते हैं।

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

सहयोग करना शुरू करें। असफल कोड समीक्षा बंद करो।


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

1
@ErdrikIronrose मैंने कभी उपयोग नहीं किया है - या उपयोग करने की आवश्यकता है - कोड समीक्षा "विफल" की शब्दावली। कोई कोड की समीक्षा करता है, सुधार के किसी भी संभावित बिंदुओं के आसपास चर्चा, उन बिंदुओं को संबोधित करने के बारे में निर्णय के बाद। इसमें कोई "पासिंग" या "फेलिंग" शामिल नहीं है, बस संचार और प्रगति है। मुझे यकीन नहीं है कि रबर स्टैम्प की आवश्यकता क्यों है।
एंट पी।

0

समीक्षा में हम एक फ़ंक्शन की खोज करते हैं जो काम करता है, पठनीय है, लेकिन यह काफी लंबा है और इसमें कुछ कोड बदबू आ रही है ...

क्या किसी असफलता या किसी समीक्षा के पीछे एक टिकट को बढ़ाने के बजाय, इसे विफल करने के बजाय कुछ अंतर्निहित समस्याएं या विचार हैं?

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

हमारे पास एक कहावत है "स्थगित पूर्णता पर प्रगतिशील सुधार चुनें"।

हमारे पास एक बहुत ही तरल प्रक्रिया है, और काफी अच्छी संख्या में 'अवधारणा के प्रमाण' सुविधाओं (1 या 2 प्रति स्प्रिंट) का निर्माण करते हैं जो इसे देव और परीक्षण के माध्यम से बनाते हैं लेकिन इसे कभी भी आंतरिक हितधारक समीक्षा (hmm) नहीं बनाते हैं, क्या हम इसके बजाय ऐसा कर सकते हैं ;), अल्फा, या बीटा ... कुछ बच, कुछ नहीं।

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


0

मेरी राय में इस समस्या को देखने के दो तरीके हैं:

  1. शैक्षणिक तरीका
  2. असली दुनिया तरीका है

शैक्षणिक रूप से बोलते हुए, कोड गुणवत्ता मानक पूरा नहीं होने पर एक PBI (उत्पाद बैकलॉग आइटम) की तैनाती को विफल करने के लिए अधिकांश कोड समीक्षा प्रक्रियाएं मौजूद हैं।

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


2
वास्तविक दुनिया में कोई भी टी के लिए फुर्तीला नहीं है - यह "फुर्तीली" नहीं होगा यदि हमारे पास बहुत कठोर नियम हैं, है ना?
पाओलो एबरमन

@ Pa @loEbermann मैं एक कंपनी के साथ एक मनोरंजक बातचीत कर रहा था जिसका मैंने एक समय में साक्षात्कार किया था। उन्होंने दावा किया कि उनकी प्रक्रिया चुस्त नहीं थी क्योंकि यह चुस्त पाठ्य पुस्तक का उदाहरण नहीं था। भले ही उन्होंने जो कुछ भी किया वह चपलता की भावना में था। मैंने इसे उन्हें बताया लेकिन केवल (अनिवार्य रूप से) के साथ मुलाकात की गई थी "नहीं, हम पत्र के लिए एक स्थापित चुस्त प्रक्रिया का पालन नहीं कर रहे हैं, भले ही हम अवधारणाओं को बहुत अधिक उधार लें। इसलिए, हम चुस्त नहीं हैं"। यह काफी विचित्र था।
वीएलएज

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

@ मुझे लगता है कि मेरा एक देव दृष्टिकोण से एक अलोकप्रिय दृष्टिकोण हो सकता है (मैं एक देव भी हूँ), लेकिन व्यवसाय वास्तव में पहले आना चाहिए, वे तनख्वाह पर हस्ताक्षर करते हैं और कुछ सम्मान के हकदार हैं। जहां तक ​​समय जाया करता है, मैं फिर से वास्तविक दुनिया की आपकी समझ को चुनौती दूंगा, और आपको यह महसूस करने की आवश्यकता है कि हमेशा संभव नहीं है और बहुत सारे स्प्रिंट तंग चलते हैं क्योंकि स्प्रिंट के अंत में भी देवों को सामान की आवश्यकता होती है। यह ऐसा नहीं है क्योंकि कोड का SOLID, एक विभाग प्रत्येक 2 सप्ताह में 1/10 दिन तक अपने पैरों को किक कर सकता है और कुछ भी नहीं कर सकता है, जो कि अल्पावधि में महान हो सकता है, लेकिन एक व्यवहार्य लंबा नहीं है।
रैंडमयूएस

@ RandomUs1r मैं वास्तविक दुनिया में भी काम करता हूं, मैं हर समय शॉर्टकट लेता हूं, और मैं हमेशा व्यवसाय पहले रखता हूं, इसलिए मुझे नहीं लगता कि मुझे यहां समझने में कमी है। लेकिन ओपी का वर्णन "हम सामान्य रूप से हमेशा यह अधिकार नहीं लेते हैं और यह सिर्फ एक मानक मामूली बोझ था" या वह प्रश्न पोस्ट नहीं कर रहा होता। जैसा कि मैंने अपने उत्तर में बताया कि यह एक प्रक्रिया समस्या की तरह दिखता है, और आप इसे ठीक करने से पहले प्रक्रिया को सही तरीके से करने का अभ्यास करते हैं।
कर्ट जे। सैम्पसन

-2

न ही । यदि यह कोड समीक्षा में विफल रहता है तो कार्य पूरा नहीं हुआ है। लेकिन आप व्यक्तिगत राय पर कोड समीक्षा विफल नहीं कर सकते। कोड गुजरता है; अगले कार्य के लिए आगे बढ़ें।

यह एक आसान कॉल होना चाहिए, और यह तथ्य कि यह सुझाव नहीं है कि आपके पास कोड समीक्षा के लिए पर्याप्त लिखित नियम स्पष्ट नहीं हैं।

  1. "फ़ंक्शन काफी लंबा है"। नीचे लिखें: फ़ंक्शंस एक्स लाइनों से कम लंबी होनी चाहिए (मैं सुझाव नहीं दे रहा हूं कि फ़ंक्शन की लंबाई के बारे में नियम एक अच्छी बात है)।

  2. "कुछ कोड महक हैं"। नीचे लिखें: सार्वजनिक फ़ंक्शंस में कार्यक्षमता और प्रदर्शन के लिए यूनिट परीक्षण होना चाहिए, सीपीयू और मेमोरी उपयोग दोनों को सीमा x और y के तहत होना चाहिए।

यदि आप एक कोड समीक्षा पास करने के नियमों को निर्धारित नहीं कर सकते हैं, तो आपको ये मामला मिलेगा कि मूल रूप से 'आपको पसंद नहीं है' कोड क्या है।

क्या आपको 'कोड पसंद नहीं है' आपको विफल होना चाहिए? मैं कहूंगा कि नहीं। आप स्वाभाविक रूप से गैर-कोड पहलुओं के आधार पर पास / असफल होना शुरू करेंगे: क्या आप व्यक्ति को पसंद करते हैं? क्या वे अपने मामले के लिए दृढ़ता से बहस करते हैं या जैसा कि उन्हें बताया गया है? जब वे आपकी समीक्षा करते हैं तो क्या वे आपका कोड पास करते हैं?

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

वह कब तक जोड़ेगा? क्या एक ही समीक्षक बाद की कोड समीक्षा करेगा और पहले समीक्षक से सहमत होगा या वे अतिरिक्त बदलाव पाएंगे? क्या होगा अगर मैं बदलाव से असहमत हूं और दूसरी राय की तलाश करते हुए इसे करना छोड़ दूं या मामले पर बहस करूं?

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

पुन: नियम लिखना असंभव है !!

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

नीचे दिए गए नियमों को लिखें और बीयर के बारे में चर्चा करें कि क्या कोड 'अच्छा' बनाता है।


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

5
"फ़ंक्शंस" की तरह एब्सोल्यूट होना चाहिए एक्स लाइन्स से कम लंबा होना चाहिए " जवाब नहीं है , या तो।
ब्लरफ्ल

2
ब्लरफ्ल के साथ सहमत। फ़ंक्शंस (सामान्य रूप से) 20 से अधिक लाइनें नहीं होनी चाहिए। लेकिन इसे पूर्ण नियम बनाना एक भूल है। विशिष्ट परिस्थितियां हमेशा सामान्य नियमों को ट्रम्प करती हैं : यदि आपके पास अपने कार्य को 20 से अधिक लाइनों को बनाने का एक अच्छा कारण है, तो ऐसा करें।
मैट मेस्मिथिथ

1
आपको एक कानूनी विनिर्देश के लिए लिखे गए कोड के लिए नियमों की आवश्यकता नहीं होनी चाहिए ... आपके पास बस दिशानिर्देश हो सकते हैं और तथ्य यह है कि आप सभी संभवतः वयस्क हैं जो एक ही अंतिम लक्ष्य (काम करने योग्य, पठनीय कोड) को पूरा करने की कोशिश कर रहे हैं। टीम के सभी सदस्यों का वास्तव में टीम में निवेश करना और एक साथ काम करने के लिए तैयार होना, स्क्रम के लिए केंद्रीय है, इसलिए यदि आपके पास ऐसा नहीं है, तो शायद स्क्रम आपकी टीम के लिए वैसे भी नहीं है।
user3067860

2
@ इवान ज़रूर मेरा कहना सिर्फ इतना था कि ओपी के पास एक नियम नहीं, बल्कि कार्य की दिशानिर्देश की लंबाई है । जहां कहीं भी सीमा निर्धारित की गई है, यह लोगों को हार्ड-टू-मेंटेन कोड रखने में मदद करने के लिए सलाह प्रदान करता है, लेकिन यह कभी भी पूर्ण नियम नहीं है। यदि (जैसा कि ओपी कहता है) यह वास्तव में पूरी तरह से पठनीय है, और समीक्षक सहमत हैं कि यह पूरी तरह से पठनीय है, और इसे उचित रूप से परीक्षण करने में कोई समस्या नहीं है, तो फ़ंक्शन सही आकार की परिभाषा है। समीक्षा में शायद यह कहते हुए एक-लाइन का नोट मिलता है कि "हाँ यह सलाह की तुलना में लंबा है, लेकिन हम सहमत हैं कि यह ठीक है", और काम किया। उस बिंदु के बाद Refactoring सोना चढ़ाना है।
ग्राहम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.