उत्पाद टीमों को तोड़े बिना डिज़ाइन सिस्टम घटकों का बहिष्कार करना
बड़े ऐप्स में ब्रेकिंग डिज़ाइन सिस्टम परिवर्तन कैसे रोल आउट करें: सिमेंटिक वर्जनिंग और उपयोग ट्रैकिंग का उपयोग करके घोषणा करें, अस्वीकृत करें, कोडमोड के साथ माइग्रेट करें और हटाएं।
कोर टेकअवे
किसी घटक को चार चरणों में रिटायर करें: कारण और प्रतिस्थापन के साथ परिवर्तन की घोषणा करें, स्पष्ट चेतावनियों के साथ एक छोटी रिलीज में अप्रचलित पुराने घटक को चिह्नित करें, टीमों को गाइड और स्वचालित कोडमोड के साथ माइग्रेट करने में मदद करें, और इसे केवल अगले प्रमुख रिलीज में हटा दें। ट्रैक करें कि कितनी स्क्रीन अभी भी हर चरण पर इसका उपयोग करती हैं, और इसे तब तक न हटाएं जब तक कि उपयोग शून्य के करीब न हो जाए।
क्यों निंदा ग़लत हो जाती है
डिज़ाइन सिस्टम परिवर्तन विफल हो जाते हैं जब वे उत्पाद टीमों को आश्चर्यचकित करते हैं: अपडेट में एक घटक गायब हो जाता है, ब्रेक बनाता है, और टीमें पुराने संस्करण को पिन करती हैं और अपग्रेड करना बंद कर देती हैं। एक बार ऐसा होने पर, सिस्टम अपना मुख्य लाभ, स्थिरता खो देता है, क्योंकि उत्पाद के विभिन्न हिस्से अलग-अलग संस्करणों में चले जाते हैं।
चार चरणों वाली प्रक्रिया
सिमेंटिक वर्जनिंग एक सरल अनुबंध देता है: असंगत परिवर्तन एक प्रमुख संस्करण में जाते हैं, और जब आप एपीआई के हिस्से को हटा देते हैं तो आपको दस्तावेज़ीकरण को अपडेट करना चाहिए और बाद में इसे हटाने से पहले, डेप्रिकेशन के साथ एक छोटी रिलीज को शिप करना चाहिए।
- घोषणा करें: कारण बताएं, प्रतिस्थापन दिखाएं, समयरेखा दें।
- पदावनत करें: इसे डॉक्स और कोड में कंसोल या लिंट चेतावनी के साथ चिह्नित करें जो गाइड से लिंक करता है।
- माइग्रेट करें: एक लिखित मार्गदर्शिका और, कोड के लिए, एक कोडमॉड प्रदान करें जो स्वचालित रूप से उपयोग को अपडेट करता है।
- हटाएँ: अगली प्रमुख रिलीज़ में, जब उपयोग शून्य के करीब हो।
माइग्रेशन स्वचालित करें
कोडमोड ऐसी स्क्रिप्ट हैं जो एक कोडबेस पर कोड को फिर से लिखती हैं। jcodeshift जैसे उपकरण एक साथ कई JavaScript या TypeScript फ़ाइलों पर कोडमोड चलाते हैं, इसलिए प्रोप नाम बदलने या घटक स्वैप को हफ्तों के बजाय मिनटों में लागू किया जा सकता है। उन्हें लिंट नियमों के साथ जोड़ें जो शेष उपयोगों को चिह्नित करते हैं।
गोद लेने का उपाय करें
आप यह जाने बिना हटाने की योजना नहीं बना सकते कि किसी घटक का उपयोग अभी भी कौन करता है। कोड (आयात, लिंट चेतावनियाँ) और डिज़ाइन फ़ाइलों (आपके डिज़ाइन टूल में लाइब्रेरी एनालिटिक्स) में उपयोग को ट्रैक करें। संख्याएँ प्रकाशित करें ताकि टीमें प्रगति देख सकें, और अंतिम कुछ टीमों को समय सीमा तय करने के बजाय सीधे मदद करें।
डिज़ाइन पक्ष को मत भूलना
डिज़ाइन लाइब्रेरी में भी घटक को अस्वीकृत करें: इसे "अस्वीकृत" उपसर्ग के साथ नाम बदलें, प्रतिस्थापन से लिंक करें, और इसे खोज में प्रदर्शित होने से रोकें। वरना डिज़ाइनर इसे नए काम में इस्तेमाल करते रहते हैं और माइग्रेशन कभी ख़त्म नहीं होता. गति और अंतःक्रिया व्यवहार परिवर्तन नोट्स का हिस्सा होना चाहिए, क्योंकि एक प्रतिस्थापन जो अलग तरह से चलता है वह टूटा हुआ महसूस कर सकता है, भले ही वह एक जैसा दिखता हो।
याद रखने योग्य कुंजी Principle
- घोषणा करें, निंदा करें, पलायन करें, हटाएं: कभी भी सीधे हटाने की ओर न बढ़ें
- एक छोटी सी रिहाई में पदावनत; एक प्रमुख रिलीज़ में हटाएँ
- माइग्रेशन को स्वचालित करने के लिए कोडमोड और लिंट नियमों का उपयोग करें
- कोड और डिज़ाइन फ़ाइलों दोनों में उपयोग को ट्रैक करें
- रिलीज़ नोट्स में गति और अंतःक्रिया परिवर्तन शामिल करें
अक्सर पूछे जाने वाले प्रश्नों
स्रोत
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — गिटहब (मेटा)