หนี้ทางเทคนิค: ไลบรารี Rust ของฉัน ตอนนี้แปลงเป็น CDO แล้ว

 (lucumr.pocoo.org)
2 คะแนน โดย GN⁺ 2024-03-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

หนี้ทางเทคนิค: ตอนนี้ไลบรารี Rust ของฉันกลายเป็น CDO ไปแล้ว

  • มีมุกล้อเกี่ยวกับหนี้ทางเทคนิคว่า ถ้ามีหนี้ทางเทคนิค ก็ต้องมีอนุพันธ์ทางการเงินไว้จัดการหนี้นั้นด้วย
  • ระบบนิเวศของ Rust ดูเหมือนจะสร้างวิธีแก้ปัญหาที่คล้ายกับการนำหนี้ทางเทคนิคไปแปลงเป็นหลักทรัพย์ค้ำประกัน
  • ตัวอย่างเช่น ไลบรารี stuff ตัวหนึ่งพึ่งพาไลบรารีอีกตัวชื่อ learned-rust-this-way แต่ผู้เขียน learned-rust-this-way หมดความสนใจไปแล้ว และปัญหาก็เริ่มสะสมขึ้น

สภาพที่แท้จริงของหนี้ทางเทคนิค

  • learned-rust-this-way ถือเป็นหนี้ทางเทคนิค ซึ่งไม่ได้ก่อปัญหาโดยตรงในทันที แต่ก็ยังคงเป็นหนี้อยู่ดี
  • ในจุดหนึ่ง จะมีคนตระหนักว่า learned-rust-this-way เป็นหนี้ และเมื่อไม่สามารถติดต่อผู้เขียนเดิมได้ มันก็ถูกเพิ่มเข้าไปในฐานข้อมูล RUSTSEC
  • RUSTSEC ทำหน้าที่เหมือนสถาบันจัดอันดับ และประเมินหนี้ก้อนนี้ว่าเป็นขยะ ส่งผลให้ CI (การผสานรวมอย่างต่อเนื่อง) ของผู้คนจำนวนมากเริ่มล้มเหลว

วิธีจัดการหนี้

  • ในฐานะผู้ดูแล stuff ความเครียดจะเพิ่มขึ้นเมื่อผู้ใช้เริ่มตั้งปัญหาเกี่ยวกับการใช้ learned-rust-this-way และเรียกร้องให้มีมาตรการจัดการหนี้นี้
  • การย้ายไปใช้ทางเลือกอื่นเป็นหนึ่งในตัวเลือก แต่ในกรณีนี้ ทางเลือกทั้งหมดกลับไม่น่าดึงดูดนัก
  • หาก fork learned-rust-this-way ก็จะต้องเจอกับข้อเรียกร้องแบบเดิมอีก ซึ่งเป็นเพียงการแก้ปัญหาเฉพาะหน้า ไม่ได้แก้ปัญหาจริง

วิธีแก้ที่ได้ผลจริง

  • ถ้านำโค้ดส่วนนั้นมารวมเข้าในไลบรารีของตัวเอง หนี้ทางเทคนิคขยะก้อนนั้นก็จะถูกประเมินเป็นระดับ ‘AAA’ ขึ้นมาทันที
  • ไม่ต้องไปแตะโค้ดนั้นอีก ซ่อนความจริงที่ว่ามันถูกควบรวมเข้าไป แล้วดูแลไลบรารีต่อไปเหมือนเดิม โลกก็ยังหมุนต่อไปได้
  • ด้วยการ vendor yaml-rust เข้ามารวมไว้ใน insta ทำให้มันกลายเป็นร่างผสมของโค้ด insta กับ yaml-rust และเป็นการอัปเกรดหนี้ทางเทคนิคให้กลายเป็นระดับ AAA

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-27
ความคิดเห็นจาก Hacker News
  • ผู้เขียนของ YAML parser ที่ได้รับความนิยมมากที่สุดได้ละทิ้งโปรเจกต์อย่างกะทันหัน และทำเครื่องหมายว่า deprecated และ unmaintained โดยไม่มีการเตือนล่วงหน้าหรือแต่งตั้งผู้ดูแลคนอื่น แพ็กเกจยังคงใช้งานได้ แต่ถูกใช้โดย crate อื่นมากกว่า 4,000 ตัว ดังนั้นเครื่องมือ audit และอัปเดตอัตโนมัติจะเตือนเกี่ยวกับการใช้ crate ที่ไม่ได้รับการบำรุงรักษา
  • สำหรับคนที่สับสนกับตัวย่อ CDO มีการคาดเดาว่ามันหมายถึง 'collateralized debt obligation' เพราะมีการใช้คำว่า 'collateralized' หลายครั้ง
  • หากเส้นทางที่เปราะบางของโค้ดไม่สามารถถูกรันหรือเข้าถึงได้จากไลบรารีภายนอก ก็ถือว่าเป็นเส้นทางโค้ดที่ปลอดภัย การทำ vendoring ไลบรารีเข้ามาจะทำให้มีเครื่องมือสำหรับโจมตีโค้ด และหากมี test coverage สำหรับไลบรารีของตัวเองเพียงพอ ก็สามารถรันเครื่องมือ code coverage กับไลบรารีที่ดึงเข้ามาได้ การแก้ไขไลบรารีที่ดึงเข้ามาอาจท้าทาย แต่การลบส่วนที่ไม่จำเป็นอาจค่อนข้างง่ายกว่า แน่นอนว่าขึ้นอยู่กับโครงสร้างของไลบรารีที่ดึงเข้ามาด้วย
  • อดีตนักวิเคราะห์เชิงปริมาณและปัจจุบันเป็นนักเศรษฐศาสตร์ชื่นชมที่ผู้เขียนใช้คำว่า 'Collateralized Debt Obligation' ได้อย่างถูกต้อง เขาอยากเขียนบทความเกี่ยวกับ 'หนี้ทางเทคนิค' แต่คิดว่าอุปมาเรื่อง 'หนี้' ไม่เหมาะกับแนวคิดนี้นัก คำว่า 'โค้ดความหนืดสูง' อาจดีกว่า เพราะโค้ดไม่สามารถเปลี่ยนให้เข้ากับฟีเจอร์ใหม่ได้ง่าย ราวกับว่ามันมีความเหนี่ยวนำสูง
  • เกี่ยวกับการที่ 'junk tech debt' จู่ ๆ ได้รับการจัดอันดับระดับ 'AAA' ผู้เขียนดูเหมือนจะหมายความว่าโค้ดเดียวกันไม่ควรมีอันดับหนี้ที่ดีกว่าทั้งก่อนและหลังการทำ vendoring แต่การมองแบบนี้พิจารณาแค่คุณค่าของโค้ดเอง และพลาดส่วนที่สำคัญที่สุดของคุณค่าโดยรวมไป ผู้ดูแลที่ดึงโค้ดเข้ามาตอนนี้เป็นเจ้าของโค้ดนั้นแล้ว และผู้ดูแลที่ยังแอ็กทีฟซึ่งดึงโค้ดมาจากโปรเจกต์ที่ตายไปแล้ว จะเพิ่มคุณค่าให้โค้ด เพราะมีมนุษย์ที่สามารถตอบสนองต่อ issue รีวิว pull request และแก้บั๊กได้
  • เคยเห็นรูปแบบเดียวกันนี้ใน ecosystem ของ JS npm เช่นกัน Npm audit มักเตือนเกินจริงในประเด็นความปลอดภัย และตราบใดที่ไลเซนส์อนุญาต หนึ่งในวิธีที่เชื่อถือได้ที่สุดในการหลุดพ้นจากปัญหาสุดเพี้ยนที่ผู้ใช้โยนมาให้ ก็คือการทำเช่นนี้
  • นับว่าโชคดีที่มีการ fork yaml-rust และเขียนใหม่เป็น Rust ล้วนจนกลายเป็น yaml-rust2 ฟอร์กนี้ผ่าน YAML test suite ได้ครบถ้วน และยังมีประสิทธิภาพดีกว่าในการ benchmark ด้วย การย้ายระบบก็ดูเรียบง่าย ท้ายที่สุดปัญหายังคงอยู่ เรากำลังพึ่งพาคนอื่นที่ลงแรงให้ฟรีในตอนนี้ แต่ไม่มีหลักประกันว่าพวกเขาจะทำเช่นนั้นไปตลอด
  • หาก source-based package manager ไม่มีสิทธิทางกฎหมายในการบังคับให้ registry เข้ารับช่วงการบำรุงรักษาแพ็กเกจที่ถูกเผยแพร่ ก็จะต้องเผชิญปัญหาน่ากลัว: การถูกปล่อยทิ้ง การเปลี่ยนแปลงโดยเจตนาร้าย การลบโดยเจตนาร้าย การปลอมตัว ฯลฯ... สำหรับแพ็กเกจที่ถูกมองว่าสำคัญพอต่อชุมชน จำเป็นต้องมีวิธีดึงรายการใน registry ออกจากมือเจ้าของเดิมแล้วเปลี่ยนให้เป็นฟอร์ก
  • ถ้าโค้ดยังทำงานได้และเป็นแบบนั้นมาหลายปีแล้ว จะไปสนใจอะไรกับการที่มันไม่ได้รับการบำรุงรักษา? ถ้าไม่จำเป็นต้องแก้และรู้ข้อจำกัดกับความสามารถของมัน ก็ไม่ใช่ปัญหา โค้ดไม่ได้แย่ลงได้เอง ในอดีตหลายสิบปีก็ไม่มีปัญหาอะไรกับการยืมหรือรวมโค้ดเก่า ๆ เข้ามาหลายครั้ง
  • การทำ vendoring dependencies คือคำตอบ ทำแบบนี้มากับ dependency เกือบทุกตัวที่ถือว่า 'เสร็จสมบูรณ์' แล้วและมีการพัฒนาหรือบำรุงรักษาช้าลง ตลอด 20 ปีที่ผ่านมา