หนี้เทคโนโลยีคืออะไร?

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

ตามหลักการแล้ว โค้ดชิ้นใดก็ตาม — ระหว่างการใช้งานครั้งแรกควรจัดการกับกรณีที่ทราบทั้งหมด อย่างไรก็ตาม อาจมีตัวบล็อก:

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

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

จำเป็นต้องก้าวไปข้างหน้า

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

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

คุณภาพ

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

1. เมื่อหนี้เทคโนโลยีได้รับการแก้ไข ทำให้โค้ดน้อยลงสำหรับโค้ดของการใช้งานที่เลือกในปัจจุบัน และ
2. นำไปสู่ความล้มเหลวอย่างสง่างามของการทำงานบางส่วนที่ไม่ธรรมดา ในทางกลับกัน เมื่อแก้ไขแล้ว — มันคือการปรับปรุงเพิ่มเติมของคุณสมบัติ

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

ค่าใช้จ่าย

คำถามที่ถามเมื่อประเมินค่าใช้จ่ายในการรับหนี้เทคโนโลยีหรือกรณีที่ไม่ได้รับ:

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

เราใช้หนี้เทคโนโลยีเพื่อประโยชน์บางอย่าง:

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

การปฏิบัติตามหลักการพื้นฐานขั้นพื้นฐานของการออกแบบที่มีประสิทธิภาพช่วยลดการทำงานซ้ำซึ่งเกี่ยวข้องกับหนี้เทคโนโลยีที่เกี่ยวข้อง

โมดูลาร์

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

พยายามคิดให้ไกลกว่าปัจจุบัน เช่น

1. หากขณะนี้เรามีการใช้งานฟังก์ชันหนึ่ง แต่ในภายหลัง เราอาจกำหนดให้การใช้งานเป็นคลาสย่อยของอินเทอร์เฟซ สิ่งนี้ทำให้ง่ายต่อการเพิ่มการใช้งานในภายหลัง
2. หากปัจจุบันเอนทิตีมีค่าหนึ่งที่เป็นไปได้สำหรับฟิลด์นี้ แต่อาจมีมากกว่านั้นในภายหลัง ให้ตั้งค่านั้นเป็น enum

สคีมาสะอาด

สคีมาฐานข้อมูลและโมเดล ORM ที่ดีและจำลองกรณีการใช้งานในชีวิตจริงอย่างใกล้ชิดมักจะแข็งแกร่งต่อการเปลี่ยนแปลงเพิ่มเติม

แนวทางปฏิบัติในการเข้ารหัสที่ดี

1. เก็บค่าที่อาจปรับแต่งได้ DRY & ไม่ลงลึกในโค้ด สามารถเป็นได้ทั้งตัวแปรการกำหนดค่าอินพุตรันไทม์หรือค่าคงที่ของโค้ด สิ่งนี้จะต้องเป็นการตัดสินใจอย่างมีสติ
2. ฟังก์ชันบางอย่างต้องการความสามารถในการทำซ้ำอย่างรวดเร็วหรือปรับแต่งตามลูกค้าแต่ละราย ใช้เครื่องมือต่ำ/ไม่มีโค้ด ง่ายต่อการทำซ้ำ — แม้จะไม่ใช่วิศวกรก็ตาม และมีรหัสน้อยกว่า & ด้วยเหตุนี้จึงปั่นป่วนน้อยลง
3. แนวปฏิบัติทั่วไปในการเขียนโค้ดและการออกแบบที่กล่าวถึงข้างต้นมีผลใช้บังคับ — เช่น เก็บโค้ดแบบ DRY (เปลี่ยนโค้ดได้ง่ายในที่เดียว) เก็บโค้ดให้เรียบง่าย (ทำให้เข้าใจการเปลี่ยนแปลงได้ง่ายกว่า) เป็นต้น
4. การเปลี่ยนแปลงบางอย่างจะเป็นแบบเสริม — สร้างตามสภาพที่เป็นอยู่ — เช่น การเพิ่มชุดเรพพลิกาไปยังเซิร์ฟเวอร์ฐานข้อมูล Mongo โหนดเดียวที่มีอยู่ หรือการแบ่งส่วนย่อยไปยังเซิร์ฟเวอร์ฐานข้อมูล Mongo หากการดำเนินการเหล่านี้มีราคาแพง ความต้องการการปรับปรุงดังกล่าวสามารถเลื่อนลงไปตามไทม์ไลน์ได้จนกว่าจะจำเป็นโดยไม่ต้องใช้ความพยายามเพิ่มเติม

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

1. ให้รหัสยืนยันในสาขาของคุณพร้อมข้อคิดเห็นที่ต้องทำมากมายเกี่ยวกับฟังก์ชันที่รอดำเนินการหรือรายการชี้แจง
2. ตามหลักการแล้ว ให้แก้ไขสิ่งที่ต้องทำทั้งหมดก่อนที่จะเพิ่มคำขอดึง
3. ปัญหาที่ไม่ได้รับการแก้ไขใดๆ จะกลายเป็นหนี้เทคโนโลยี — ตรวจสอบให้แน่ใจว่าผู้ตรวจสอบโค้ดและผู้จัดการฝ่ายวิศวกรรมที่เกี่ยวข้อง/ลีดถูกแท็ก / ข้อมูล หนี้เทคโนโลยีที่จิราสร้างขึ้น & จิระ ID ที่กล่าวถึงในความคิดเห็น หวังว่าการตรวจสอบ PR ควรเป็นการยืนยันอีกครั้งว่าหนี้เทคโนโลยีนั้นตกลงที่จะรับ
4. ตรวจสอบให้แน่ใจว่าโค้ดจัดการแม้กระทั่งกรณีที่ไม่ได้จัดการอย่างสง่างาม เช่น ส่วนหน้าได้รับการตอบกลับ API ที่เหมาะสมเพื่อแสดงข้อผิดพลาดของอินพุต API ที่ยังไม่ได้จัดการ มากกว่าที่จะทำให้แบ็กเอนด์ขัดข้อง
5. คำนึงถึงลำดับเวลาสำหรับหนี้เทคโนโลยีของ Jira โดยอาจเก็บไว้ในการวิ่งครั้งต่อไปเพื่อให้มีการวางแผนการวิ่งเพื่อตรวจสอบเบื้องต้น