รหัสการทอดทิ้งเครื่องตายอย่างถูกต้องหรือไม่?


10

มันเป็นความประทับใจของฉันที่สร้างรหัสโอเพนซอร์สมากขึ้นเรื่อย ๆ เพิ่มไปยังที่เก็บข้อมูลฟรีหรือที่ว่างบางส่วนแล้วละทิ้ง

มีมาตรฐานที่ยอมรับกันโดยทั่วไปสำหรับการทิ้งรหัสที่ถูกทอดทิ้งหรือไม่? สิ่งนี้ควรถูกบังคับใช้โดยที่เก็บหรือนี่เป็นสิ่งที่ขึ้นอยู่กับผู้เขียนรหัสดั้งเดิมที่ต้องทำ


2
ทำไมมันต้องถูกกำจัด? ถ้าเป็นโอเพ่นซอร์สใครบางคนอาจต้องการบางสิ่งบางอย่างและมันไม่ได้มีค่าใช้จ่ายมากนักในการเก็บไว้ในที่เก็บ
David Thornley

คุณหมายถึงอะไรโดย "มาตรฐานสำหรับการทิ้งรหัสที่ถูกทอดทิ้ง"? "del . "
โกง

@Rook: หรือ "rm -rf *" สำหรับผู้ใช้ Unix / Linux
David Thornley

@David Thornley - ใช่แล้ว ... คุณเข้าใจแล้ว :)
Rook

คำตอบ:


7

ปัญหาใหญ่ที่นี่กำลังตัดสินใจเมื่อบางสิ่งถูกทิ้งร้าง

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

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

ดังนั้นฉันจะบอกว่าไม่เพียงเพราะไม่มีวิธีที่เชื่อถือได้เพื่อตรวจสอบว่าซอฟต์แวร์ยังคงใช้งานอยู่ การขาดหลักฐานไม่ใช่หลักฐานของการขาด :)


+1 สำหรับประโยคสุดท้าย คุณไม่สามารถบอกได้ว่าใครต้องอาศัยซอฟต์แวร์ตัวนั้นซึ่งเป็นเหตุผลว่าทำไมไมโครซอฟท์ให้ความสำคัญกับความเข้ากันได้แบบย้อนหลัง
Michael K

1

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

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

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

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


1

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

ในทำนองเดียวกันเรามักจะเห็นนักแต่งเพลงศตวรรษที่ 18 ทุกคนในฐานะโมสาร์ทและนักเขียนบทละครในศตวรรษที่ 16 ทุกคนเป็นเช็คสเปียร์ กฎหมายของปลาสเตอร์เจียนบอกว่า 90% ของทุกสิ่งทั้งตอนนี้และตอนนี้ / เป็นอึ แต่คุณคุ้นเคยกับอึที่มีอยู่ในขณะนี้เพราะมันไม่มีเวลามากพอที่จะพบกับการสลายตัวของผู้ใช้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.