कोड के साथ अपने सॉफ़्टवेयर डिज़ाइन को कैसे सुधारें जो गलत लगता है

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

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

सिंटेक्टिक सिरका कैसा दिखता है?

यहां मिनिटेस्ट/मॉक का इस्तेमाल करते हुए सिंटैक्टिक विनेगर का एक उदाहरण दिया गया है, एक छोटा मॉकिंग और स्टबिंग लाइब्रेरी जो रूबी के साथ आता है:

require 'minitest/mock'

class CartTest < MiniTest::Test
  def test_error_message_set_on_charge_failure
    cart = Cart.new(items)
    cart.stub(:charge!, false) do
      cart.checkout!
      assert_equal "The credit card could not be charged", cart.credit_card_error
    end
  end
end

जब आप परीक्षण चलाते हैं, तो charge! Cart पर विधि ठूंठ दिया गया है, इसलिए परीक्षण भुगतान प्रोसेसर से नहीं टकराएगा। ब्लॉक सिंटैक्स यह सुनिश्चित करने के लिए अच्छा है कि आप केवल तभी स्टब करें जब आप चाहते हैं। लेकिन क्या होता है जब आप कई तरीकों को रोकना चाहते हैं?

require 'minitest/mock'

class CartTest < MiniTest::Test
  def test_error_message_set_on_charge_failure
    payment_processor = PaymentProcessor.new
    cart = Cart.new(items, processor: payment_processor)

    payment_processor.stub(:charge!, false) do
      payment_processor.stub(:login!, true) do
        payment_processor.stub(:logout!, true) do
          cart.checkout!
          assert_equal "The credit card could not be charged", cart.credit_card_error
        end
      end
    end
  end
end

ईव। यह बहुत इंडेंटेशन है। और यह सिर्फ एक परीक्षण में है - आप कल्पना कर सकते हैं कि यह कोड कई अन्य परीक्षणों में दोहराया जा रहा है।

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

class TestPaymentProcessor < PaymentProcessor
  def login!(account_id, key)
    true
  end

  def charge!(amount, credit_card)
    credit_card.can_be_charged?
  end

  def logout!
    true
  end
end

class CartTest < MiniTest::Test
  def test_error_message_set_on_charge_failure
    test_payment_processor = TestPaymentProcessor.new
    cart = Cart.new(items, processor: test_payment_processor)
    
    cart.credit_card = failing_credit_card
    cart.checkout!
    assert_equal "The credit card could not be charged", cart.credit_card_error
  end
end

अब आपका परीक्षण अधिक पठनीय है। साथ ही, आपके पास एक TestPaymentProcessor है जिसे और भी कई जगहों पर इस्तेमाल किया जा सकता है। यदि आप वास्तविक सर्वर को हिट नहीं करना चाहते हैं, तो आप इसे विकास मोड में भी इस्तेमाल कर सकते हैं!

खराब कोड को बुरा लगना चाहिए

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

आपके पसंदीदा पुस्तकालय कौन से हैं, और वे खराब कोड को खोजने और ठीक करने में आपकी सहायता कैसे करते हैं? मुझे नीचे कमेंट्स में बताएं!