हम कब रिफैक्टर (Refactor) करें और कब दोबारा लिखें (Rewrite), इसका निर्णय कैसे लें
हर डेवलपर को इस पल का सामना करना पड़ता है।
कोडबेस धीमा है। नए फीचर्स जोड़ने में बहुत समय लगता है। नए कर्मचारी सिस्टम को समझने में संघर्ष करते हैं। अंततः कोई पूरी तरह से दोबारा लिखने (rewrite) का सुझाव देता है।
टीम आमतौर पर दो समूहों में बंट जाती है। एक समूह नए सिरे से शुरुआत करना चाहता है। दूसरा समूह पिछले रीराइट्स (rewrites) की विफलता से डरता है। दोनों पक्षों के पास वैध तर्क हैं।
रीराइट (Rewrite) कोई जादुई समाधान नहीं है। इसमें अक्सर योजना से अधिक समय लगता है। आप एक साथ दो सिस्टम बनाए रखने की स्थिति में आ जाते हैं। आप नए वर्जन में भी वही गलतियाँ दोहरा सकते हैं।
इन विशिष्ट मामलों में रीराइट (Rewrite) करना तर्कसंगत है:
• डेटा मॉडल व्यवसाय के लिए मौलिक रूप से गलत है। • तकनीक पुरानी (dead) हो चुकी है और इसमें कोई सुरक्षा अपडेट नहीं मिल रहे हैं। • व्यावसायिक ज़रूरतें इतनी बदल गई हैं कि मूल सिस्टम अब अप्रचलित (obsolete) हो गया है। • वर्तमान टीम में कोई भी यह नहीं समझता कि सिस्टम कैसे काम करता है।
फिर भी, एक साथ सब कुछ बदलने (big bang replacement) की कोशिश न करें। 'strangler fig pattern' का उपयोग करें। पुराने सिस्टम के साथ-साथ धीरे-धीरे नए सिस्टम को टुकड़ों में बनाएं।
अधिकांश समय, आपको वास्तव में रिफैक्टरिंग (refactoring) की आवश्यकता होती है।
रिफैक्टरिंग (Refactoring) सही विकल्प है जब:
• आप अभी भी फीचर्स जोड़ सकते हैं, भले ही इसमें समय लगे। • टीम वर्तमान कोड को समझती है। • समस्या (mess) केवल विशिष्ट मॉड्यूल्स तक ही सीमित है। • व्यवसाय नए फीचर्स जारी करना बंद नहीं कर सकता।
चुनाव करने से पहले, पूछें कि कोड खराब क्यों हुआ।
यदि समस्या तकनीकी ऋण (technical debt) है, तो सबसे खराब हिस्सों को रिफैक्टर करें। यदि समस्या कोड रिव्यू की कमी या खराब कार्य संस्कृति है, तो रीराइट (rewrite) से कोई मदद नहीं मिलेगी। आप बस पुरानी आदतों के साथ एक नया कचरा (mess) तैयार कर लेंगे।
निर्णय लेने से पहले ये प्रश्न पूछें:
• क्या हम सबसे खराब हिस्सों को अलग से (in isolation) ठीक कर सकते हैं? • क्या डेटा मॉडल वर्तमान व्यावसायिक आवश्यकताओं के लिए अनुपयुक्त है? • यदि हम नए सिरे से शुरुआत करते हैं, तो हम क्या ज्ञान खो देंगे? • क्या व्यवसाय में लंबे ट्रांज़िशन (transition) को संभालने के लिए स्थिरता है?
नए सिरे से शुरुआत करना अच्छा लगता है। रीराइट को पूरा करना कठिन हिस्सा है। अधिकांश समय, एक व्यवस्थित रिफैक्टरिंग योजना अधिक सुरक्षित और प्रभावी होती है।
स्रोत: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk