परिचय
यह पहली बार नहीं है जब मुझे संबंधित प्रश्न पूछे गए हैं:
"आप इतने सारे कार्य क्यों कर रहे हैं?"
"आप किसी फ़ंक्शन में एक-बार-उपयोग कोड क्यों बनाते हैं?";
"बाकी आपके फ़ंक्शन नामकरण सम्मेलनों से परिचित नहीं हैं। वे इसके साथ कैसे काम करेंगे? ” इसलिए, मैं समस्या के बारे में अपने दृष्टिकोण का वर्णन करूंगा। खैर, समुदाय आपको बताएगा कि किसके लिए प्रयास करना है।
स्थिति
इस प्रक्रिया में, एक अलग कोड होता है। इसमें नई त्रुटियों को जोड़ने के साथ, इसे सही त्रुटियों के साथ होना चाहिए। नया कोड भी लिखा जा रहा है, जिसके साथ अन्य लोग बाद में काम करेंगे। मैं कई स्थितियों का वर्णन करूंगा:
स्थिति # 1 कोड बहुत कुछ करता है
कक्षा में एक प्रभावी तरीका होता है जो कक्षा से ही थोड़ा छोटा होता है, जबकि इसमें सभी तर्क और बुनियादी ढाँचे का कोड होता है;
सिचुएशन नंबर 2 कोड के तर्क का अध्ययन करने के बाद ही स्पष्ट होता है
हालांकि कोड छोटा है, लेकिन यह समझना काफी मुश्किल है कि यह क्या करता है;
स्थिति संख्या 3 नई कार्यक्षमता जोड़ी गई है
एक काफी जटिल कोड है जिसमें आपको नए कार्यों को जोड़ने की आवश्यकता है;
स्थिति संख्या 4 एक नया कोड लिखा गया है
कोड में कम कनेक्टिविटी, अच्छा परीक्षण कवरेज, रखरखाव, आदि होना चाहिए।
कारणों
इन स्थितियों में से प्रत्येक में, मैं कम से कम refactoring करने की कोशिश करता हूं। मैं कोड को अधिक समझने योग्य और सरल बनाता हूं।
सबसे अधिक बार मैंने विधि में कोड डाला। अगर एपीआई अनुमति देता है, तो मैं और अधिक जटिल रीफैक्टरिंग कर रहा हूं। सशर्त अभिव्यक्ति, यदि उन्हें तुरंत नहीं समझा जाता है, तो मैं एक स्पष्ट नाम के साथ एक विधि में डालने की कोशिश करता हूं।
मुझे हमेशा नियम द्वारा निर्देशित किया जाता है:
"कोड को पढ़ा जाना चाहिए, संकलित और निष्पादित नहीं किया जाना चाहिए", जो कि फाउलर द्वारा वर्णित विचारधारा के अनुसार है।
प्रत्येक फ़ंक्शन का एक अच्छा नाम होना चाहिए, यदि वह ऐसा नहीं करता है जो नाम में वर्णित है, तो इसके लिए एक नया नाम चुना जाना चाहिए। टिप्पणियाँ जो कोड अनुवाद हैं, वे बेमानी हैं (अपवाद - त्रुटि)।
मैं हमेशा पहले की तुलना में कोड को कम महक छोड़ने का प्रयास करता हूं। कोड के अंशों को कई द्वारा पढ़ा जा सकता है, विशेष रूप से फाउलर द्वारा।
परिणाम
लगभग हर अधिक या कम महत्वपूर्ण संशोधन के बाद, मुझे ऊपर वर्णित प्रश्न पूछे जाते हैं। वे कहते हैं कि कोड कम स्पष्ट हो गया है, वांछित रेखा को ढूंढना मुश्किल हो गया है, आदि।
कारणों
वास्तव में, समस्या कोड में और डेवलपर में है जो कोड के लिए उपयोग किया जाता है।
मैं एक प्रयोग करने का प्रस्ताव करता हूं।
एक अज्ञात कोड लें जो अच्छी तरह से लिखा गया हो। इसमें 5 से कम जटिलता वाले तरीके होने चाहिए (जिसका अर्थ है
साइक्लोमैटिक मूल्यांकन की एक सरल व्याख्या)। यदि आपके लिए इस कोड को पढ़ना मुश्किल होगा, तो ध्यान दें कि आप कोड का अनुवाद करने की कोशिश कर रहे हैं। आप जांचें कि कार्यक्रम कैसे चलेगा, इसलिए असुविधा विधि से विधि तक लगातार कूद रही है। आप अपने सिर में कोड संकलित और निष्पादित करते हैं।
यदि कोड को पढ़ना आसान है, तो सबसे अधिक संभावना है कि आप उनके नामों पर विधि हस्ताक्षर पर अधिक ध्यान दें। आप कोड पढ़ रहे हैं।
30 से अधिक जटिलता वाले कई कार्यों वाले कोड के लिए, विपरीत सच है (उदाहरण के लिए, 100 से अधिक लाइनें)। यह पढ़ना असंभव है, लेकिन निष्पादन फल दे सकता है। यदि आप लूप के बीसवें पुनरावृत्ति पर स्थिति के पंद्रहवें बाड़े में फंस गए हैं ... सौभाग्य!
निष्कर्ष
हम कह सकते हैं कि कोड जितना आसान होगा, उतना ही बेहतर होगा। केवल अगर यह आपको लगता है कि आपका कोड सरल है, तो इसे कुछ और बिंदुओं द्वारा सरल बनाया जा सकता है। यह ठीक है कि फ़ंक्शन का उपयोग अब एक ही स्थान पर किया जाता है, कुछ भी नहीं जिसका नाम 20 से अधिक वर्ण है। मुख्य बात यह है कि कोड पठनीय है, एक कला पुस्तक की तरह कह सकता है। यह कोड है, टिप्पणी नहीं।
ग्लास, फाउलर, मैककोनेल, मार्टिन के कार्यों में अच्छे उदाहरण मिल सकते हैं।
एक और अच्छी गुणवत्ता नियंत्रण कोड परीक्षण हैं। इस अर्थ में नहीं कि इसमें कोई त्रुटि नहीं हैं - हर जगह त्रुटियां हैं। यदि, परीक्षण लिखते समय, आपने कुछ मिनट के लिए सोचा कि कोड का परीक्षण कैसे किया जाए, तो यह वास्तव में जटिल है, इसे सरल बनाया जा सकता है। कभी-कभी, वास्तविक अंतर्दृष्टि आती है।
अपना कोड लिखें और पढ़ें, और कंपाइलर बाकी काम करेगा!
उपयोगी लिंक:
1.
सही कोड। एस। मैककॉनेल2.
परावर्तन। मौजूदा कोड में सुधार। एम। फाउलर3.
साफ कोड। आर। मार्टिन4.
ग्रेग विल्सन - हम वास्तव में सॉफ्टवेयर विकास के बारे में क्या जानते हैं, और हम क्यों मानते हैं कि यह सच है5.
अंकल बॉब के साथ ठोस सिद्धांत - रॉबर्ट सी। मार्टिन6.
एक अच्छा अंग्रेजी संसाधन sourcemaking.com