स्टील थ्रेड्स एक शक्तिशाली लेकिन अस्पष्ट सॉफ़्टवेयर डिज़ाइन दृष्टिकोण है। स्टील थ्रेड्स के बारे में जानने से आप एक बेहतर इंजीनियर बनेंगे। एकीकरण दर्द जैसी सामान्य समस्याओं से बचने के लिए आप उनका उपयोग कर सकते हैं। और आप सिस्टम डिज़ाइन की जटिलता को कम करने के लिए उनका उपयोग कर सकते हैं। इतना अस्पष्ट, इसे 2013 में विकिपीडिया से हटा दिया गया था स्टील के धागे कितने अज्ञात हैं? अवधारणा को 2013 में था क्योंकि "विचार सॉफ्टवेयर इंजीनियरिंग के भीतर उल्लेखनीय नहीं है, और उल्लेखनीय स्रोतों से महत्वपूर्ण कवरेज प्राप्त नहीं हुआ है।" आइए कवरेज में जोड़ें, और यह भी बात करें कि यह इतना उपयोगी तरीका क्यों है। विकिपीडिया से हटा दिया गया स्टील के धागे क्या हैं? एक स्टील थ्रेड कार्यक्षमता का एक बहुत पतला टुकड़ा है जो एक सॉफ्टवेयर सिस्टम के माध्यम से थ्रेड करता है। उन्हें "धागा" कहा जाता है क्योंकि वे सॉफ्टवेयर सिस्टम के विभिन्न भागों के माध्यम से बुनते हैं और एक महत्वपूर्ण उपयोग के मामले को लागू करते हैं। उन्हें "स्टील" कहा जाता है क्योंकि धागा बाद के सुधारों के लिए एक ठोस आधार बन जाता है। स्टील थ्रेड दृष्टिकोण के साथ, आप सबसे पतले संभव संस्करण का निर्माण करते हैं जो सिस्टम की सीमाओं को पार करता है और एक महत्वपूर्ण उपयोग के मामले को कवर करता है। एक पारंपरिक, समस्याग्रस्त दृष्टिकोण का उदाहरण मान लीजिए कि आप अपने मोनोलिथिक कोडबेस के एक हिस्से को बदलने के लिए एक नई सेवा बना रहे हैं। ऐसा करने का सबसे सामान्य तरीका होगा पुराने कोड को देखें, और नई प्रणाली की जरूरतों का पता लगाएं। आपको आवश्यक क्षमताएं प्रदान करने वाले API को डिज़ाइन और निर्मित करें। पुराने कोड में जाएं, और नए एपीआई का उपयोग करने के लिए संदर्भों को अपडेट करें। इसे फीचर फ्लैग के पीछे करें। फीचर फ़्लैग का उपयोग करके काटें। इसके काम करने तक आने वाली किसी भी समस्या को ठीक करें, पुराने कोड पथ पर वापस जाने के लिए यदि आवश्यक हो तो फीचर फ्लैग को बंद कर दें। जब यह स्थिर हो जाए, तो पुराने कोड पथ हटा दें। उचित लगता है, है ना? ठीक है, यह सॉफ्टवेयर इंजीनियरों का सबसे आम तरीका है, लेकिन इस दृष्टिकोण में बहुत सारे बारूदी सुरंगें हैं। मैं इस परियोजना में किन समस्याओं की अपेक्षा करूंगा? पुरानी प्रणाली से अलग तरीके से नई सेवा का निर्माण करना आकर्षक हो सकता है। आखिरकार, डिजाइन शुद्ध लग सकता है। लेकिन आप काफी अधिक संरचनात्मक परिवर्तन भी पेश कर रहे हैं, और आप इन परिवर्तनों को पुरानी प्रणाली में किसी भी एकीकरण के बिना कर रहे हैं। इससे एकीकरण का दर्द काफी बढ़ जाता है। मेरी अपेक्षा यह होगी कि परियोजना के लिए सभी अनुमान अवास्तविक हों। और मैं उम्मीद करता हूं कि परियोजना को पूरा होने के बाद असफल माना जाएगा, भले ही परिणामी सेवा में आम तौर पर अच्छी डिजाइन हो। मुझे उम्मीद है कि नई प्रणाली में स्विचओवर समस्याग्रस्त होगा। जैसे ही आप स्विच करते हैं, समस्याओं की एक श्रृंखला सामने आएगी, जिसके लिए पुराने कोड पथों पर वापस जाने या परियोजना के अंतिम चरणों में समस्याओं को ठीक करने के लिए गहनता से काम करने की आवश्यकता होगी। भारी कटओवर न होने से इन दोनों चीजों से बचा जा सकता है। ध्यान दें कि फीचर फ़्लैग के साथ नई सेवा के ट्रैफ़िक में एक प्रतिशत से अधिक कटौती करना भी एक कटओवर दृष्टिकोण है। क्यों? आप एक ही समय में सभी परिवर्तनों के लिए एक प्रतिशत ट्रैफ़िक काट रहे हैं। मुझे अभी भी इसके अच्छे होने की उम्मीद नहीं है। आप ऐसे कदम उठा रहे हैं जो बहुत बड़े हैं। स्टील के धागे का उपयोग करने का उदाहरण इसे करने के स्टील थ्रेड तरीके के साथ तुलना करें। आपके द्वारा बनाई जा रही नई प्रणाली के बारे में सोचें। कुछ संकीर्ण उपयोग मामलों के साथ आओ जो सिस्टम के स्टील थ्रेड्स का प्रतिनिधित्व करते हैं - वे सिस्टम में उपयोगी कार्यक्षमता को कवर करते हैं, लेकिन सभी उपयोग मामलों को संभाल नहीं पाते हैं, या कुछ तरीकों से विवश हैं। एक प्रारंभिक उपयोग मामला चुनें जो जितना संभव हो उतना संकीर्ण हो जो कुछ मूल्य प्रदान करता हो। उदाहरण के लिए, आप एक एपीआई चुन सकते हैं जो आपको लगता है कि नई सेवा का हिस्सा होगा। एक नई सेवा में नया एपीआई बनाएं। इसे केवल उस संकीर्ण उपयोग मामले के लिए काम करें। किसी अन्य उपयोग के मामले में, पुराने कोड पथ का उपयोग करें। इसे उत्पादन के लिए, और पूर्ण उपयोग में लाएँ। (युक्ति: आप नया और पुराना दोनों कोड पथ भी कर सकते हैं और तुलना कर सकते हैं!) फिर आप धीरे-धीरे अतिरिक्त उपयोग के मामले जोड़ते हैं, जब तक कि आप नई सेवा के लिए आवश्यक सभी कार्यक्षमताओं को स्थानांतरित नहीं कर देते। प्रत्येक उपयोग मामला उत्पादन में है। एक बार जब आप काम पूरा कर लेते हैं, तो आप पुराने कोड और फीचर फ्लैग को हटा देते हैं। यह बिल्कुल भी जोखिम भरा नहीं है, क्योंकि आप पहले से ही नई प्रणाली पर चल रहे हैं। क्या यह भी "अजनबी" पैटर्न नहीं है? हां, लेकिन इसका इस्तेमाल नए प्रोजेक्ट्स के लिए भी किया जा सकता है। ग्रीनफ़ील्ड उदाहरण के लिए आगे पढ़ें। स्टील के धागे एकीकरण के दर्द से बचते हैं, और आपको उच्च आत्मविश्वास देते हैं परियोजनाओं में अंतिम-मिनट की समस्याओं के बड़े कारणों में से एक एकीकरण दर्द है। जब आप एक नई प्रणाली में कटौती करते हैं, तो आपको ऐसी समस्याएं मिलती हैं जिनकी आप अपेक्षा नहीं करते हैं। आपको किसी भी चीज के बारे में संदेह होना चाहिए जिसमें कट-ओवर शामिल हो। चीजों को छोटे वेतन वृद्धि में करें। हमेशा स्टील थ्रेड्स शुरू से ही एकीकृत होते हैं, इसलिए आपको कभी भी बहुत अधिक एकीकरण दर्द से गुजरना नहीं पड़ता है। इसके बजाय, आपके पास पूरे रास्ते में छोटे एकीकरण का दर्द है। साथ ही, आपकी सेवा के लाइव होने से पहले उसकी कभी भी जांच करने की आवश्यकता नहीं होती है, क्योंकि आपने इस प्रक्रिया के दौरान उसका क्रमिक रूप से परीक्षण किया है। आप जानते हैं कि यह उत्पादन भार को संभाल सकता है। आप पहले ही नेटवर्क विलंबता जोड़ चुके हैं, इसलिए आप इसके निहितार्थ जानते हैं। जिस तरह से आप धीरे-धीरे सेवा शुरू करते हैं, उसके हिस्से के रूप में सभी आश्चर्यों को आगे बढ़ाया जाता है, और वृद्धिशील रूप से संभाला जाता है। महत्वपूर्ण बात यह है कि आपके पास एक कार्यशील, एकीकृत प्रणाली है, और जैसे-जैसे आप इस पर काम करते हैं, आप इसे काम करते रहते हैं। और आप इसे समय के साथ बाहर निकाल देते हैं। स्टील के धागे जटिलता को काटने में मदद कर सकते हैं जब आप एक सिस्टम डिजाइन कर रहे होते हैं, तो आपके पास बहुत सारी जटिलता होती है। नई प्रणाली के लिए आवश्यकताओं का एक सेट बनाना एक चुनौतीपूर्ण प्रयास हो सकता है। स्टील थ्रेड दृष्टिकोण का उपयोग करते समय, आप कुछ मुख्य आवश्यकताओं को चुनते हैं और उन्हें इस तरह से वाक्यांशित करते हैं जो सिस्टम की परतों के माध्यम से कटौती करता है, और आपके डिजाइन का अभ्यास करता है। यह पूरे सिस्टम के लिए एक प्रकार की कंकाल संरचना प्रदान करता है। उस स्टील थ्रेड का कार्यान्वयन तब हड्डियां बन जाता है जिस पर आगे की आवश्यकताओं का निर्माण किया जा सकता है। इस प्रकार, स्टील थ्रेड्स सिस्टम की हैं। आवश्यकताओं का एक सबसेट स्टील के धागों का उपयोग ग्रीनफील्ड कार्य में भी किया जा सकता है मान लीजिए कि आप स्लैक का क्लोन लागू कर रहे हैं। आपका प्रारंभिक स्टील थ्रेड कुछ ऐसा हो सकता है: "कोई भी अप्रमाणित व्यक्ति हार्डकोडेड # सामान्य कमरे में हार्डकोड खाते में एक संदेश पोस्ट कर सकता है। संदेश पेज रीफ्रेश के माध्यम से बने रहते हैं।" ध्यान दें कि यह शुरुआती स्टील थ्रेड कितना सीमित है। यह प्रमाणीकरण, उपयोगकर्ताओं या खातों को हैंडल नहीं करता है। यह संदेशों को लिखने और उन्हें जारी रखने का कार्य करता है। आपका दूसरा स्टील थ्रेड सिस्टम को और अधिक उपयोगी होने की ओर ले जा सकता है। उदाहरण के लिए, आपके पास स्टील थ्रेड हो सकता है जो संदेश पोस्टर को वह नाम चुनने की अनुमति देता है जिसके तहत वे पोस्ट करते हैं। इस दूसरे स्टील थ्रेड ने वास्तव में बहुत कुछ नहीं किया है। आपके पास अभी भी प्रमाणीकरण, खाते या उपयोगकर्ता की अवधारणा भी नहीं है। लेकिन आपने एक चैट रूम बनाया है जो इतना काम करता है कि आप इसका इस्तेमाल शुरू कर सकते हैं। इसके अलावा, ध्यान दें कि आपने सिस्टम के हर हिस्से से स्टील थ्रेड नहीं खींचा है। लेकिन आपने उपयोगकर्ताओं और खातों की अवधारणाओं को दबा दिया है। स्टील थ्रेड्स प्रारंभिक प्रतिक्रिया प्रदान करते हैं ध्यान दें कि इस सुस्त क्लोन उदाहरण में, आप अपने द्वारा बनाए जा रहे सिस्टम पर प्रारंभिक प्रतिक्रिया प्राप्त कर सकते हैं, भले ही आपने अभी तक इतना नहीं बनाया हो। स्टील थ्रेड्स का उपयोग करने का यह एक और शक्तिशाली कारण है। केवल उन दो स्टील थ्रेड्स के बाद, आपकी टीम चैट रूम का पूर्णकालिक उपयोग करना शुरू कर सकती है। इस बारे में सोचें कि आपकी टीम आपके सिस्टम का उपयोग करने से कितना सीखेगी। यह एक कार्य प्रणाली है। तुलना करें कि आपने उपयोगकर्ता और खाता प्रणाली का निर्माण करना, सब कुछ जोड़ना और अंत में एक चैट रूम बनाना सीखा होगा। स्टील थ्रेड्स से शुरू करें अपनी परियोजनाओं को डिजाइन करते समय शुरू करने के लिए स्टील थ्रेड्स अक्सर एक अच्छी जगह होती है। वे आने वाले बाकी कार्यों के लिए एक ढांचा तैयार करते हैं। वे सिस्टम के मुख्य हिस्सों को कील से ठोंक देते हैं ताकि बाहर निकलने के लिए प्राकृतिक स्थान हों। मैं आपको स्टील थ्रेडेड दृष्टिकोण का प्रयास करने के लिए प्रोत्साहित करता हूं। मुझे लगता है कि आप पाएंगे कि यह आपकी परियोजनाओं को बदल सकता है। मुझे इसके साथ अपने अनुभव बताएं! स्टील थ्रेड्स वर्टिकल स्लाइस से निकटता से संबंधित हैं आपने "वर्टिकल स्लाइसिंग" शब्द के बारे में सुना होगा। मैं पर अपनी पोस्ट में अवधारणा का वर्णन करता हूं। मील के पत्थर स्टील थ्रेड्स एक सॉफ्टवेयर डिज़ाइन तकनीक है जिसके परिणामस्वरूप आपके सॉफ़्टवेयर को वर्टिकल स्लाइस में डिलीवर किया जाता है। इस शब्द का प्रयोग एक प्रणाली के प्रारंभिक लंबवत स्लाइस का वर्णन करने के लिए किया जाता है। वे निकट से संबंधित अवधारणाएँ हैं, लेकिन पूरी तरह से समान नहीं हैं। मैंने स्टील थ्रेड्स को "ट्रेसर बुलेट्स" के रूप में संदर्भित करने के बारे में भी सुना है। से द्वारा छवि पिक्साबे स्टीन जेपसेन यह कहानी मूल रूप से यहां दिखाई गई थी: https://www.rubick.com/steel-threads/
