การเขียนโค้ดที่จะยังคงทำงานเป็นปีนับจากนี้
การเปลี่ยนแปลงภาษาการเขียนโปรแกรม ห้องสมุดเปลี่ยนไป รหัสบางส่วนจาก 5, 10 หรือแม้กระทั่ง 20 ปีที่ผ่านมาอาจยังคงทำงานและให้ผลลัพธ์ที่คาดหวังในขณะที่บางรหัสจาก 2 ปีอาจล้มเหลวด้วยข้อผิดพลาดทางไวยากรณ์ นี่เป็นส่วนหนึ่งที่หลีกเลี่ยงไม่ได้เนื่องจากภาษามีวิวัฒนาการ นักพัฒนามีความรับผิดชอบในการรักษารหัสของพวกเขา แต่บางครั้งความเสถียรเป็นข้อกำหนดที่สำคัญในรหัสการผลิตและรหัสควรทำงานเป็นเวลา 10 ปีโดยไม่จำเป็นต้องให้ใครซักคนผ่านรหัสทุกปีเพื่อปรับเปลี่ยนให้เหมาะกับการเปลี่ยนแปลงภาษา หรือฉันอาจมีสคริปต์ขนาดเล็กเช่นการวิเคราะห์ข้อมูลทางวิทยาศาสตร์ว่าฉันต้องกลับมายังหลังจากไม่ได้สัมผัสเป็นเวลาหลายปี ตัวอย่างเช่นที่สำนักงานอุตุนิยมวิทยามีรหัส Fortran จำนวนมากที่ใช้งานได้แม้ในส่วนที่ไม่จำเป็นความเร็วและความเสถียรของรหัสเป็นหนึ่งในเหตุผล ผม' เคยได้ยินว่ากลัวความไม่มั่นคงเป็นหนึ่งในวัตถุที่พวกเขามีต่อการย้ายไปยัง Python (นอกเหนือจากความเฉื่อยของภาษาแน่นอนมันเป็นไปได้สำหรับรหัสใหม่ที่ไม่ขึ้นอยู่กับรหัสเก่า) แน่นอนว่ากลยุทธ์หนึ่งสำหรับรหัสที่เสถียรคือการหยุดระบบปฏิบัติการทั้งหมด แต่นั่นเป็นไปไม่ได้เสมอไป
ฉันใช้ Python เป็นตัวอย่าง แต่ปัญหาไม่ได้ จำกัด เฉพาะ Python โดยเฉพาะ
เอกสารเกี่ยวกับปัญหาความเข้ากันได้ของ Python
ในกรณีของ Python มีเอกสารหลายฉบับที่สรุปนโยบายสำหรับการเปลี่ยนแปลงย้อนหลังที่เข้ากันไม่ได้
PEP-5
ตามPEP 5 :
ต้องมีช่วงเวลาการเปลี่ยนแปลงอย่างน้อยหนึ่งปีระหว่างการเปิดตัว Python และการปล่อยของเวอร์ชันที่เข้ากันไม่ได้ย้อนหลัง ผู้ใช้จะมีเวลาอย่างน้อยหนึ่งปีในการทดสอบโปรแกรมของพวกเขาและโยกย้ายพวกเขาจากการใช้โครงสร้างที่เลิกใช้แล้วไปยังตัวเลือกอื่น
โดยส่วนตัวแล้วฉันคิดว่าหนึ่งปีนั้นค่อนข้างสั้น หมายความว่าฉันอาจเขียนโค้ดและ 1 and ปีจากนี้มันจะไม่ทำงานอีกต่อไป
PEP 291
PEP 291มีรายการแนวทางที่ไม่สมบูรณ์ที่ควรหลีกเลี่ยงเพื่อรักษาความเข้ากันได้ย้อนหลัง อย่างไรก็ตามมันเกี่ยวข้องกับ Python 2.x เท่านั้น เนื่องจาก Python 2.7 เป็นรุ่นสุดท้ายในซีรีย์ 2.x และ Python 2.7 เป็นเพียงการแก้ไขข้อบกพร่องเท่านั้น PEP นี้จึงเป็นที่สนใจในอดีตเท่านั้น
PEP 387
นอกจากนี้ยังมีPEP 387เกี่ยวกับการเปลี่ยนแปลงย้อนหลังที่เข้ากันไม่ได้ PEP 387 เป็นฉบับร่างและไม่ใช่นโยบายอย่างเป็นทางการ ในเดือนมิถุนายน 2009 นี้ได้รับการกล่าวถึงในงูใหญ่ความคิดทางรายการ ส่วนหนึ่งของการสนทนาเน้นที่นักพัฒนาสามารถเขียนโค้ดที่มีความทนทานต่อการเปลี่ยนแปลงภาษา โพสต์หนึ่งโพสต์มีคำแนะนำเกี่ยวกับสิ่งที่ไม่ควรทำ :
นอกจากนี้ยังมีกฎหลายข้อที่คุณสามารถอนุมานได้ว่าเป็นเรื่องจริงส่วนใหญ่เวลา: อย่าเรียกสิ่งที่เริ่มต้นด้วย
"_"อย่าลิงอะไรปะไม่ใช้การเปลี่ยนคลาสแบบไดนามิกบนวัตถุจากคลาสอื่นนอกเหนือจากของคุณเอง ไม่ต้องอาศัยความลึกของลำดับชั้นการสืบทอด (ตัวอย่างเช่นไม่ใช่".__bases__[0].__bases__[0]") ตรวจสอบให้แน่ใจว่าการทดสอบของคุณทำงานโดยไม่ต้องใช้ DeprecationWarnings โปรดระลึกถึงความขัดแย้งของเนมสเปซที่เป็นไปได้เมื่อเพิ่มแอตทริบิวต์ไปยังคลาสที่สืบทอดจากไลบรารีอื่น ๆ ฉันไม่คิดว่าทุกสิ่งเหล่านี้จะถูกเขียนลงในที่เดียว
นอกจากนี้ยังมีบางจุดเกี่ยวกับ "ทุ่งเหมือง" (คุณสมบัติใหม่ที่มีแนวโน้มที่จะเปลี่ยนแปลง) และ "พื้นที่แช่แข็ง" (API ที่ขายดีมากรับประกันได้ว่าจะไม่เปลี่ยนแปลง) การอ้างอิง Antoine Pitrou :
ฉันคิดว่าควรกำหนด "พื้นที่แช่แข็ง" ในเชิงบวก (API สาธารณะอย่างชัดเจนและรับประกันพฤติกรรมอย่างชัดเจน) แทนที่จะเป็นเชิงลบ (เขตข้อมูลเหมืองชัดเจน) มิฉะนั้นเราจะลืมใส่สิ่งที่สำคัญบางอย่างในเขตที่วางทุ่นระเบิดและถูกกัดในภายหลังเมื่อเราจำเป็นต้องเปลี่ยนสิ่งเหล่านั้นในทางกลับกันไม่เข้ากัน
ดูเหมือนจะไม่มีข้อสรุปใด ๆ จากกระทู้นี้ แต่ใกล้เคียงกับแกนหลักของสิ่งที่ฉันกำลังมองหา เธรดนั้นมีอายุเกือบสี่ปีดังนั้นอาจมีการเปลี่ยนแปลงหรือปรับปรุงสถานการณ์ รหัสประเภทใดที่จะอยู่รอดและรหัสประเภทใดที่บอบบางกว่า
แนวทางการย้าย
นอกเหนือจากเอกสารที่ระบุไว้ด้านบนแล้ว Python แต่ละเวอร์ชันยังมีแนวทางในการย้ายพอร์ต : เปลี่ยนเป็น Python 3.2 , เปลี่ยนเป็น Python 3.3เป็นต้น
มีประโยชน์เข้ากันได้
PEP 3151แนะนำผมให้แนวคิดของการทำงานร่วมกันที่มีประโยชน์ ในคำพูดของฉันเองสิ่งนี้ทำให้เกิดความคิดขึ้นมาว่าหากโค้ดเป็นภาษาที่นักพัฒนาเขียนอย่างระมัดระวังจะต้องระมัดระวังในการรักษาความเข้ากันได้ ไม่ได้กำหนดความเข้ากันได้ที่เป็นประโยชน์จริง ๆแต่ฉันคิดว่ามันคล้ายกับความคิดที่ฉันยกมาจากการอภิปราย PEP 387 ด้านบน
จากมุมมองของโปรแกรมเมอร์
ในฐานะโปรแกรมเมอร์ฉันรู้ว่า Python จะเปลี่ยนไปในอนาคตและผู้คน - ตัวฉันเองที่สะดุดตาที่สุด - จะพยายามเรียกใช้โค้ดของฉันหลายปีต่อจากนี้ในเวอร์ชัน Python ที่เป็นหนึ่งสองหรือสามรุ่นรอง ไม่ใช่ทุกอย่างที่จะเข้ากันได้และอันที่จริงมันง่ายที่จะเกิดขึ้นกับรหัสที่จะล้มเหลว (ฉันเคยพบรหัสที่ระบุif sys.version[:3] != '2.3': print 'Wrong version, exiting') สิ่งที่ฉันกำลังมองหาคือชุดของแนวทางเกี่ยวกับสิ่งที่ต้องทำและสิ่งที่ ไม่ ควรทำเพื่อเพิ่มโอกาสที่รหัสของฉันจะยังคงทำงานไม่เปลี่ยนแปลงในอนาคต
มีแนวทางดังกล่าวหรือไม่? ฉันจะเขียนโค้ด Python ที่จะยังคงทำงานได้ในอนาคตได้อย่างไร
คำถามของฉันที่เกี่ยวข้องทั้งแกนหลามไปยังห้องสมุดมาตรฐาน แต่ยังใช้กันทั่วไป add-on ห้องสมุดโดยเฉพาะอย่างยิ่งnumpy, ,scipymatplotlib
แก้ไข : ถึงตอนนี้คำตอบสองข้อเกี่ยวข้องกับ python2 กับ python3 นี่ไม่ใช่สิ่งที่ฉันหมายถึง ฉันรู้เกี่ยวกับเครื่องมือในการโยกย้ายจาก Python2 ไปยัง Python3 คำถามของฉันที่เกี่ยวข้องกับการเปลี่ยนแปลงของภาษายังมาไม่ถึง เราสามารถทำได้ดีกว่าลูกบอลคริสตัลในการค้นหาแนวทางการเข้ารหัสที่มีเสถียรภาพมากขึ้น ตัวอย่างเช่น:
import moduleเป็นหลักฐานในอนาคตมากกว่าfrom module import *เพราะหลังสามารถแบ่งรหัสหากmoduleขยายฟังก์ชั่น / คลาสใหม่การใช้วิธีการที่ไม่ได้จดทะเบียนอาจพิสูจน์ได้ในอนาคตน้อยกว่าการใช้วิธีการที่ทำเป็นเอกสารเนื่องจากสิ่งที่ไม่ได้จดทะเบียนอาจเป็นสัญญาณบ่งบอกถึงสิ่งที่ไม่มั่นคง
มันเป็นคำแนะนำการเขียนโค้ดเชิงปฏิบัติแบบนี้ที่ฉันตามหา เนื่องจากเป็นเรื่องเกี่ยวกับปัจจุบัน→อนาคตเราสามารถ จำกัด ตัวเองเป็น Python3 ได้เพราะ Python2 จะไม่เปลี่ยนแปลงอีกต่อไป