मजबूती सिद्धांत के साथ रूबी कोड विश्वसनीयता बढ़ाएं

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

आपका current_user मेथड एक User वापस करता है, सिवाय जब कोई यूजर नहीं होता और यह nil वापस करता है। एक search मेथड परिणामों का एक Array वापस करता है, जब तक कि केवल एक परिणाम न हो, और यह उस परिणाम को वापस कर देता है। उचित लगता है, है ना? शायद सुविधाजनक भी!

लेकिन जल्द ही, ये निर्णय आपके कोड को if स्टेटमेंट्स के पहाड़ के नीचे दबा देंगे। शायद यह हर जगह छिड़के हुए if kind_of? का एक गुच्छा है। या शायद आपको लगता है कि आपको हर जगह nil की जांच करनी होगी। या बदतर, NoMethodErrors हर बार दिखाई देने लगते हैं जब आप एक नई फीचर शिप करते हैं। लगता है एक और हॉटफिक्स का समय आ गया है!

इसे रोकने का एक तरीका है, हालांकि, और इसमें बस थोड़ी सी विचारशीलता लगती है।

मजबूती सिद्धांत

कंप्यूटिंग में एक सिद्धांत है जो कहता है,

आप जो करते हैं उसमें रूढ़िवादी बनें, दूसरों से जो स्वीकार करते हैं उसमें उदार बनें।

आप इस सिद्धांत को अपने रूबी मेथड पर लागू कर सकते हैं। आपके द्वारा लिखे गए मेथड को उचित इनपुट स्वीकार करना चाहिए, और सुसंगत आउटपुट वापस करना चाहिए।

अंतिम भाग पर ध्यान केंद्रित करते हुए: जब कोई आपके द्वारा लिखे गए मेथड को कॉल करता है, तो उन्हें ठीक-ठीक पता होना चाहिए कि वह मेथड क्या वापस करेगा।

अपने आउटपुट के बारे में विचारशील बनें

रेल्स 2.1 के ActiveRecord::Errors#on के कार्यान्वयन पर एक नज़र डालें:

# File activerecord/lib/active_record/validations.rb, line 212 def on(attribute) attribute = attribute.to_s return nil unless @errors.has_key?(attribute) errors = @errors[attribute].map(&:to_s) errors.size == 1 ? errors.first : errors end 

जब कॉल किया जाता है, तो यह या तो Strings का एक Array, एक String, या nil वापस कर सकता है। यह कॉलर पर निर्भर करता है कि वह यह पता लगाए कि वह किस प्रकार के ऑब्जेक्ट के साथ काम कर रहा है। यह एक बुरा विचार है:

• कॉलर को अपने स्वयं के कोड को घुसपैठ करने वाले टाइप-चेकिंग के साथ गंदा करना पड़ता है।

• कॉलर को उस मेथड के बारे में बहुत कुछ जानना होगा जिसे वह कॉल कर रहा है। न्यूनतम, उसे मेथड द्वारा वापस किए जा सकने वाले हर प्रकार के ऑब्जेक्ट को जानना होगा और प्रत्येक प्रकार को कब वापस किया जा सकता है।

• आपके पास टेस्ट करने के लिए अधिक एज केस हैं। यदि आप आश्वस्त होना चाहते हैं कि आपका कोड वही कर रहा है जो उसे करना चाहिए, तो आपको सभी तीन परिदृश्यों को आजमाना होगा।

आपके मेथड को इस बारे में सुसंगत होना चाहिए कि वे क्या वापस करते हैं। यदि आप आमतौर पर एक Array वापस करते हैं, तो हमेशा एक Array वापस करने के लिए आपको जो करना है वह करें। यदि आप आमतौर पर एक User वापस करते हैं, लेकिन कभी-कभी nil वापस करते हैं, तो आप एक नल यूजर ऑब्जेक्ट बना सकते हैं और nil के बजाय वह वापस कर सकते हैं।

आप कम सख्त भी हो सकते हैं: "मैं Taggable मॉड्यूल शामिल करने वाली कोई चीज वापस करने जा रहा हूँ"। आप अधिक सामान्य जा सकते हैं: "मैं id और name विशेषताओं वाली कोई चीज वापस करने जा रहा हूँ।" महत्वपूर्ण बात स्थिरता है और यह सुनिश्चित करना कि आपका कॉलर जानता है कि क्या उम्मीद करनी है।

jQuery एक दिलचस्प उदाहरण है। अधिकांश jQuery मेथड एक ही प्रकार की Array-जैसी ऑब्जेक्ट वापस करते हैं। इस वजह से, jQuery के मेथड अविश्वसनीय रूप से कंपोजेबल हैं, और आप कोड की एक ही लाइन में पागल मात्रा में काम कर सकते हैं।

और यदि आप सोच रहे थे, तो रेल्स ने बाद के संस्करणों में उस मेथड को ठीक कर दिया:

# File activemodel/lib/active_model/errors.rb, line 133 def [](attribute) get(attribute.to_sym) || set(attribute.to_sym, []) end 

अब यह हमेशा एक Array वापस करता है। उनके लिए सरल, और हमारे लिए सरल।

असंगति को मारें

अगली बार जब आप खुद को "एक Array या nil" वापस करते हुए पाएं, तो बस एक Array वापस करें। अपने कोडबेस के माध्यम से देखें और देखें कि आप कहां kind_of? और respond_to? का उपयोग कर रहे हैं। देखें कि क्या आप उन मेथड को रिफैक्टर कर सकते हैं जिन्हें वह कोड कॉल करता है ताकि वे एक ही प्रकार वापस करें।

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