जटिलता से अधिक

मैंने ऐसी अभिव्यक्ति सुनी कि प्रोग्रामर बनने के लिए, आपको आलसी होने की आवश्यकता है। लेकिन कभी-कभी प्रोग्रामिंग में आलस एक भयानक तकनीकी ऋण की ओर ले जाता है। एसआरपी पर अपने लेख में, मैंने उल्लेख किया कि इस सिद्धांत का उल्लंघन करने से जटिलता बढ़ सकती है या यहां तक ​​कि इसका गुणा भी हो सकता है। मेरे एक सहकर्मी ने एक दिलचस्प उदाहरण पेश किया, और मेरी मदद से मैंने यह प्रदर्शित करने का निर्णय लिया कि यह कैसा दिखता है।



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

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

यहाँ एक सरल उदाहरण है। यह काल्पनिक लग सकता है, लेकिन ऐसा नहीं है। यह भी सरल नहीं है, यह इस रूप में था कि मैं एक कोड समीक्षा के दौरान उनसे कुछ साल पहले मिला था। कोड में दो स्थानों पर एक ही फ़ंक्शन के लिए कॉल थे लेकिन एक अलग बूलियन पैरामीटर के साथ:

// first place doSomething(true); // second place doSomething(false); 

इसी तरह के डिजाइन हमेशा संदिग्ध लगते हैं और इस फ़ंक्शन ने मुझे निराश नहीं किया। इस फ़ंक्शन के अंदर जाँच के लिए यह पैरामीटर पारित किया गया था:

 doSomething(flag: boolean): void { if(flag) { // do first thing } else { // do second thing } } 

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

 // first place doFirstThing(); // second place doSecondThing(); //method is split into 2 parts each having their own responsibility doFirstThing(): void { // do first thing } doSecondThing(): void { // do second thing } 

यह सब, और कोई जटिलता नहीं है। यह वह जगह है जहाँ डेवलपर को बहुत आलसी नहीं होना चाहिए और एक अन्य फ़ंक्शन हस्ताक्षर लिखना चाहिए।

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

 // first place checkValidity(obj); // second place checkValidity(arrayOfObjs); 

विधि, जैसा कि इसके नाम से है, वस्तु की वैधता की जांच करती है। हालांकि, यह स्पष्ट नहीं था कि यह वस्तुओं की एक सरणी की वैधता की भी जांच कर सकता है। मैंने इस उल्लंघन पर ज़ोर देने के लिए चर नामों को ट्विक किया। विधि इस तरह दिखती है:

 checkValidity(parm: MyType | MyType[]): void { if(Array.isArray(parm)) { parm.forEach(p => checkValidity(p)); } else { // here the object gets checked // and conditional exception is thrown } } 

यहाँ यह है। एक तो बहुत सारे इफ़्स हो जाते हैं। यदि सरणी में 100 ऑब्जेक्ट हैं, तो यह "यदि" 101 बार निष्पादित होगा। और वास्तविक आंकड़ों पर, हमारे पास 30 हजार वस्तुएं हो सकती हैं, और यह पहले से ही एक प्रभावशाली प्रदर्शन हानि है।

जाहिर है, एकमात्र जिम्मेदारी के सिद्धांत का पालन करते हुए, इस विधि को फिर से शुरू करने की आवश्यकता है ताकि 2 तरीके प्राप्त हों:

 checkItemsValidity(parms: MyType[]): void { parms.forEach(p => checkItemValidity(p)); } checkItemValidity(parm: MyType): void { // here the object gets checked // and conditional exception is thrown } 

इसके विपरीत, आपको कॉल पॉइंट को समायोजित करने की भी आवश्यकता है।

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

वह सब है। अच्छे कोड के सबसे महत्वपूर्ण सिद्धांत को प्रदर्शित करने के लिए सरल उदाहरणों के एक जोड़े।