Cách cải thiện thiết kế phần mềm của bạn với mã cảm thấy sai

Bạn biết mình muốn gì để làm, nhưng mã của bạn không hợp tác. Có thể nó có quá nhiều mức độ thụt lề, hoặc chuỗi nửa tá phương thức, hoặc trông không đối xứng. Dù nó là gì, một cái gì đó chỉ cảm thấy tắt. Bạn có thể bỏ qua nó - ý tôi là, bạn có một công việc tồn đọng với đầy đủ các tính năng mà bạn vẫn muốn viết và nó thực sự không điều đó xấu. Nhưng đó sẽ là một sai lầm:Mã của bạn đang cố cho bạn biết điều gì đó và bạn không muốn bỏ lỡ nó.

Nếu bạn có thể học cách nhận biết khi nào mã của bạn cảm thấy lạ, bạn sẽ nhanh chóng và cải thiện đáng kể kỹ năng thiết kế phần mềm của mình . Trực giác này rất khó xây dựng, vì nó đến từ kinh nghiệm, sự cố vấn và đánh giá mã. Tuy nhiên, bạn có thể nhận được một số trợ giúp từ các thư viện sử dụng giấm cú pháp để làm cho mã xấu trở nên tồi tệ.

Giấm cú pháp trông như thế nào?

Dưới đây là một ví dụ về giấm cú pháp bằng cách sử dụng minitest / mock, một thư viện nhỏ chế nhạo và khai thác đi kèm với Ruby:

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

Khi bạn chạy thử nghiệm, charge! phương thức trên Cart còn sơ khai, vì vậy thử nghiệm sẽ không ảnh hưởng đến bộ xử lý thanh toán. Cú pháp khối rất hay để đảm bảo rằng bạn chỉ khai báo chính xác khi bạn muốn. Nhưng điều gì sẽ xảy ra khi bạn muốn khai thác một loạt các phương pháp?

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

Ờ. Đó là rất nhiều thụt lề. Và đó chỉ là trong một thử nghiệm duy nhất - bạn có thể tưởng tượng mã này được lặp lại trong rất nhiều thử nghiệm khác.

Bạn có thể bọc tất cả sự lồng ghép này vào một phương thức trình trợ giúp thử nghiệm. Nhưng nếu bạn thực sự nghe mã của bạn, nó cho bạn biết rằng bạn nên tìm một cách tốt hơn. Có thể đã đến lúc xem xét sử dụng Test Double thay thế:

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

Bây giờ bài kiểm tra của bạn dễ đọc hơn. Ngoài ra, bạn có TestPaymentProcessor có thể được sử dụng ở rất nhiều nơi khác. Bạn thậm chí có thể sử dụng nó trong chế độ phát triển, nếu bạn không muốn sử dụng máy chủ thực!

Mã không hợp lệ sẽ rất tệ

Bằng cách sử dụng các thư viện cố định làm cho mã xấu trở nên rõ ràng, bạn sẽ bắt đầu nhận thấy mã xấu nhanh hơn và đáng tin cậy hơn nhiều. Và điều đó sẽ làm cho mã trong tương lai của bạn sạch hơn, dễ đọc hơn và ít khó làm việc hơn.

Thư viện cố ý yêu thích của bạn là gì và chúng giúp bạn tìm và sửa mã xấu như thế nào? Hãy cho tôi biết trong phần bình luận bên dưới!