रिफैक्टरिंग कोड को सरल क्यों बनाता है?

पिछले हफ्ते, मैंने लगातार रिटर्न वैल्यू वाले तरीकों के बारे में लिखा था, और वे आपके कोड को कैसे आसान बनाएंगे। लेकिन ऐसा कैसे होता है? सही रिफैक्टरिंग आपके कोड को काम करने में कैसे आसान बना सकती है? क्या अच्छा अमूर्तन अच्छा बनाता है, और बुरा अमूर्तन बुरा? मेरा मतलब है, आप केवल आँख बंद करके अपने कोड को पुनर्व्यवस्थित नहीं कर सकते और गुणवत्ता वाले सॉफ़्टवेयर के साथ समाप्त नहीं हो सकते।

अगर आप सीख सकते हैं क्यों ये तकनीकें काम करती हैं, आप बेहतर ढंग से समझ पाएंगे कि आपके कोड को कहां मदद की जरूरत है। और आप उन सही टूल का उपयोग करने में सक्षम होंगे जहां वे सबसे अधिक महत्वपूर्ण हैं।

सॉफ़्टवेयर विकास में सबसे कठिन समस्या क्या है?

"कंप्यूटर विज्ञान में केवल दो कठिन समस्याएं हैं:कैश अमान्यता और नामकरण की चीज़ें।"

- फिल कार्लटन

ज़रूर, वह उद्धरण हर जगह है . लेकिन वास्तविक दुनिया के सॉफ्टवेयर विकास में वास्तव में एक कठिन समस्या है:जटिलता का प्रबंधन। सॉफ्टवेयर विकास में जटिलता की कुछ अलग परिभाषाएँ हैं। हालांकि, इसके मूल में, किसी कार्यक्रम की जटिलता उस सामग्री की मात्रा है जिसे आप उस पर काम करते समय अपने दिमाग के सामने रखना चाहते हैं।

जैसे-जैसे आप अधिक सॉफ़्टवेयर लिखते हैं, आप अपने दिमाग में एक ही बार में अधिक सामग्री रखने में सक्षम होंगे। लेकिन सबसे अच्छे देवों की भी सीमाएँ होती हैं। यदि आपकी परियोजना बहुत जटिल है, तो आप अपने दिमाग को संभाल सकते हैं, और आप अपने कार्यक्रम के विभिन्न क्षेत्रों के बारे में भूलना शुरू कर देंगे। और सबसे खराब बग तब दिखाई देते हैं जब आप अपने प्रोजेक्ट के एक हिस्से में बदलाव करते हैं, बिना यह जाने कि यह बदलाव उसी प्रोजेक्ट के पूरी तरह से अलग हिस्से को कैसे प्रभावित करेगा।

अनुमानों के माध्यम से सरलीकरण

यदि आपके पास फोटोग्राफिक मेमोरी थी, और यह याद रख सकते थे कि आपके प्रोग्राम के सभी अलग-अलग हिस्से एक साथ कैसे फिट होते हैं, तो आपके पास बहुत कम बग होंगे, है ना? मेमोरी बनाना मुश्किल हो सकता है। लेकिन आप एक समय में एक ही चीज़ पर ध्यान केंद्रित करने में सक्षम होने से समान लाभ प्राप्त कर सकते हैं।

सॉफ़्टवेयर विकास में कई सर्वोत्तम अभ्यास उन चीज़ों की संख्या को कम करने के बारे में हैं जिन्हें आपको एक बार में अपने दिमाग में रखना है। कुछ उदाहरण:

• आपके वापसी मूल्यों में एकरूपता इसका मतलब है कि आपको अलग-अलग स्थितियों में अलग-अलग तरह के डेटा के बजाय केवल एक तरह के डेटा से निपटने के बारे में सोचना होगा।

• अमूर्त सरल इंटरफ़ेस के पीछे कोड छिपाने का एक तरीका है। अच्छे एब्स्ट्रैक्शन के साथ, आप बस इस बारे में सोच सकते हैं कि एब्स्ट्रैक्शन चाहिए कार्य करें, और आपको इस बारे में चिंता करने की ज़रूरत नहीं है कि यह अंदर से कैसे काम करता है।

• परीक्षण जब आप दूसरे क्षेत्र में काम कर रहे हों तो आपको एक क्षेत्र में गलती से कोड तोड़ने से बचा सकता है। आप मान सकते हैं कि आप गलती से जो कुछ भी तोड़ेंगे वह पकड़ा जाएगा। इसका मतलब है कि आप केवल उस कोड पर ध्यान केंद्रित कर सकते हैं जिस पर आप काम कर रहे हैं, और जो कुछ भी आप बाद में तोड़ते हैं उसे ठीक कर सकते हैं।

• परीक्षण संचालित विकास आपको कोड लिखने में मदद करेगा जो उस तरह से काम करेगा जिस तरह से आपने इसे काम करने की उम्मीद की थी। आप परीक्षण पास करने वाली अपनी पद्धति के सबसे सरल संभव कार्यान्वयन को लिखने पर ध्यान केंद्रित कर सकते हैं। यदि यह बहुत आसान है और वास्तव में आपकी अपेक्षा के अनुरूप काम नहीं करता है, तो आपके परीक्षण इसे पकड़ लेंगे।

जब आप इन तकनीकों का सही तरीके से उपयोग करते हैं, तो आप कुछ अच्छी धारणाएँ बना सकते हैं। इन धारणाओं के साथ, आपको अपने दिमाग के सामने कहीं भी उतना पास नहीं रखना है। आप बेहतर, अधिक विश्वसनीय कोड लिख सकते हैं, क्योंकि आपको अपने कोड के सिस्टम पर होने वाले लगभग अनंत परिणामों के बारे में चिंता करने की आवश्यकता नहीं है।

दूसरी ओर, इन तकनीकों का गलत स्थान पर उपयोग करने से छिपा . होगा कोड जिसे आपको वास्तव में देखने की आवश्यकता है। कोड को छुपाने से, आपके द्वारा की गई धारणाएं कभी-कभी गलत हो जाती हैं। यह इसे और भी अधिक बनाता है संभावना है कि आप इसे तोड़ देंगे!

इसीलिए खराब एब्स्ट्रैक्शन बिना किसी एब्स्ट्रैक्शन से भी बदतर हैं, और जब तक यह जादुई रूप से अच्छा नहीं हो जाता, तब तक आप कोड पर "एक्सट्रैक्ट मेथड" को फेंक नहीं सकते।

राइट रिफैक्टरिंग, सही जगह

स्पष्ट कोड वह कोड है जो इसके बारे में सबसे आगे है कि वह क्या कर रहा है। आपको जो जानना आवश्यक है, उसे दिखाना उतना ही महत्वपूर्ण है जितना कि वह छिपाना जो आपको जानने की आवश्यकता नहीं है। जब आप रिफैक्टरिंग करते हैं, या किसी सॉफ़्टवेयर के सर्वोत्तम अभ्यास का उपयोग करते हैं, तो आपको उस कोड के बारे में सोचना चाहिए जिसके साथ आप समाप्त होते हैं, और यह कितनी अच्छी तरह से आपको जटिलता को कम करने में मदद करता है। क्या आप बाकी कोड को अच्छा बनाने में मदद कर रहे हैं, धारणाओं को सरल बना रहे हैं? या आप एक बहुत ही सरल इंटरफ़ेस के पीछे आवश्यक ज्ञान छिपा रहे हैं?