अपने रेल कैरियर में किसी बिंदु पर, आप एक नियंत्रक में भाग लेंगे जो आपको प्रोग्रामिंग को हमेशा के लिए छोड़ना चाहता है। इसमें संपूर्ण सुविधा के लिए कोड की प्रत्येक पंक्ति हो सकती है। इसमें 15 before_filters हो सकते हैं कि सभी आवृत्ति चर के माध्यम से संवाद करते हैं और उन्हें एक विशिष्ट क्रम में बुलाया जाना चाहिए या चीजें उड़ जाती हैं। और, अनिवार्य रूप से, इसके परीक्षण इस तरह दिखाई देंगे:
test "index" do
get :index
assert_response :success
end
बहुत बढ़िया। 100% परीक्षण कवरेज, है ना?
अपनी आँखें बंद करना और यह दिखावा करना जितना अच्छा होगा कि यह अस्तित्व में नहीं है, किसी दिन आपको इनमें से किसी एक नियंत्रक में एक बग को ठीक करना होगा। और, एक अच्छा सॉफ़्टवेयर डेवलपर होने के नाते, आप कोड को उस से बेहतर छोड़ना चाहते हैं जो आपने पाया है।
लेकिन आप रिफैक्टर कैसे कर सकते हैं, खासकर अच्छे परीक्षणों पर भरोसा किए बिना?
इसका परीक्षण करवाएं (किसी तरह)
रिफैक्टरिंग के दौरान सुरक्षित महसूस करने के लिए आपको अच्छे परीक्षणों की आवश्यकता है, लेकिन आप लिख नहीं कर सकते इस कोड के खिलाफ अच्छे परीक्षण जब तक आप रिफ्लेक्टर। तो आप क्या कर सकते हैं?
ठीक है, कोई फर्क नहीं पड़ता कि आपका नियंत्रक कितनी बुरी तरह लिखा गया है, आप अभी भी एकीकरण परीक्षण लिख सकते हैं जो नियंत्रक को कुछ डेटा भेजते हैं और इससे कुछ प्रतिक्रिया की अपेक्षा करते हैं। अभी के लिए, आपको ऐसे परीक्षण लिखने चाहिए जो सुनिश्चित करें कि नियंत्रक का मौजूदा . है व्यवहार नहीं बदलता जैसा कि आप रिफ्लेक्टर करते हैं।
ये परीक्षण इकाई परीक्षणों की तरह केंद्रित नहीं होंगे। लेकिन ये उच्च-स्तरीय परीक्षण आपको सहज महसूस करा सकते हैं कि आप जो रिफैक्टरिंग करने वाले हैं, वह सब कुछ नहीं तोड़ देगा। और उन्हें लिखने की प्रक्रिया आपको अपने कोड को बेहतर ढंग से समझने में मदद करेगी, जिससे आपको यह तय करने में मदद मिलेगी कि इसे कैसे रिफलेक्टर करना है।
अपनी निर्भरता को तोड़ें
खराब नियंत्रक कोड क्या खराब करता है? अधिकांश समय, यह अंतर्निहित निर्भरता . है before_filters . के बीच , सहायक विधियाँ, या 200-लाइन फ़ंक्शंस के विभिन्न भाग। यह बहुत जल्दी रिफैक्टरिंग का मामला भी हो सकता है। कोड को बेहतर बनाने के लिए, आपको इन निर्भरताओं को तोड़ना होगा।
रेल नियंत्रकों के लिए, निर्भरता को तोड़ने का एक आसान तरीका है। बस अपने before_filters . से कोड कॉपी करें , सहायक विधियां, सुपरक्लास, और कहीं और नियंत्रक-ईश कोड छुपाया जा सकता है। फिर, आपके द्वारा कॉपी किए गए कोड के साथ कॉल को उन तरीकों से बदलें।
आप अपने कोड को अस्थायी रूप से अन-ड्राय कर रहे हैं, ताकि आप बाद में इसे और अधिक समझने योग्य तरीके से पुन:सक्रिय कर सकें। यह बदसूरत है, लेकिन अब आपका सारा कोड खुले में है। आपको यह देखने में सक्षम होना चाहिए कि कौन से टुकड़े परस्पर क्रिया करते हैं और सब कुछ कैसे प्रवाहित होता है।
(इस प्रक्रिया के दौरान, आपको यह सुनिश्चित करने के लिए प्रत्येक परिवर्तन के बाद अपने परीक्षण चलाना चाहिए कि आपकी इनलाइनिंग कुछ भी नहीं तोड़ रही है।)
परीक्षण योग्य कोड की ओर पुनरावर्तक
अब, आप अपने कोड को फिर से रिफलेक्टर करने के लिए तैयार हैं। आप शायद मूल निकालने की विधि से चिपके रहेंगे , वस्तु निकालें , पुल अप विधि -टाइप रिफैक्टरिंग। अपने कोड को कुछ अलग तरीकों से पुन:सक्रिय करने का प्रयास करें और देखें कि सबसे अच्छा क्या लगता है।
पहले कुछ पास के दौरान, आप सुरक्षा जाल के रूप में अपने उच्च-स्तरीय एकीकरण परीक्षणों पर भरोसा कर सकते हैं। लेकिन जल्द ही, आप कुछ बेहतर चाहते हैं।
जैसे ही आप रिफैक्टर करते हैं, अपने कोड को अधिक परीक्षण योग्य बनाने के अवसरों की तलाश करें। इसका मतलब आमतौर पर टेस्ट डबल्स को इंजेक्ट करने के लिए जगह बनाना, आपकी वस्तुओं के बीच निर्भरता को कम करना और आपके नियंत्रक को उन वस्तुओं पर भरोसा करना होगा जिन्हें आसानी से बनाया जा सकता है और यूनिट का परीक्षण किया जा सकता है। कोड को परीक्षण योग्य वस्तुओं में ले जाने से, आपके नियंत्रक छोटे, समझने में आसान और स्वयं का परीक्षण करने में आसान हो जाएंगे।
क्या मैं इसे क्रमांकित सूची के रूप में प्राप्त कर सकता हूं?
एक बार फिर, बड़े नियंत्रक को तोड़ने के लिए ये कदम उठाने होंगे:
- नियंत्रक के विरुद्ध चलने वाले उच्च-स्तरीय एकीकरण परीक्षण प्राप्त करें।
- परीक्षण चलाएं, सुनिश्चित करें कि वे पास हो गए हैं।
- इनलाइन
before_filters, सुपरक्लास विधियाँ, और अन्य सार तत्व जो कोड छिपाते हैं। - परीक्षण चलाएं, सुनिश्चित करें कि वे अभी भी उत्तीर्ण हैं।
- एक रिफैक्टरिंग करें (निकालने का तरीका , सेवा ऑब्जेक्ट निकालें , इंस्टेंस वैरिएबल को लोकल से बदलें , आदि।)। देखें कि क्या कोड बेहतर लगता है।
- परीक्षण चलाएं, सुनिश्चित करें कि वे अभी भी उत्तीर्ण हैं।
- यदि आपने अभी-अभी कोड निकाला है, तो आपके द्वारा निकाली गई वस्तु या विधि के विरुद्ध कुछ इकाई परीक्षण लिखें।
- परीक्षण चलाएं, सुनिश्चित करें कि वे अभी भी उत्तीर्ण हैं।
- अगर नियंत्रक को अभी भी काम करने की ज़रूरत है, तो चरण 5 पर वापस जाएं।
आगे क्या है?
यदि आप और अधिक जानना चाहते हैं, तो लिगेसी कोड के साथ प्रभावी ढंग से कार्य करना बिना किसी परीक्षण के अप्राप्य कोड को लेने और इसे किसी ऐसी चीज़ में बदलने की बाईबल है जिसके साथ आप काम कर सकते हैं। मैं इसकी अत्यधिक अनुशंसा करता हूं , यदि आप अपने आप को अक्सर विशाल अखंड नियंत्रकों का सामना करते हुए पाते हैं (और यदि रिफैक्टरिंग आपके लिए उतना ही मजेदार है जितना कि यह मेरे लिए है)।
तो अब, आइए सुनते हैं आपकी डरावनी कहानियां! आपने अब तक जिस सबसे खराब नियंत्रक कोड पर काम किया है, वह कैसा दिखता है?