การจัดหมวดหมู่หนี้ทางเทคนิค (2018)

การจัดหมวดหมู่หนี้ทางเทคนิค

บทนำ

• Bill "LtRandolph" Clark เป็นผู้จัดการฝ่ายวิศวกรรมของทีม Champions ของ LoL และให้ความสนใจอย่างลึกซึ้งกับหนี้ทางเทคนิค
• หนี้ทางเทคนิคถูกนิยามว่าเป็นโค้ดหรือข้อมูลที่ก่อให้เกิดต้นทุนกับนักพัฒนาในอนาคต
• บทความนี้แนะนำประเภทต่าง ๆ ของหนี้ทางเทคนิคที่ Riot เคยพบ และโมเดลที่ใช้ภายในองค์กร

เมทริกซ์

เพื่อประเมินหนี้ทางเทคนิค มีการใช้แกนหลัก 3 ด้าน: ผลกระทบ, ต้นทุนในการแก้ไข, การแพร่กระจาย

ผลกระทบ

• ผลกระทบที่หนี้ทางเทคนิคมีต่อผู้เล่นและนักพัฒนา
• เช่น บั๊ก, ฟีเจอร์ที่ขาดหายไป, พฤติกรรมที่ไม่คาดคิด เป็นต้น

ต้นทุนในการแก้ไข

• เวลาและความเสี่ยงที่จำเป็นในการแก้ไขหนี้ทางเทคนิค
• ความผิดพลาดง่าย ๆ อาจแก้ได้ในไม่กี่นาที แต่ปัญหาที่ฝังรากลึกอาจใช้เวลาหลายสัปดาห์หรือหลายเดือน

การแพร่กระจาย

• หนี้ทางเทคนิคสามารถแพร่ขยายได้มากเพียงใด
• ส่งผลต่อการโต้ตอบกับระบบอื่น การคัดลอกข้อมูล และการพัฒนาฟีเจอร์ใหม่

ประเภทของหนี้

หนี้เฉพาะจุด

• ปัญหาเกิดขึ้นเฉพาะภายในระบบ และไม่ส่งผลต่อภายนอก
• ตัวอย่าง: Cataclysm ของ Jarvan

เมทริกซ์ของ Cataclysm

• ผลกระทบ: 1 / 5
• ต้นทุนในการแก้ไข: 2 / 5
• การแพร่กระจาย: 1 / 5

หนี้แบบ MacGyver

• กรณีที่สองระบบซึ่งขัดแย้งกันถูกเชื่อมเข้าด้วยกันแบบชั่วคราว
• ตัวอย่าง: std::string ของ C++ และคลาส AString ของ Riot

เมทริกซ์ของ std::string vs AString

• ผลกระทบ: 2 / 5
• ต้นทุนในการแก้ไข: 3 / 5
• การแพร่กระจาย: -2 / 5

หนี้เชิงรากฐาน

• กรณีที่สมมติฐานซึ่งฝังลึกอยู่ในระบบส่งผลกระทบต่อทั้งระบบ
• ตัวอย่าง: การใช้ภาษา Lua สำหรับสคริปต์ใน LoL

เมทริกซ์ของ BlockBuilder Lua

• ผลกระทบ: 4 / 5
• ต้นทุนในการแก้ไข: 4 / 5
• การแพร่กระจาย: 4 / 5

หนี้ข้อมูล

• กรณีที่มีคอนเทนต์จำนวนมากสะสมทับอยู่บนหนี้ทางเทคนิคประเภทอื่น ทำให้การแก้ไขยากและมีความเสี่ยง
• ตัวอย่าง: บั๊กชื่อพารามิเตอร์ของภาษาเขียนสคริปต์ BlockBuilder

เมทริกซ์ของบั๊กชื่อพารามิเตอร์

• ผลกระทบ: 2 / 5
• ต้นทุนในการแก้ไข: 2 / 5
• การแพร่กระจาย: 4 / 5

สรุป

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

สรุปโดย GN⁺

• บทความนี้อธิบายประเภทของหนี้ทางเทคนิคและวิธีประเมิน เพื่อช่วยให้นักพัฒนาตัดสินใจได้ดีขึ้น
• เน้นย้ำเรื่องการแพร่กระจายของหนี้ทางเทคนิค และชี้ให้เห็นว่าการแก้ปัญหาตั้งแต่เนิ่น ๆ เป็นสิ่งสำคัญ
• โปรเจ็กต์อื่นที่มีลักษณะใกล้เคียงกัน ได้แก่ Dota 2 และ Overwatch

[GN⁺]

ความคิดเห็นจาก Hacker News

• อินเทอร์เฟซเป็นหนึ่งในองค์ประกอบที่สำคัญที่สุดของการออกแบบ และควรพิจารณาอย่างรอบคอบ

  • หากมีเวลา อินเทอร์เฟซที่สวยงามมักปรับปรุงได้ง่าย แต่ในทางกลับกันเกิดขึ้นไม่บ่อย

• หนี้ของผู้ก่อตั้งคือหนี้ที่ผู้ก่อตั้งสร้างขึ้นเพื่อส่งมอบเทคโนโลยีที่ดีได้อย่างรวดเร็ว

  • เอกสารก่อตั้งของหลายประเทศก็อยู่ในหมวดหมู่นี้เช่นกัน

• น่าแปลกใจที่บทความนี้เขียนโดย Engineering Manager

  • มีแนวโน้มว่าจะไม่มีผู้จัดการที่เลื่อนตำแหน่งมาจากภายใน และมักจ้างจากภายนอก

• มีการพูดคุยถึงการจัดหมวดหมู่ของหนี้ทางเทคนิค

  • ลิงก์ที่เกี่ยวข้อง: A Taxonomy of Technical Debt
  • ลิงก์ที่เกี่ยวข้อง: A Taxonomy of Tech Debt (2018)

• เป็นบทความที่ยอดเยี่ยมในมุมมองทางเทคนิค

  • "ศัพท์บัญญัติ" อาจเป็นคำที่เหมาะสมกว่า
  • ตัวอย่างแต่ละข้อชวนให้ขบคิดมาก

• ใช้คำว่า "Contagion" ในการอธิบายหนี้ทางเทคนิค

  • เป็นคำอธิบายที่ยอดเยี่ยม

• นิยามหนี้ทางเทคนิคคือโค้ดหรือข้อมูลที่ทำให้นักพัฒนาในอนาคตต้องเป็นผู้จ่ายต้นทุน

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

• จะไม่เรียก "หนี้เฉพาะจุด" ว่าเป็นหนี้ทางเทคนิคในบริบททั่วไป

  • จะมีความสับสนอยู่ที่ไหนสักแห่งเสมอ และโดยทั่วไปก็มักห่อหุ้มมันไว้

• มีประสบการณ์ทำงานในหลายสตาร์ตอัป

  • ผู้ก่อตั้งมักสับสนระหว่างไอเดีย สิ่งที่ถูกนำไปทำจริง และส่วนที่ใช้งานได้จริง

• บางครั้งก็จงใจแบกรับหนี้ทางเทคนิคเพื่อผลประโยชน์ระยะสั้น

  • ผลประโยชน์นี้ก็ควรถูกพิจารณาเป็นอีกแกนหนึ่งด้วย