การปรับโครงสร้างใหม่ - เหมาะสมหรือไม่ที่จะเขียนรหัสใหม่อีกครั้งตราบใดที่การทดสอบทั้งหมดผ่าน?

ฉันเพิ่งดู"ทุกสิ่งเล็ก ๆ น้อย ๆ "จาก RailsConf 2014 ในระหว่างการพูดคุยนี้ Sandi Metz refactors ฟังก์ชั่นที่รวมถึงคำสั่ง if ซ้อนขนาดใหญ่:

def tick
    if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert'
        if @quality > 0
            if @name != 'Sulfuras, Hand of Ragnaros'
                @quality -= 1
            end
        end
    else
        ...
    end
    ...
end

ขั้นตอนแรกคือการแบ่งฟังก์ชั่นออกเป็นหลาย ๆ อันเล็ก ๆ :

def tick
    case name
    when 'Aged Brie'
        return brie_tick
    ...
    end
end

def brie_tick
    @days_remaining -= 1
    return if quality >= 50

    @quality += 1
    @quality += 1 if @days_remaining <= 0
end

สิ่งที่ฉันคิดว่าน่าสนใจคือวิธีที่ฟังก์ชั่นเล็ก ๆ เหล่านี้เขียนขึ้น brie_tickตัวอย่างเช่นไม่ได้เขียนโดยการแยกส่วนที่เกี่ยวข้องของtickฟังก์ชั่นดั้งเดิมแต่เริ่มต้นจากการอ้างอิงถึงการtest_brie_*ทดสอบหน่วย เมื่อผ่านการทดสอบหน่วยเหล่านี้แล้วbrie_tickก็ถือว่าเสร็จสิ้น เมื่อฟังก์ชั่นขนาดเล็กทั้งหมดเสร็จสิ้นแล้วtickฟังก์ชั่นเสาหินเดิมจะถูกลบ

น่าเสียดายที่ผู้นำเสนอดูเหมือนไม่ทราบว่าวิธีการนี้นำไปสู่การสามในสี่*_tickหน้าที่ผิด (และอีกอันว่างเปล่า!) มีกรณีขอบซึ่งพฤติกรรมของ*_tickฟังก์ชั่นที่แตกต่างจากtickฟังก์ชั่นเดิม ยกตัวอย่างเช่น@days_remaining <= 0ในbrie_tickควรจะเป็น< 0- เพื่อให้brie_tickไม่สามารถทำงานได้อย่างถูกต้องเมื่อเรียกด้วย และdays_remaining == 1quality < 50

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

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

ทั้งสอง การสร้างใหม่โดยใช้ขั้นตอนมาตรฐานจากหนังสือต้นฉบับของ Fowlersนั้นมีข้อผิดพลาดน้อยกว่าการเขียนซ้ำดังนั้นจึงมักจะดีกว่าที่จะใช้ขั้นตอนทารกชนิดนี้เท่านั้น แม้ว่าจะไม่มีการทดสอบหน่วยสำหรับทุกกรณีที่มีขอบและแม้ว่าสภาพแวดล้อมจะไม่ให้การรีแฟคเตอร์อัตโนมัติการเปลี่ยนรหัสเดียวเช่น "แนะนำตัวแปรอธิบาย" หรือ "ฟังก์ชั่นดึงข้อมูล" มีโอกาสน้อยกว่ามากในการเปลี่ยนรายละเอียดพฤติกรรมของ รหัสที่มีอยู่กว่าฟังก์ชั่นเขียนใหม่ที่สมบูรณ์

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

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

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

สิ่งหนึ่งที่ยากมากเกี่ยวกับการทำงานกับรหัสดั้งเดิมคือการได้รับความเข้าใจที่สมบูรณ์เกี่ยวกับพฤติกรรมปัจจุบัน

รหัสดั้งเดิมที่ไม่มีการทดสอบที่ จำกัด พฤติกรรมทั้งหมดเป็นรูปแบบทั่วไปใน wild ข้อใดทำให้คุณเดา: นั่นหมายความว่าพฤติกรรมที่ไม่มีข้อ จำกัด เป็นตัวแปรอิสระหรือไม่ หรือข้อกำหนดที่ไม่ได้ระบุไว้หรือไม่

จากการพูดคุย :

ตอนนี้เป็นการปรับโครงสร้างใหม่ตามคำจำกัดความของการปรับโครงสร้างใหม่ ฉันจะ refactor รหัสนี้ ฉันจะเปลี่ยนการจัดเรียงโดยไม่เปลี่ยนพฤติกรรมของมัน

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

ในบางกรณีคุณสามารถยืนยันได้ว่าหากการทดสอบไม่สามารถอธิบายพฤติกรรมของระบบได้ว่าคุณมี "ความล้มเหลวในการทดสอบ" และฉันคิดว่ามันยุติธรรม - แต่ไม่มีประโยชน์จริง ๆ นี่เป็นปัญหาที่พบโดยทั่วไปในป่า

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

ปัญหาไม่ได้ค่อนข้างที่แปลงควรจะได้รับการขั้นตอนโดยขั้นตอน; แต่แทนที่จะเป็นทางเลือกของเครื่องมือ refactoring (ผู้ประกอบการแป้นพิมพ์ของมนุษย์? มากกว่าระบบอัตโนมัติที่แนะนำ) ไม่สอดคล้องกับการครอบคลุมการทดสอบเนื่องจากอัตราความผิดพลาดสูงขึ้น

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

ดังนั้นฉันคิดว่าเพื่อนร่วมงานของคุณได้รับการคัดเลือกไม่ดี ไม่ANDOR

การสร้างใหม่ไม่ควรเปลี่ยนพฤติกรรมที่มองเห็นได้จากภายนอกของรหัสของคุณ นั่นคือเป้าหมาย

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

การทดสอบหน่วยการทำงานในกรณีนี้ให้ความรู้สึกผิดที่ประสบความสำเร็จเท่านั้น แต่เกิดอะไรขึ้น สองสิ่ง: การปรับโครงสร้างใหม่นั้นไม่ประมาทและการทดสอบหน่วยก็ไม่ค่อยดีนัก

หากคุณกำหนดว่า "ถูกต้อง" ให้เป็น "การทดสอบผ่าน" ดังนั้นตามคำนิยามมันไม่ผิดที่จะเปลี่ยนพฤติกรรมที่ยังไม่ทดลอง

หากควรกำหนดลักษณะการทำงานของขอบเฉพาะให้เพิ่มการทดสอบหากไม่เป็นเช่นนั้นก็โอเคที่จะไม่สนใจว่าจะเกิดอะไรขึ้น หากคุณเชื่องช้าจริงๆคุณสามารถเขียนการทดสอบที่ตรวจสอบtrueว่าในกรณีที่ขอบเพื่อเอกสารที่คุณไม่สนใจว่าพฤติกรรมคืออะไร