क्षमा करें, यह लंबा होने जा रहा है, लेकिन यह व्यक्तिगत अनुभव पर आधारित है, क्योंकि कई पुन: लिखने वाली परियोजनाओं पर आर्किटेक्ट और डेवलपर दोनों हैं।
निम्नलिखित स्थितियों से आपको किसी प्रकार के पुनर्लेखन पर विचार करना चाहिए। मैं यह तय करने के बारे में बात करूंगा कि किसके बाद क्या करना है
- डेवलपर रैंप-अप समय बहुत अधिक है। यदि किसी नए डेवलपर को रैंप करने के लिए नीचे (अनुभव के स्तर) से अधिक समय लगता है, तो सिस्टम को फिर से डिज़ाइन करने की आवश्यकता है। रैंप-अप समय से, मेरा मतलब है कि नए डेवलपर के पहले समय की राशि उनके पहले कमिट (एक छोटी सी सुविधा पर) करने के लिए तैयार है
- कॉलेज के बाहर ताजा - 1.5 महीने
- अभी भी हरा है, लेकिन 1 महीने से पहले अन्य परियोजनाओं पर काम किया है
- मध्य स्तर - 2 सप्ताह
- अनुभवी - 1 सप्ताह
- वरिष्ठ स्तर - 1 दिन
- मौजूदा आर्किटेक्चर की जटिलता के कारण तैनाती को स्वचालित नहीं किया जा सकता है
- मौजूदा कोड की जटिलता के कारण साधारण बग फिक्स में भी बहुत समय लगता है
- नई विशेषताओं में बहुत लंबा समय लगता है, और कोडबेस की अन्योन्याश्रयता के कारण लागत बहुत अधिक होती है (नई सुविधाओं को अलग नहीं किया जा सकता है, और इसलिए मौजूदा सुविधाओं को प्रभावित करता है)
- मौजूदा कोडबेस की अन्योन्याश्रयता के कारण औपचारिक परीक्षण चक्र बहुत लंबा होता है।
- बहुत अधिक उपयोग मामलों को बहुत कम स्क्रीन पर निष्पादित किया जाता है। यह उपयोगकर्ताओं और डेवलपर्स के लिए प्रशिक्षण मुद्दों का कारण बनता है।
- मौजूदा व्यवस्था में जो तकनीक है, वह इसकी मांग करती है
- प्रौद्योगिकी में अनुभव के साथ गुणवत्ता डेवलपर्स को खोजने के लिए बहुत कठिन हैं
- इसे हटा दिया गया है (इसे नए प्लेटफार्मों / सुविधाओं का समर्थन करने के लिए उन्नत नहीं किया जा सकता है)
- बस एक और अधिक उच्च स्तरीय उच्च स्तरीय तकनीक उपलब्ध है
- पुरानी तकनीक के बुनियादी ढांचे को बनाए रखने की लागत बहुत अधिक है
ये बातें काफी हद तक स्पष्ट हैं। जब एक पूर्ण पुनर्लेखन बनाम एक वृद्धिशील पुनर्निर्माण पर निर्णय लेना अधिक व्यक्तिपरक है, और इसलिए अधिक राजनीतिक रूप से चार्ज किया जाता है। मैं विश्वास के साथ कह सकता हूं कि स्पष्ट रूप से कहा गया है कि यह कभी भी अच्छा विचार नहीं है कि गलत है।
यदि किसी सिस्टम को इंक्रीमेंटल रिडिजाइन किया जा सकता है, और आपके पास इस तरह के काम के लिए प्रोजेक्ट स्पॉन्सरशिप का पूरा सपोर्ट है, तो आपको यह करना चाहिए। यहाँ समस्या है, यद्यपि। कई प्रणालियों में वृद्धि को फिर से डिज़ाइन नहीं किया जा सकता है। यहाँ कुछ कारणों का मैंने सामना किया है जो इसे रोकते हैं (तकनीकी और राजनीतिक दोनों)।
- तकनीकी
- घटकों का युग्मन इतना अधिक है कि एकल घटक में परिवर्तन अन्य घटकों से अलग नहीं किया जा सकता है। किसी एकल घटक के पुनर्निर्देशन से न केवल आसन्न घटकों के परिवर्तनों में कमी आती है, बल्कि सभी घटकों में अप्रत्यक्ष रूप से परिवर्तन होता है।
- प्रौद्योगिकी स्टैक इतना जटिल है कि भविष्य के राज्य के डिजाइन में कई बुनियादी ढांचे में बदलाव की आवश्यकता है। यह एक पूर्ण पुनर्लेखन में भी आवश्यक होगा, लेकिन अगर यह एक वृद्धिशील रीडिज़ाइन में आवश्यक है, तो आप उस लाभ को खो देते हैं।
- एक घटक को फिर से तैयार करने से उस घटक का पूर्ण रूप से फिर से लिखना होता है, क्योंकि मौजूदा डिज़ाइन इतना फ़्यूबर है कि बचत के लायक कुछ भी नहीं है। फिर से, यदि यह मामला है तो आप लाभ खो देते हैं।
- राजनीतिक
- प्रायोजकों को यह समझने के लिए नहीं किया जा सकता है कि एक वृद्धिशील रीडिज़ाइन को परियोजना के लिए दीर्घकालिक प्रतिबद्धता की आवश्यकता है। अनिवार्य रूप से, अधिकांश संगठन निरंतर बजट नाली के लिए भूख खो देते हैं जो एक वृद्धिशील नया स्वरूप बनाता है। भूख के इस नुकसान के रूप में अच्छी तरह से एक फिर से लिखना के लिए अपरिहार्य है, लेकिन प्रायोजकों को जारी रखने के लिए अधिक इच्छुक होंगे, क्योंकि वे आंशिक रूप से पूर्ण नई प्रणाली और आंशिक रूप से अप्रचलित पुरानी प्रणाली के बीच विभाजित नहीं होना चाहते हैं।
- सिस्टम के उपयोगकर्ता अपने "वर्तमान स्क्रीन" के साथ बहुत अधिक संलग्न हैं। यदि यह स्थिति है, तो आपके पास सिस्टम के महत्वपूर्ण भाग (फ्रंट-एंड) को सुधारने के लिए लाइसेंस नहीं होगा। एक नया स्वरूप आपको इस समस्या को दरकिनार करने की अनुमति देता है, क्योंकि वे कुछ नया शुरू कर रहे हैं। वे अभी भी "समान स्क्रीन" प्राप्त करने पर जोर देंगे, लेकिन आपके पास वापस धकेलने के लिए थोड़ा अधिक गोला-बारूद है।
ध्यान रखें कि वृद्धिशील रूप से पुनर्वितरण की कुल लागत हमेशा एक पूर्ण पुनर्लेखन करने की तुलना में अधिक होती है, लेकिन संगठन का प्रभाव आमतौर पर छोटा होता है। मेरी राय में, यदि आप एक पुनर्लेखन को सही ठहरा सकते हैं, और आपके पास सुपरस्टार डेवलपर्स हैं, तो इसे करें।
इसे केवल तभी करें जब आप निश्चित हो सकते हैं कि पूरा होने के माध्यम से इसे देखने की राजनीतिक इच्छाशक्ति है। इसका मतलब है कि कार्यकारी और अंतिम उपयोगकर्ता दोनों ही खरीद-इन करते हैं। इसके बिना, आप असफल होंगे। मैं मान रहा हूं कि यही वजह है कि जोएल कहते हैं कि यह एक बुरा विचार है। कार्यकारी और अंत उपयोगकर्ता खरीदने में कई आर्किटेक्ट के लिए दो सिर वाला गेंडा जैसा दिखता है। आपको इसे आक्रामक रूप से बेचना होगा, और इसके पूर्ण होने तक लगातार जारी रखने के लिए अभियान चलाना होगा। यह मुश्किल है, और आप अपनी प्रतिष्ठा को किसी ऐसी चीज पर अटकाने की बात कर रहे हैं जिसे कुछ लोग सफल नहीं देखना चाहेंगे।
सफलता के लिए कुछ रणनीतियाँ:
- यदि आप, हालांकि, मौजूदा कोड को बदलने की कोशिश नहीं करते हैं। खरोंच से सिस्टम को डिज़ाइन करें। अन्यथा आप अपना समय बर्बाद कर रहे हैं। मैंने "रूपांतरण" परियोजना के बारे में कभी नहीं देखा या सुना है जो बुरी तरह से समाप्त नहीं हुई।
- एक समय में नई प्रणाली एक टीम में उपयोगकर्ताओं को माइग्रेट करें। उन टीमों को पहचानें जिनके पास मौजूदा प्रणाली के साथ MOST दर्द है, और पहले उन्हें माइग्रेट करें। उन्हें मुंह से वचन देकर खुशखबरी फैलाने दें। इस तरह आपका नया सिस्टम भीतर से बिक जाएगा।
- अपनी ज़रूरत के अनुसार अपना ढांचा डिज़ाइन करें। कुछ I-6-महीने-निर्माण-इस ढांचे के साथ शुरू न करें, जिसने कभी वास्तविक कोड नहीं देखा है।
- जितना संभव हो अपनी तकनीक को छोटा रखें। ओवर-डिजाइन मत करो। आप आवश्यकतानुसार तकनीकों को जोड़ सकते हैं, लेकिन उन्हें बाहर निकालना मुश्किल है। इसके अतिरिक्त, आपके पास जितनी अधिक परतें हैं, उतना ही यह काम करने के लिए डेवलपर्स के लिए है। गेट-गो से मुश्किल मत करो।
- उपयोगकर्ताओं को सीधे डिज़ाइन प्रक्रिया में शामिल करें, लेकिन उन्हें यह निर्धारित करने की अनुमति न दें कि यह कैसे करना है। उन्हें यह दिखा कर उनका विश्वास अर्जित करें कि यदि आप अच्छे डिजाइन सिद्धांतों का पालन करते हैं तो आप उन्हें वह दे सकते हैं जो वे बेहतर चाहते हैं।
