เมื่อเคส Edge เจาะรูในโซลูชันที่สมบูรณ์แบบของคุณ

คุณพบวิธีแก้ปัญหาที่สมบูรณ์แบบสำหรับปัญหาการทดสอบที่บ้าคลั่งของคุณ สิ่งที่คุณต้องทำคือแทนที่ DEFAULT_HOST คงที่และคุณจะอยู่ในธุรกิจ

ยกเว้นว่าคุณต้องปิดคำเตือนเพื่อให้ข้อความน่าเกลียดหายไป แต่ ตอนนี้ การทดสอบทั้งหมดของคุณผ่าน และคุณต้องเปลี่ยนโค้ดเพียงไม่กี่บรรทัด!

ยกเว้นการทดสอบที่คุณ ไม่ ต้องการแทนที่โฮสต์ แต่คุณสามารถแทนที่ค่าคงที่ใหม่ ปิดการเตือนอีกครั้ง และตรวจดูให้แน่ใจว่าค่าคงที่ถูกรีเซ็ตเมื่อสิ้นสุดการทดสอบ ใกล้จะเสร็จแล้ว เกือบจะได้ชิมแล้ว!

ยกเว้น… ยกเว้น… ยกเว้น…

และสองสามวันต่อมา เมื่อคุณติดค้างเป็นครั้งที่ยี่สิบเจ็ดและแอปของคุณกลายเป็นลูกแฮ็กขนาดยักษ์ คุณจะนั่งลงและสงสัยว่า:ทำไมฉันถึง ทำ ทั้งหมดนี้? วิธีแก้ปัญหาไม่เลวร้ายไปกว่าปัญหาหรอกหรือ

วิธีแก้ปัญหาที่ฉลาดเกินไป

ชัดเจนว่าความคิดเดิมของคุณไม่สามารถแก้ปัญหาทั้งหมดของคุณได้ แล้วคุณคิดว่า ดีกว่า . ได้อย่างไร ไอเดียที่แก้ปัญหาขอบทุกด้านที่ไอเดียเดิมของคุณทำไม่ได้

คุณไม่สามารถ คุณไม่สามารถต่อสู้กับความฉลาดมากเกินไปด้วยความฉลาดที่มากกว่านี้ อย่างน้อยก็ไม่ได้โดยตรง ให้ไปทางอื่นแทน ไปง่ายๆ ตรงไปตรงมา

หมายความว่าไง

อินไลน์โค้ดที่คุณพยายามแยกออก ทำ ทำซ้ำตัวเอง รักษารหัสของคุณอย่างชัดเจน

หากคุณกำลังพยายามแทนที่ DEFAULT_HOST คงที่กับโฮสต์เริ่มต้นอื่น ลืมแนวคิดทั้งหมดเกี่ยวกับค่าเริ่มต้น เพียงระบุทุกครั้ง

ดังนั้น แทนที่จะเป็น:

require 'test_helper'

silence_warnings do
  Rack::Test::DEFAULT_HOST = "www.justinweiss.com"
end

class WelcomeTest < ActionDispatch::IntegrationTest
  include Rack::Test::Methods
  
  test "can visit the homepage" do
    get "/"
    # ...
  end

  # ...
end

ทำสิ่งที่ชอบ:

require 'test_helper'

class WelcomeTest < ActionDispatch::IntegrationTest
  test "can visit the homepage" do
    get "https://www.justinweiss.com/"
    # ...
  end
  # ...
end

เมื่อใดก็ตามที่โซลูชันที่ดูเหมือนสมบูรณ์แบบของฉันพัง นั่นเป็นเพราะฉันไม่ได้นึกภาพกรณีที่ในที่สุดฉันจะต้องจัดการ

ไม่เป็นไร. เราไม่สามารถทำนายอนาคตได้ แต่เมื่อคุณสังเกตเห็นมันเกิดขึ้น ให้หยุดขุดคุ้ย อย่าเพิ่งใช้แพทช์หลังจากแพทช์หลังจากแพทช์ ให้คลี่คลายโซลูชันเดิมของคุณและ แยก ดีกว่า

วิธีการแยกวิธีแก้ปัญหาที่ดีกว่า

เมื่อคุณเขียนโค้ดทั้งหมดอย่างชัดเจนและตรงไปตรงมา คุณจะเริ่มคิดหาวิธีจัดระเบียบใหม่

โดยปกติแล้ว การใช้ Extract Method หรือ Extract Class ให้ถูกที่ก็เพียงพอแล้ว เคล็ดลับคือการตัดสินใจว่าสถานที่ที่เหมาะสมคืออะไร แต่การหาสิ่งนั้นจะง่ายกว่ามากเมื่อคุณเห็นการซ้ำซ้อนอยู่ตรงหน้าคุณ

และพึ่งพามรดกและการมอบอำนาจ สิ่งเหล่านี้คือองค์ประกอบพื้นฐานง่ายๆ ที่จะช่วยให้คุณล้างโค้ดได้โดยไม่ฉลาดเกินไป

อีกสิ่งหนึ่ง

อย่าลืมอ่านเอกสาร:

require 'test_helper'

class WelcomeTest < ActionDispatch::IntegrationTest

  setup do
    # This already exists:
    host! "www.justinweiss.com"
  end
  
  test "can visit the homepage" do
    get "/"
    # ...
  end
  # ...
end

คำตอบจะไม่ชัดเจนเสมอไป แต่ไม่มีอะไรที่อ่อนน้อมถ่อมตนมากไปกว่าการตระหนักว่ามีวิธีแก้ปัญหาในตัวแบบเดียวสำหรับปัญหาที่คุณเขียนถึงสามคลาสและอัญมณีที่ต้องแก้ไข

ทางออกที่ดีกว่าในท้ายที่สุด

วิธีแก้ปัญหาที่สองของคุณมักจะดีกว่าในทุกวิถีทาง กว่าเดิม

ทำไมถึงเป็นเช่นนั้น?

• คุณมีประสบการณ์มากขึ้นในฐานะนักพัฒนา

  ดังนั้นคุณจะมีความคิดที่ดีขึ้นว่าอะไรคือการสร้างโค้ดที่ดี

• คุณรู้เพิ่มเติมเกี่ยวกับระบบที่คุณสร้างขึ้น

  คุณจึงตัดสินใจได้ดีขึ้นว่าโค้ดที่คุณเขียนนั้นเข้ากันได้อย่างไร

• คุณรู้ว่าสมมติฐานใดของคุณผิด

  ดังนั้นวิธีแก้ปัญหาของคุณจึงเหมาะกับปัญหาที่มีอยู่จริงมากกว่า ไม่ใช่ปัญหาที่คุณจินตนาการ อาจ มีอยู่จริง

และในที่สุด อาจมีที่สำหรับความฉลาดที่ดีที่สุดของคุณ คราวนี้โดยไม่มีการแฮ็ก

คุณต้องหยุดขุด

รหัสที่ชาญฉลาดคือความสนุกในการเขียน ใน Ruby นั้นเขียนได้ง่ายเช่นกัน และมันง่ายมากที่จะเดินไปตามทาง แม้ว่าคุณจะรู้ว่ามันกำลังพาคุณไปผิดที่

แต่เมื่อเข้าใจความรู้สึกที่จู้จี้ว่ามีบางอย่างไม่ถูกต้อง ให้หยุดสักครู่ Un-factor รหัสของคุณ อ่านเอกสาร ทำให้โค้ดของคุณตรงไปตรงมาและชัดเจน และหาวิธีที่ดีกว่านี้

คุณจำครั้งสุดท้ายที่คุณขุดหลุมที่ไม่มีวันจบได้ด้วยตัวเองหรือไม่? คุณเป็นยังไงบ้าง เอาตัวเองออกจากมัน? แล้วโค้ดที่คุณลงเอยด้วยหน้าตาเป็นอย่างไร