कोड की गंध पहचानकर और ठीक करके सॉफ्टवेयर डिज़ाइन को बेहतर बनाएं

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

अगर आप सीख लें कि कब कोड अजीब लगता है, तो आप तेज़ी से और नाटकीय रूप से अपने सॉफ्टवेयर डिज़ाइन कौशल को सुधारेंगे

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

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

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

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

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

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 है जिसे कई अन्य जगहों पर इस्तेमाल किया जा सकता है। आप इसे डेवलपमेंट मोड में भी उपयोग कर सकते हैं, अगर आप असली सर्वर को हिट नहीं करना चाहते!

खराब कोड को खराब महसूस होना चाहिए

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

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