ข้อบกพร่องเป็นส่วนหนึ่งของหนี้ทางเทคนิคหรือไม่

Scrum Master ของเรายังคงอ้างถึงข้อบกพร่องเป็นหนี้ทางเทคนิค เขาคิดถูกไหมข้อบกพร่องถือเป็นหนี้ทางเทคนิคในโลกของ Agile หรือไม่?

ฉันคิดว่าคำตอบที่นี่ค่อนข้างง่าย - คุณสมบัติที่สำคัญของหนี้ทางเทคนิคคือสิ่งที่เราต้องทำโดยเลือก

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

ข้อผิดพลาดไม่ใช่สิ่งที่เราเลือกที่จะมีในรหัสของเรา - ดังนั้นความจริงไม่ใช่หนี้ทางเทคนิค

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

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

ใช่.

หนี้ทางเทคนิค (หรือเรียกอีกอย่างว่าหนี้การออกแบบหรือหนี้รหัส) เป็นคำเปรียบเทียบที่เกี่ยวข้องกับผลที่เกิดขึ้นในที่สุดของสถาปัตยกรรมซอฟต์แวร์ที่น่าสงสารหรือการพัฒนาซอฟต์แวร์และการพัฒนาซอฟต์แวร์ในรหัสฐาน

ที่มา: Wikipedia

อ่านหนี้ทางเทคนิคเป็นสิ่งที่คุณสามารถหลีกเลี่ยงได้โดยมีเวิร์กโฟลว์ที่ดีขึ้น (ตัวอย่างเช่นการทำสถาปัตยกรรมอย่างถูกต้องก่อนที่จะกระโดดไปยังการเข้ารหัสทำ TDD ฯลฯ ) การเขียนโค้ดที่ดีขึ้น ฯลฯ

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

หลังจากอ่านคำตอบของBЈовићฉันเห็นว่ามันอาจไม่ง่ายอย่างที่คิด

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

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

• ในที่สุดเมื่อสร้างแบบจำลองของหนี้สินทางเทคนิค ABCDE-Tฉันรวมข้อบกพร่องเป็นหนึ่งในหกปัจจัย แต่พวกเขาถือว่าแตกต่างกัน การมุ่งเน้นไม่ได้อยู่ที่ข้อบกพร่องของตัวเอง แต่เกี่ยวกับวิธีการรวบรวมจัดลำดับความสำคัญและแก้ไข บั๊กเองปรากฏเป็นผลมาจากหนี้ทางเทคนิค (เช่นในตัวอย่างก่อนหน้า) แต่ไม่ปรากฏว่าตัวเองเป็นปัจจัยของหนี้ทางเทคนิค

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

อาร์กิวเมนต์แรก:

การอ่านคำพูดของ Jeff Atwood ข้อบกพร่องส่วนใหญ่จะมีคุณสมบัติเป็น:

ความพยายามพิเศษที่เราต้องทำในการพัฒนาในอนาคตเนื่องจากทางเลือกที่รวดเร็วและสกปรก

ในแอปพลิเคชันทางธุรกิจเกือบทุกข้อบกพร่องมาจากตัวเลือกการออกแบบที่รวดเร็วและสกปรกหรือการปฏิบัติที่ไม่ดี (จะเป็นการขาดการทดสอบการใช้เทคโนโลยีที่นักพัฒนาไม่รู้จักเพียงพอขาดการสื่อสารขาดความเข้าใจในโดเมน ฯลฯ ) ซึ่งหมายความว่า"โดยการปรับการออกแบบที่รวดเร็วและสกปรกให้เป็นการออกแบบที่ดีขึ้น"และด้วยการปรับวิธีปฏิบัติที่ดีขึ้นธุรกิจสามารถแก้ไขข้อบกพร่องส่วนใหญ่ได้

อาร์กิวเมนต์ที่สอง:

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

• ต้องจัดการกับข้อบกพร่องเหล่านั้นก่อนที่จะสร้างคุณสมบัติใหม่ (จุดที่ 5 ของการทดสอบ Joel: คุณแก้ไขข้อบกพร่องก่อนที่จะเขียนรหัสใหม่หรือไม่?)

• หรือเก็บบั๊กรักษา / เพิ่มทางหนี้ทางเทคนิค

Jeff Atwood ในบทความของเขาการชำระหนี้ทางเทคนิคของคุณให้คำตอบที่ดีเกี่ยวกับหนี้ทางเทคนิคคือ:

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

พูดอย่างเคร่งครัดข้อบกพร่องไม่ได้เป็นส่วนหนึ่งของหนี้ทางเทคนิคถ้าพวกเขาไม่ชะลอการพัฒนาซอฟต์แวร์เพิ่มเติม (การเปลี่ยนแปลงสิ่งต่าง ๆ การเพิ่มคุณสมบัติใหม่ ฯลฯ ) เป็นข้อบกพร่องของซอฟต์แวร์

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

ข้อผิดพลาดไม่ใช่หนี้ทางเทคนิค หนี้ทางเทคนิคคือการข้ามที่มีคุณภาพไม่ได้ขาดมัน ไม่ควรส่งมอบซอฟต์แวร์ที่มีข้อบกพร่องในซอฟต์แวร์ตั้งแต่แรก คุณจะรู้ว่าซอฟต์แวร์ที่ใช้งานได้ทั้งหมดในสิ่งที่ครอบคลุมเอกสาร

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

สำหรับการสนับสนุนความคิดเห็นนี้ฉันไปที่แหล่งข่าว Ward Cunningham เกี่ยวกับเรื่องนี้วอร์ดทำการสัมภาษณ์ที่ดีสักพักหนึ่งกับ Capers Jones มันคุ้มค่ากับการดู

การโต้วาทีทางเทคนิคกับ Ward Cunningham & Capers Jones

บทความที่ควรค่าแก่การอ่านคือ Martin Fowler

Martin Fowler เกี่ยวกับหนี้ทางเทคนิค

ภายในบทความของ Martin โปรดค้นหาลิงก์ไปยังการอ้างถึงต้นฉบับของหนี้ทางเทคนิคโดย Ward Cunningham จาก OOPSLA92:

ระบบการจัดการพอร์ตการลงทุนของ WyCash

อ้างจากบทความข้างต้น:

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

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

คำตอบสำหรับคำถามของคุณอย่างเคร่งครัดคือไม่

หนี้ทางเทคนิคสามารถ (และอาจจะ) นำไปสู่ข้อบกพร่อง แต่สรุปว่าข้อผิดพลาดใด ๆ ที่เป็นผลมาจากหนี้ทางเทคนิคมีการวางการตีความระหว่างสองข้อเท็จจริง: มีข้อผิดพลาดและมีหนี้ทางเทคนิค (สมมติว่าสามารถสรุปได้ว่าเป็นความจริง)

หากนายการต่อสู้ของคุณระบุว่า 'เป็นทฤษฎี' ที่ข้อบกพร่องเป็นผลมาจากหนี้ทางเทคนิคเขากำลังตัดมุม หากเขาพูดถึงข้อผิดพลาดบางอย่างที่ปรากฏขึ้นอีกครั้งเขาอาจพูดถูก - เราไม่สามารถเห็นคุณภาพของรหัสได้จากที่นี่ ;-)

เขาอาจมีการร้องเรียนอย่างต่อเนื่องเกี่ยวกับคนที่ไม่ฟังเขาเกี่ยวกับหนี้ทางเทคนิคและดังนั้นจึงติดป้ายทุกข้อผิดพลาดเป็นหนี้ทางเทคนิค แต่ตอนนี้ฉันคาดเดา

ในความคิดของฉันมันไม่สำคัญว่าคุณจะพูดว่าข้อบกพร่องเป็นส่วนหนึ่งของหนี้ทางเทคนิค ... หรือไม่

ความจริงธรรมดาคือข้อบกพร่องที่มีอยู่แสดงถึงการทำงานพิเศษที่อาจจำเป็นต้องดำเนินการในอนาคตเพื่อแก้ไขปัญหาหรือเพื่อแก้ไขปัญหา

หนี้ทางเทคนิค (ตามปกติแล้วจะใช้ป้ายกำกับ) นอกจากนี้ยังหมายถึงงานพิเศษที่อาจต้องดำเนินการในอนาคต ... ไม่ทางใดก็ทางหนึ่ง

ดังนั้นไม่ว่าคุณจะบอกว่าข้อบกพร่องที่รู้จัก (หรือไม่รู้จัก) เป็นหนี้เชิงเทคนิค ... หรือไม่ ... เป็นเพียงแค่คำจำกัดความ และเนื่องจากไม่มีคำนิยามที่มีสิทธิ์¹ของ "หนี้ทางเทคนิค" การสนทนาทั้งหมดจึงไม่มีประโยชน์

ดังที่ลูอิสคาร์โรลเขียนว่า:

'เมื่อฉันใช้คำหนึ่ง' Humpty Dumpty กล่าวด้วยน้ำเสียงที่ดูถูกเหยียดหยาม 'มันหมายถึงสิ่งที่ฉันเลือกให้หมายถึง - ไม่มากไปหรือน้อยไป' .

ที่จริงแล้วภาษาธรรมชาติทำงานอย่างไร คำหมายถึงสิ่งที่ผู้คนคิดว่าพวกเขาหมายถึง คำจำกัดความของพจนานุกรมและอื่น ๆ เป็นเพียงเอกสารวิธีการใช้คำและไม่จำเป็นต้องเป็นเอกสารที่ถูกต้อง หาก Scrum Master ของคุณต้องการอ้างถึงข้อบกพร่องที่รู้จักกันว่าเป็นหนี้ทางเทคนิคใครจะพูดว่าเขาเป็น "ผิด"?

^{1 - การอ้างอิงผู้คนเช่น Ward Cum Birmingham และ Caper Jones ไม่ได้ช่วยอะไรเช่นกัน อย่างดีที่สุดมันบอกเราว่าพวกเขาหมายถึง (หรือหมายถึง) เมื่อพวกเขาใช้ (ใช้) วลี พวกเขาไม่ได้ "เจ้าของ" วลี แม้ว่าพวกเขาจะมีอำนาจอย่างไม่ต้องสงสัยในประเด็นเหล่านี้ แต่ก็เป็นเพียงความคิดเห็นของพวกเขา}