กรรมไม่ดีในการเขียนโปรแกรม หนี้ทางเทคนิคคืออะไร และจะแก้ไขได้อย่างไร

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

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

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

เหตุผลในการปรากฏตัว

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

การจัดหมวดหมู่

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

1. หนี้ทางเทคนิคโดยเจตนา

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

   “บางครั้งเราจงใจรับภาระทางเทคนิคเพื่อลดเวลาในการพัฒนา หากคุณตัดสินใจที่จะไปในเส้นทางนี้ ให้พิจารณาไม่เพียงแต่เวลาที่คุณจะประหยัดในระหว่างการพัฒนาเท่านั้น แต่ยังรวมถึงเวลาที่คุณจะต้องใช้ในภายหลังเพื่อ "ชำระ" หนี้ดังกล่าวด้วย นอกจากนี้ ตรวจสอบให้แน่ใจว่าผู้มีส่วนได้ส่วนเสีย [ผู้บริหารระดับสูงของบริษัท] ตระหนักว่าการตัดสินใจดังกล่าวจะทำให้การเปิดตัวฟังก์ชั่นอื่นๆ ช้าลงอย่างหลีกเลี่ยงไม่ได้ในอนาคต” Dag Ljodden กล่าว

   แนวทางแก้ไขหนี้ทางเทคนิคประเภทนี้

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

2. อุบัติเหตุหรือเกิดจากสถาปัตยกรรมโครงการที่ล้าสมัย หนี้ทางเทคนิค

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

   แนวทางแก้ไขหนี้ทางเทคนิคประเภทนี้

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

3. หนี้ทางเทคนิคที่เกิดขึ้นเมื่อเวลาผ่านไป

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

   แนวทางแก้ไขหนี้ทางเทคนิคประเภทนี้

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

โซลูชั่นการจัดการหนี้ทางเทคนิค

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

1. จัดสรรเปอร์เซ็นต์เวลาทำงานที่แน่นอนให้กับการทำงานเกี่ยวกับหนี้ทางเทคนิค

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

   ซึ่งสามารถทำได้หลายวิธี

2. ทำงานเกี่ยวกับหนี้ทางเทคนิค 1 วันต่อสัปดาห์

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

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