जब कोड समीक्षा के लिए प्रस्तुत कोड बहुत जटिल प्रतीत होता है तो क्या करें?

Question

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

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

Comments

प्रकट होता है या है? स्रोत फ़ाइलों का त्वरित माप आपके संदेह की पुष्टि या खंडन करेगा। मापने के बाद कोड की समीक्षा में केवल माप संख्या लाएं और जटिलता संख्याओं को नीचे लाने के लिए एक रीफैक्टरिंग सुझाएं।

— जॉन रेन्नोर

संबंधित: मैं समीक्षा के दौरान दूसरों के बुरी तरह से डिज़ाइन किए गए कोड में सुधार का सुझाव कैसे दे सकता हूं?

— gnat

के संभावित डुप्लिकेट आप जब कोड की समीक्षा अभी भी कठिन है क्या करते हो?

— बिल

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

— पीटर गेकर्न्स

@PieterGeerkens या, शायद, यह बहुत जटिल है क्योंकि यह एक जटिल समस्या को हल कर रहा है?

— केसी

Answer 1

यदि इसकी समीक्षा नहीं की जा सकती है, तो यह समीक्षा पारित नहीं कर सकती है।

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

यदि यह बहुत जटिल है, तो यह SOLID सिद्धांतों के एक टन का उल्लंघन कर रहा है । रिफलेक्टर, रिफलेक्टर, रिफलेक्टर। इसे ठीक से नामित कार्यों में तोड़ दें जो बहुत कम, सरल करते हैं। आप इसे साफ कर सकते हैं और आपके परीक्षण के मामले यह सुनिश्चित करेंगे कि यह सही काम करना जारी रखे। आपके पास परीक्षण के मामले हैं, है ना? यदि नहीं, तो आपको उन्हें जोड़ना शुरू करना चाहिए।

Comments

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

— डेविड ग्रिनबर्ग

अच्छा उत्तर। यह "कोड समीक्षा" के उद्देश्य पर निर्भर करता है। पठनीयता एक बात है, एक और संरचना - लेकिन उनके बहुत निकट से संबंधित। fwiw मैं कुछ खुले स्रोत के साथ काम कर रहा हूं, जो MAJOR वाहिनी द्वारा लिखा गया है, और यह लगभग अपठनीय है क्योंकि var और fn नाम इतने बाल-दिमाग वाले हैं।

@DavidGrinberg सभी व्यावहारिक उद्देश्यों के लिए, "आप छह महीने में" एक पूरी तरह से अलग व्यक्ति हैं।

— क्राइसिस -ऑन स्ट्राइक-

कुछ समय के लिए कोड को दूर रखें (लंबे समय तक उसके लिए सब कुछ याद न रखने के लिए)। मूल कोडर से इसकी समीक्षा करने को कहें। देखें कि क्या HE इसे समझता है।

— नेल्सन

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

— कोड़ी ग्रे

Answer 2

आपके द्वारा उल्लिखित सब कुछ एक कोड समीक्षा में इंगित करने के लिए पूरी तरह से वैध है।

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

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

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

Answer 3

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

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

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

Comments

शानदार टिप्पणी! "अधिकांश कोड इतना अधिक सोखता है कि इसे आसानी से पंक्ति में 10 बार परावर्तित किया जा सकता है, हर बार अधिक पठनीय हो सकता है" लड़का, क्या मैं ऐसा करने का दोषी हूं :)

— डीन रेडक्लिफ

"अधिकांश कोड इतना अधिक सोखता है कि इसे आसानी से पंक्ति में 10 बार रिफलेक्ट किया जा सकता है, हर बार अधिक पठनीय हो सकता है।" वास्तव में, यह वास्तविक दुनिया में ऐसा ही है।

— पीटर मोर्टेंसन

@PeterMortensen यह वास्तव में सच है कि आप वास्तविक दुनिया में बहुत कुछ पाते हैं। लेकिन उस तरह से कोड लिखना किसी के हित में नहीं है। मुझे लगता है कि इस तरह से दो कारण हैं। डेवलपर्स को प्राप्त होने वाली शिक्षा शिक्षण में बहुत कम प्रयास करती है कि पठनीय कोड कैसे लिखा जाए। और कुछ व्यवसायों में इसे समय की बर्बादी के रूप में माना जाता है: "यदि डेवलपर ने पहले से ही काम करने वाला कोड लिखा है, तो हमें यह ध्यान रखना चाहिए कि क्या यह पठनीय है या नहीं? बस बात को जहाज करें।"

— कैस्परल्ड

Answer 4

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

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

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

एक अन्य उत्तर में कहा गया है कि कुछ लोगों का कोड 10 बार रिफलेक्ट किया जा सकता है, हर बार अधिक पठनीय बन सकता है। यह सिर्फ दुख की बात है। यह एक डेवलपर है जिसे एक अलग नौकरी की तलाश करनी चाहिए।

Comments

मुझे अपने कोड को 10 बार रिफलेक्टर करने में बहुत कम समय लगता है, फिर मुझे कोड का पहला संस्करण लिखने में समय लगता है। अगर किसी और को पता है कि मैं इस refactoring मैं विफल रहा है किया है।

— इयान

Answer 5

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

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

Comments

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

— gnat

@ नागट: एक के लिए, क्योंकि यह असभ्य है। आप बेहतर देखते हैं जब आप समझाते हैं कि कोड में क्या गलत है और दूसरे व्यक्ति को इसे सुधारने में मदद करने के लिए प्रयास करें। ऐसा करने वाली एक बड़ी कंपनी में अन्यथा आप दरवाजे से जल्दी बाहर निकल सकते हैं। खासकर यदि आप किसी वरिष्ठ व्यक्ति के कोड की समीक्षा कर रहे हैं।

— नियोलिस्क

उस मामले मैं ऊपर कहा गया है, यह बड़े स्थापित कंपनी है कि बस के बारे में पर्याप्त सावधान रहने की हुआ में था नहीं दरवाजे से बाहर उनके सबसे योग्य डेवलपर्स रही, कम से कम सीधे अपनी तकनीकी विशेषज्ञता को साझा करने के आधार पर नहीं है जब करने के लिए कहा

— कुटकी

@gnat: दृष्टिकोण "रिफैक्टर। अब" नीचे की ओर काम कर सकता है, अर्थात जब 10+ वर्षों के अनुभव वाला एक वरिष्ठ डेवलपर किसी ऐसे जूनियर डेवलपर को रिफ्लेक्टर कहता है जिसे 1 महीने पहले बिना किसी अनुभव या इसी तरह की स्थिति के साथ काम पर रखा गया था। ऊपर की ओर - आप एक समस्या हो सकती है। क्योंकि आप नहीं जानते होंगे कि दूसरे डेवलपर के पास कितना अनुभव है, इसलिए सम्मान को डिफ़ॉल्ट व्यवहार मानना ​​सुरक्षित है। यह आपको यकीन नहीं होगा।

— नियोलिस्क

@ नोलिस्क: एक अनुभवी डेवलपर, जिसे समय के दबाव में कोड लिखना पड़ता है और जानता है कि यह बहुत अच्छा नहीं है केवल बहुत खुश हो सकता है यदि आप कोड को अस्वीकार करते हैं, तो उसे समय और इसे सुधारने का बहाना दें। PHB तय करना काफी अच्छा है जिससे देव दुखी होता है; समीक्षक यह तय कर रहा है कि यह काफी अच्छा नहीं है।

— gnasher729

Answer 6

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

एक सामान्य सुराग सुराग यह है कि पैच बहुत बड़ा है लेकिन इसका विवरण छोटा है: "$ FOO लागू करें।"

इस तरह के पैच को संभालने का एक उचित तरीका यह पूछना है कि इसे छोटे, स्व-निहित टुकड़ों की एक श्रृंखला में तोड़ दिया जाए। जैसे एकल-जिम्मेदारी सिद्धांत कहता है कि एक फ़ंक्शन को सिर्फ एक काम करना चाहिए, एक पैच को केवल एक चीज पर ध्यान देना चाहिए।

उदाहरण के लिए, पहले पैच में विशुद्ध रूप से यांत्रिक रिफ्लेक्टर हो सकते हैं जो कोई कार्यात्मक परिवर्तन नहीं करते हैं, और फिर अंतिम पैच (तों) कम विक्षेप और लाल झुंडों के साथ $ FOO के वास्तविक कार्यान्वयन और परीक्षण पर ध्यान केंद्रित कर सकते हैं।

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

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

इतना बड़ा पैच जैसे "$ FOO लागू करें" पैच की एक श्रृंखला में बदल जाता है:

1. Frobnicate का एक नया संस्करण पेश करें जो पुनरावृत्तियों की एक जोड़ी लेता है क्योंकि मुझे $ FOO लागू करने के लिए वेक्टर के अलावा अन्य दृश्यों के साथ इसे कॉल करने की आवश्यकता है।
2. नए संस्करण का उपयोग करने के लिए Frobnicate के सभी मौजूदा कॉलर्स को स्विच करें।
3. पुरानी Frobnicate हटाएं।
4. फ्रोबनेट बहुत ज्यादा कर रहा था। अपने स्वयं के तरीके में refrumple कदम को फैक्टर करें और उसके लिए परीक्षण जोड़ें।
5. परीक्षण के साथ Zerzify का परिचय दें। अभी तक उपयोग नहीं किया गया है, लेकिन मुझे $ FOO के लिए इसकी आवश्यकता होगी।
6. Zerzify और नई Frobnicate के संदर्भ में $ FOO लागू करें।

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

Comments

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

— जिमी ब्रेक-मैके

Answer 7

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

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

यदि जटिलता को विधि के स्तर पर अलग किया जाता है जिसे आमतौर पर पुनरावृत्त रूप से और अच्छे स्वचालित परीक्षणों के साथ ठीक किया जा सकता है।

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

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

Answer 8

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

अगर इसकी अच्छी तरह से जांच नहीं हुई है तो समीक्षा शुरू करने के लिए यह एक अच्छी जगह है।