นี้บทความเกี่ยวกับหนี้ทางเทคนิคมีจุดดีบางอย่างรวมถึง:

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

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

วิธีการนี้มีข้อดีอย่างน้อย:

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

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

คุณเห็นประโยชน์เชิงบวกอะไรบ้างจากการล้างฐานรหัสและกำจัดหนี้ด้านเทคนิคด้วยตัวคุณเอง? คุณใช้วิธีใดในการทำให้งานเสร็จ?

ฉันสามารถยกตัวอย่างหนึ่งอย่างจากประสบการณ์ของฉัน

ประมาณ 10 หรือ 12 ปีที่ผ่านมาฉันได้รับแอปพลิเคชันจากทีมนักพัฒนาซอฟต์แวร์ซึ่งจบลงด้วยการลาออกจาก บริษัท (นานเกินกว่าที่จะมาที่นี่ ... ) ระบบนี้เป็นระบบการสร้างรายงานมิดเดิลแวร์ขนาดใหญ่ที่สร้างขึ้นในบ้าน มันวิ่งทุกคืนต่อสัปดาห์และสร้างรายงาน Excel ประมาณสองโหลสำหรับผู้บริหารระดับสูงของ บริษัท Fortune 500 เมื่อฉันสืบทอดมันใช้เวลาประมาณ 5-6 ชั่วโมงในการวิ่งและในช่วงสัปดาห์ใดก็ตามจะล้มเหลวอย่างน้อย 2 คืน

ฉันไม่ได้เป็นผู้ออกค่ายที่มีความสุขที่ได้รับความยุ่งเหยิงนี้

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

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

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

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

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

เสมอ

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

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

เกี่ยวกับสองจุดสุดท้าย: ฉันเข้าใจว่ามาจากไหนตามที่อธิบายไว้ในโพสต์ต้นฉบับของเขา:

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

"แล้วอะไรล่ะ" เท่ากับ: เจ้าของผลิตภัณฑ์และคนในแวดวงธุรกิจอื่น ๆ ไม่มีความสุข และเมื่อ Momma ไม่มีความสุขทุกคนก็ไม่มีความสุข

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

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

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

จากblog.acrowire.com