หนี้ทางเทคนิคคืออะไรและคุณสามารถหลีกเลี่ยงได้หรือไม่?

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

หนี้ทางเทคนิคคืออะไร?

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

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

ไม่มีสิ่งใดที่ ไม่ดี อย่างแน่นอน ไม่ใช่ด้วยตัวเอง อาจจะไม่เลย แต่เมื่อรวมเข้าด้วยกันแล้ว หนี้ทางเทคนิคที่เกิดขึ้นจะต้องชำระคืนในอนาคต

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

คุณได้รับมัน.

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

คุณสามารถหลีกเลี่ยงหนี้เทคโนโลยีได้หรือไม่?

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

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

การพิจารณาหนี้ทางเทคนิคโดยเจตนา

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

นี่คือเวลาที่คุณต้องพิจารณาการกู้ยืมเงินและกลายเป็นหนี้ทางเทคนิค

คุณมีสามตัวเลือกที่นี่:

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

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

การชำระคืนเงินกู้โดยเจตนา

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

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

พิจารณาหนี้ทางเทคนิครหัสเดิม

หนี้ทางเทคนิคทั่วไปอีกประเภทหนึ่งคือ WordPress กำลังสะสมอยู่เป็นจำนวนมากในขณะนี้ WordPress สามารถทำงานบน PHP 5.x อย่างไรก็ตาม การอัปเดตใหม่ล่าสุดจะบอกผู้ใช้ว่าอย่างน้อยต้องมี PHP 5.6 ภายในสิ้นปี 2019 WP Core จะต้องใช้ PHP 7.x อย่างไรก็ตาม ด้วยการผลักดันข้อกำหนดขึ้น โค้ดเก่าจำนวนมากต้องได้รับการอัปเดต เพราะยังคงมีโค้ด PHP 5.x ในปลั๊กอิน ธีม และ Core เอง

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

การชำระหนี้ของรหัสเดิม

อันนี้ค่อนข้างยากเพราะไม่มีวิธีที่ดีที่จะทำ คุณสามารถใช้ตัวเลือกนิวเคลียร์และเขียนใหม่ทั้งหมดตั้งแต่ต้นในภาษา/เฟรมเวิร์ก/เวอร์ชันใหม่ (ดูสิ่งที่เราทำระหว่าง Divi 2 และ Divi 3.0 จาก Backbone.js เป็น React) นี้ยังคงไม่สามารถแก้ไขปัญหาของหนี้ได้ทั้งหมด อย่างไรก็ตาม เนื่องจากคุณยังมีคนใช้ห้องสมุดเก่า เมื่อถึงจุดหนึ่ง คุณจะต้องยกเลิกการสนับสนุนสำหรับ codebase รุ่นเก่า ซึ่งก็เหมือนกับการชำระคืนเงินกู้ จนต้องเอาตัวต่อไป.

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

พิจารณานักพัฒนาหลายรายเมื่อเวลาผ่านไป

นี่เป็นหนี้เทคโนโลยีชนิดหนึ่งที่ทีมใหญ่มักจะสะสมเมื่อเวลาผ่านไปแย่กว่าทีมพัฒนาขนาดเล็ก แม้ว่าคนตัวเล็กจะต้องกังวลเรื่องนี้เช่นกัน คุณเห็นไหมว่าวิศวกรซอฟต์แวร์ทุกคนเขียนโค้ดต่างกัน คุณแทบจะไม่มีนักพัฒนาสองคนที่แก้ปัญหาเดียวกันด้วยโค้ดเดียวกัน พวกเขาอาจทำหน้าที่เดียวกัน และผลลัพธ์สุดท้ายก็อาจจะเหมือนกัน แต่โค้ดจะถูกเขียนด้วยเสียงของผู้แต่ง (เหมือนกับที่คุณบอกได้ว่าใครเป็นคนเขียนโพสต์ที่นี่ เช่น Jason, Nathan, Donjete และ ฉันมีสไตล์ที่แตกต่างกันทั้งหมด) รหัสไม่แตกต่างกัน

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

ชำระคืนหนี้ทางเทคนิคของผู้พัฒนาเก่า

วิธีที่ง่ายที่สุดคือจ้างผู้พัฒนาที่ดีที่สุดและอย่าปล่อยให้พวกเขาออกจากบริษัทของคุณ เคย.

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

นอกจากนี้ ตรวจสอบให้แน่ใจว่านักพัฒนาทุกคนในทีมของคุณยึดมั่นในแนวทางสไตล์หรือชุดมาตรฐาน WordPress Core มีชุดมาตรฐานการเข้ารหัสที่จะเก็บปลั๊กอิน ธีม และการสนับสนุน Core ไว้ในบรรทัด เพื่อไม่ให้ใครก็ตามที่มาภายหลังจะไม่มีปัญหากับมัน Airbnb มีคู่มือสไตล์สำหรับ React ที่นำมาใช้เป็นมาตรฐานที่ไม่เป็นทางการของอุตสาหกรรม แม้แต่คู่มือและมาตรฐานของสไตล์ภายในก็ป้องกันไม่ให้นักพัฒนาของคุณไปไกลเกินไปเพราะการกระทำประเภทนั้นจะไม่ถูกรวมเข้าด้วยกันเว้นแต่ว่ามันจะจบลง

ห่อ

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

คุณจัดการกับหนี้ทางเทคนิคภายในโครงการและทีมพัฒนาของคุณอย่างไร?

ภาพเด่นของบทความโดย Andrey Suslov/ shutterstock.com