कैसे कम कोड लिखने के लिए और अधिक समझ में आता है

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

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

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

इन सभी समस्याओं के लिए, एक समाधान है: कम कोड लिखें। इस दृष्टिकोण के बहुत सारे फायदे हैं:

• विकास के लिए कम कोड = कम विकास लागत
• विकास में कम कोड = कम रखरखाव लागत
• विकास में कम कोड = कम कीड़े
• कम कोड विकसित करने के लिए = अधिक कुशल परीक्षण

और सबसे महत्वपूर्ण बात: जितना कम कोड आप लोगों को पढ़ने के लिए बाध्य करते हैं, उतना ही अधिक संभावना है कि कोई व्यक्ति इसे बिल्कुल भी पढ़ेगा।

यहां कुछ तरीके दिए गए हैं जिनसे आप कोड को वापस काट सकते हैं।

YAGNI सिद्धांत ("आपको इसकी आवश्यकता नहीं है")

सिद्धांत "आपको इसकी आवश्यकता नहीं है" (इसे अक्सर YAGNI के रूप में संदर्भित किया जाता है - आपको Aint 'की आवश्यकता होगी) का अर्थ है निम्नलिखित चरम प्रोग्रामिंग नियम: "इस या उस अवसर का एहसास केवल तब करें जब वास्तव में इसकी आवश्यकता हो, और जब आप यह न मानें तो जल्द ही उसकी जरूरत होगी। ” यहां तक ​​कि अगर आप एक सौ प्रतिशत सुनिश्चित हैं कि यह कार्य भविष्य में नहीं किया जा सकता है, तो इसे अभी लागू न करें।

इस अभ्यास के दो कारण हैं:

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

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

यहां मूल नियम यह है: जो स्पष्ट रूप से आवश्यक है उस पर ध्यान केंद्रित करें, और जो होने की संभावना है उसके बारे में मत सोचो।

अजेय कोड न लिखें

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

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

इसीलिए, यदि आप कम कोड लिखने का लक्ष्य बना रहे हैं, तो आपको "यदि केवल काम किया है" की श्रेणी से, सरलतम संभव कार्यान्वयन के लिए प्रयास करना चाहिए।

एक्सट्रीम प्रोग्रामिंग गाइड में सरल कोड लिखने के दो सुनहरे नियमों का उल्लेख है:

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

मत भूलना: हम सबसे छोटे मार्ग के लिए प्रयास नहीं करते हैं, लेकिन सबसे सरल परिणाम के लिए।

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

याद रखें कि सादगी लालित्य के केंद्र में है। अनावश्यक जटिलता को नियंत्रित करने और समाप्त करने की क्षमता मास्टर प्रोग्रामिंग है।

कोड को बदतर मत बनाओ

इस नियम को डेवलपर्स के लिए हिप्पोक्रेटिक शपथ माना जा सकता है। प्रोग्रामिंग में शामिल लोग लगातार सुझावों को सुनते हैं कि कोनों में कटौती न करें और ऐसे वर्कआर्डर्स की तलाश न करें जो कोड को नुकसान पहुंचा सकते हैं और इसके क्षरण का नेतृत्व कर सकते हैं।

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

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

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

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

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

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

अत्यधिक संगति से बचें

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

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

• दौड़ की स्थिति: ऑपरेशन अप्रत्याशित रूप से होने लगते हैं
• म्यूचुअल ब्लॉकिंग: एक साथ काम पूरा करने के लिए प्रतीक्षा करते समय शामिल ऑब्जेक्ट क्रॉस-ब्लॉक
• संसाधनों की कमी: ऑपरेशन stably आवश्यक संसाधन तक पहुँच प्राप्त नहीं करता है जो यह अपेक्षा करता है

सॉफ़्टवेयर विकास से जुड़ी सबसे उच्च-प्रोफ़ाइल आपदाओं में से एक गलत तरीके से निर्धारित अन्योन्याश्रित स्थितियों के कारण ठीक थी। थेरैक -25 के साथ एक प्रोग्रामिंग त्रुटि, एक रेडियोथेरेपी उपकरण, जिससे चार लोगों की मौत हो गई।

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

जमाखोरी में न टकराएं

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

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

क्या प्लायस्किन के सिंड्रोम ने कभी आप पर हमला किया है? शायद आपने चीजों को क्रम में रखने का विचार त्याग दिया क्योंकि आप समझते हैं कि आपके पास यह सब गड़बड़ करने के लिए पर्याप्त समय नहीं है? यदि ऐसा है, तो आप अभी भी अपने कामकाजी जीवन में जमाखोरी और पूर्ण अराजकता से पीड़ित हैं।

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

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