कोड हैंडकफ से बचें: क्लीनर सॉफ्टवेयर के लिए कमजोर अभास्ट्रैक्शन का प्रबंधन

(यह पोस्ट कुछ महीने पहले मेरी सूची को भेजी गई एक पोस्ट पर आधारित है। हर हफ्ते इस तरह की और पोस्ट पढ़ने के लिए, यहां जुड़ें!)

Using a Little Bit of Convenience to Save Your Programming Flow में, मैंने इस बारे में बात की कि कैसे सबसे सरल अभास्ट्रैक्शन आपके कोडबेस को काम करने में अधिक मजेदार बना सकते हैं।

लेकिन क्या होता है जब आपके पास एक खराब अभास्ट्रैक्शन होता है?

आप हर बार API रेफरेंस खोदते हैं यह समझने के लिए कि वह मेथड जो स्पष्ट रूप से leaderboard नाम होना चाहिए था, वास्तव में क्या कहलाता है। आप इसके चारों ओर रीफैक्टर करने की कोशिश करते हैं, लेकिन कोड का एक हिस्सा आपको संरचित डेटा देता है और दूसरा हिस्सा आपको टेक्स्ट की कच्ची लाइनें देता है। और हर बार जब आप कोड को छूते हैं, तो कुछ टूट जाता है, और आप बाकी दिन इसे डीबग करने की कोशिश में बिता देते हैं। क्योंकि आपने position को ट्वीक किया, लेकिन score को उसी समय अपडेट नहीं किया।

तो आप अच्छी अभास्ट्रैक्शन कैसे बनाते हैं, जबकि बुरी से दूर रहते हैं?

स्पष्ट कोड लिखने के लिए अच्छे रूपकों का उपयोग करना

अच्छी अभास्ट्रैक्शन अच्छे रूपकों से आती हैं।

एक रूपक आपके सिस्टम में किसी चीज़ का वर्णन करता है उसे एक ऐसी अवधारणा से जोड़कर जो पहले से ही आपके दिमाग में है। उदाहरण के लिए:

• कई कमांड लाइन्स पाइप के रूपक का उपयोग करते हैं।

  आप डेटा को पाइप के एक छोर में डालते हैं, और यह दूसरे छोर से बाहर आता है। कल्पना करना आसान और उपयोग करना आसान।

• समवर्ती प्रोग्रामिंग में, एक लॉक एक अच्छा रूपक है।

  बिना यह जाने कि लॉक आंतरिक रूप से कैसे काम करते हैं, आप जानते हैं कि जब कोई संसाधन लॉक हो जाता है, तो आप इसका उपयोग नहीं कर सकते। आपको तब तक इंतजार करना होगा जब तक यह अनलॉक न हो जाए।

• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, मैसेज पासिंग एक विशिष्ट मानसिक छवि को ट्रिगर करता है: एक ऑब्जेक्ट दूसरे ऑब्जेक्ट को एक मैसेज पास करता है। दूसरा ऑब्जेक्ट मैसेज के साथ कुछ कर सकता है या इसे किसी और को पास कर सकता है।

  आइडिया प्राप्त करने के लिए आपको कार्यान्वयन के बारे में कुछ भी जानने की आवश्यकता नहीं है (और यह प्रॉक्सी पैटर्न जैसी चीजों को समझना बहुत आसान बनाता है)।

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

आप अच्छे रूपक कैसे लेकर आते हैं?

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

अच्छे रूपक लाना कठिन है। आप अक्सर कुछ लीक रूपकों से गुजरेंगे इससे पहले कि आप सही वाला ढूंढ सकें, और यह ठीक है! अभ्यास के साथ यह आसान हो जाएगा। लेकिन यहां एक प्रक्रिया है जिसने मेरी मदद की है:

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

फिर, उस छवि के बारे में सोचें। क्या यह फिट बैठता है कि वह कोड कैसे काम करता है? क्या ऐसे एज केस हैं जो रूपक के माध्यम से लीक होते हैं? क्या रूपक के अलावा कुछ ऐसा है जिसे एक नए योगदानकर्ता को कोड का उपयोग करने से पहले समझना होगा? जब आप अपने रूपक के बारे में सोचते हैं, तो क्या आपको अपने दिमाग में एक स्पष्ट तस्वीर मिलती है, या यह धुंधली है?

ये संकेतक हैं कि आपका रूपक आपके कोड से पर्याप्त रूप से मेल नहीं खाता। लेकिन आप एक अच्छे रूपक के जितने करीब हैं, उतनी कम छलांग आपको वहां पहुंचने के लिए लगानी पड़ेगी।

अंत में, इसे एक वाक्य में उपयोग करें। "यह कोड है एक (कुछ), क्योंकि…" क्या आप अपने रूपक को बिना तकनीकी पृष्ठभूमि वाले किसी को समझा सकते हैं, और क्या वे समझ सकते हैं कि यह क्या करता है? किसी को रूपक को समझने के लिए जितनी कम पृष्ठभूमि की आवश्यकता होती है, उतना ही अधिक सहायक आपका रूपक होगा।

यदि आप करीब हैं, लेकिन बिल्कुल नहीं, तो एक थीसॉरस में देखें। समान शब्दों के बीच सूक्ष्म अंतर एक ठीक रूपक और एक पूर्ण रूपक के बीच का अंतर हो सकता है।

रूपक और OOP

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग मूल रूप से रूपक पर आधारित है। यहीं से इसे इसकी शक्ति मिलती है! अच्छी तरह से डिज़ाइन की गई क्लासेस न केवल अपने कार्यान्वयन को अन्य क्लासेस से छुपाती हैं, वे इसे आपसे छुपाती हैं।

एक महान रूपक के साथ, आपको केवल क्लास नाम से यह बताने में सक्षम होना चाहिए कि अपने ऑब्जेक्ट्स का उपयोग कैसे करना है। यदि आपकी क्लासेस का नाम अच्छी तरह से रखा गया है, और वे आपके दिमाग में सही छवियां पैदा करती हैं, तो आपको उनका उपयोग करने के लिए उनके कार्यान्वयन में गोता नहीं लगाना चाहिए।

तो अब, मैं चाहूंगा कि आप उस अंतिम कोड के बारे में सोचें जिस पर आपने काम किया था। क्या आप किसी ऐसी क्लास के बारे में सोच सकते हैं जिनमें विशेष रूप से स्पष्ट रूपक हैं? कौन सी क्लासेस आपको लगता है कि आप उनके साथ काम करते हैं, बजाय उनके विरुद्ध काम करने के? आप कितनी बार यह पता लगाने के लिए उनमें खुदाई करते हैं कि उनका उपयोग कैसे करना है?

मुझे यह सुनना अच्छा लगेगा कि आप क्या पता लगाते हैं। एक कमेंट छोड़ें, और मुझे बताएं।

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

प्रैक्टिसिंग रेल्स का मेरा मुफ्त 32-पेज का सैंपल डाउनलोड करें, और सीखें कि इस तरह के विचारों को छोटे पैमाने पर कैसे आजमाया जाए, बिना अभिभूत हुए।