วิธีการวาดความสนใจของโปรแกรมเมอร์ในเงื่อนไขบางอย่าง?

เริ่มจากตัวอย่างกันก่อน

สมมติว่าฉันมีวิธีที่เรียกexportว่าขึ้นอยู่กับ schema DB อย่างมาก และโดย“ พึ่งพาหนัก” ฉันหมายถึงฉันรู้ว่าการเพิ่มคอลัมน์ใหม่ในตารางหนึ่งบ่อยครั้ง (บ่อยครั้งมาก) จะนำไปสู่exportการเปลี่ยนแปลงวิธีการที่สอดคล้องกัน(โดยปกติแล้วคุณควรเพิ่มเขตข้อมูลใหม่ลงในข้อมูลการส่งออกด้วย)

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

ฉันมีสองแนวคิด แต่ทั้งคู่มีข้อบกพร่อง

เสื้อคลุม "อ่านทั้งหมด" สมาร์ท

ฉันสามารถสร้าง wrapper อัจฉริยะที่ทำให้แน่ใจว่าข้อมูลทั้งหมดอ่านอย่างชัดเจน

บางสิ่งเช่นนี้

def export():
    checker = AllReadChecker.new(table_row)

    name    = checker.get('name')
    surname = checker.get('surname')
              checker.ignore('age') # explicitly ignore the "age" field

    result = [name, surname] # or whatever

    checker.check_now() # check all is read

    return result

ดังนั้นcheckerยืนยันหากtable_rowมีเขตข้อมูลอื่นที่ไม่ได้อ่าน แต่ทุกอย่างดูหนักและอาจส่งผลกระทบต่อความสมบูรณ์แบบ

“ ตรวจสอบวิธีการนั้น ” ไม่ได้

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

ฉันมีความคิดอื่น ๆ เล็กน้อย แต่พวกเขาลำบากเกินกว่าจะนำไปปฏิบัติหรือยากเกินกว่าจะเข้าใจ (และฉันไม่ต้องการให้โครงการกลายเป็นตัวต่อ)

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

คุณกำลังติดตามความคิดการทดสอบหน่วยของคุณอย่างถูกต้อง แต่การนำไปใช้ของคุณผิด

หากสิ่งexportที่เกี่ยวข้องกับสคีมาและสคีมามีการเปลี่ยนแปลงมีสองกรณีที่เป็นไปได้:

• ทั้งสองexportยังคงทำงานได้ดีอย่างสมบูรณ์เพราะมันไม่ได้รับผลกระทบจากการเปลี่ยนแปลงเล็กน้อยในสคีมา

• หรือมันจะแตก

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

ทำไมการปฏิบัติของคุณผิด ด้วยเหตุผลหลายประการ

1. ไม่มีอะไรเกี่ยวข้องกับการทดสอบหน่วย ...

2. ... และจริงๆแล้วมันไม่ใช่การทดสอบ

3. ส่วนที่เลวร้ายที่สุดคือว่าการแก้ไข“การทดสอบ” ต้องดีจริงเปลี่ยน“การทดสอบ” exportที่จะทำการดำเนินงานซึ่งเป็นสมบูรณ์ไม่เกี่ยวข้องกับที่

แต่โดยการทดสอบที่แท้จริงสำหรับขั้นตอนคุณแน่ใจว่านักพัฒนาที่จะแก้ไขexportexport

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

ในขณะที่ฉันพูดเฉพาะเกี่ยวกับชั้นเรียนมันใช้มากหรือน้อยกับหน่วยงานอื่นเช่นกัน ตัวอย่างเช่นการเปลี่ยนแปลงในสคีมาฐานข้อมูลควรสะท้อนให้เห็นโดยอัตโนมัติในรหัสของคุณตัวอย่างเช่นผ่านตัวสร้างโค้ดที่ใช้โดย ORM จำนวนมากหรืออย่างน้อยก็ควรแปลเป็นภาษาท้องถิ่นอย่างน้อย: ถ้าฉันเพิ่มDescriptionคอลัมน์ลงในProductตารางและฉันไม่ใช้ ORM อย่างน้อยฉันก็คาดหวังว่าจะทำการเปลี่ยนแปลงเพียงครั้งเดียวภายในData.Productคลาสของ DAL โดยไม่จำเป็นต้องค้นหาผ่านรหัสฐานทั้งหมดและค้นหาสิ่งที่เกิดขึ้นในProductชั้นเรียนในการพูดชั้นงานนำเสนอ

ถ้าคุณไม่สามารถที่สมเหตุสมผล จำกัด การเปลี่ยนแปลงไปยังสถานที่หนึ่ง (อาจเพราะคุณอยู่ในกรณีที่มันก็ไม่ได้ทำงานหรือเพราะต้องใช้เป็นจำนวนมากของการพัฒนา) แล้วคุณสร้างความเสี่ยงของการถดถอย เมื่อฉันเปลี่ยนคลาสAและคลาสที่Bใดที่หนึ่งในฐานรหัสหยุดทำงานมันเป็นการถดถอย

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

ในทุกกรณีหลีกเลี่ยงการพึ่งพาในกรณีดังกล่าวเพียงแค่แสดงความคิดเห็น สิ่งที่ต้องการ:

// If you change the following line, make sure you also change the corresponding
// `measure` value in `Scaffolding.Builder`.

ไม่เคยทำงาน ไม่เพียง แต่นักพัฒนาซอฟต์แวร์จะไม่อ่านในกรณีส่วนใหญ่ แต่บ่อยครั้งที่มันจะจบลงด้วยการลบหรือย้ายออกไปจากบรรทัดที่เกี่ยวข้องและเป็นไปไม่ได้ที่จะเข้าใจ

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

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

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

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

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

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