รักษาภาษาการเขียนโปรแกรมไว้ด้านหลังและแก้ไขข้อบกพร่อง

ขั้นแรกให้บริบท (สิ่งที่คุณส่วนใหญ่รู้อยู่แล้ว):

ภาษาการเขียนโปรแกรมยอดนิยมทุกภาษามีวิวัฒนาการที่ชัดเจนเวลาส่วนใหญ่ถูกทำเครื่องหมายโดยเวอร์ชัน: คุณมี Java 5, 6, 7 ฯลฯ , PHP 5.1, 5.2, 5.3 ฯลฯ การปล่อยเวอร์ชันใหม่ทำให้ API ใหม่พร้อมใช้งานแก้ไขข้อบกพร่องเพิ่ม คุณสมบัติใหม่กรอบใหม่ ฯลฯ ดังนั้นทั้งหมด: ดี

แต่ปัญหาของภาษา (หรือแพลตฟอร์ม) เกี่ยวกับอะไร? หากและเมื่อมีสิ่งผิดปกติในภาษานักพัฒนาอาจหลีกเลี่ยง (ถ้าพวกเขาสามารถ) หรือพวกเขาเรียนรู้ที่จะอยู่กับมัน

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

วิธีที่ดีที่สุดที่ฉันสามารถอธิบายคำถามของฉันคือการใช้ PHP เป็นตัวอย่าง:

PHP เป็นที่รักและเกลียดชังคนหลายพันคน ทุกภาษามีข้อบกพร่อง แต่เห็นได้ชัดว่า PHP นั้นพิเศษ ลองดูโพสต์บล็อกนี้ มันมีรายการที่ยาวมากของข้อบกพร่องที่เรียกว่าใน PHP ตอนนี้ฉันไม่ใช่นักพัฒนา PHP (ยังไม่ได้) แต่ฉันอ่านทั้งหมดและฉันแน่ใจว่ารายการใหญ่ ๆ นั้นเป็นปัญหาจริง (ไม่ใช่ทั้งหมดเพราะมันอาจเป็นอัตวิสัย)

ตอนนี้ถ้าฉันเป็นหนึ่งในคนที่พัฒนา PHP ฉันจะต้องแก้ไขปัญหาเหล่านั้นทีละคน อย่างไรก็ตามถ้าฉันทำอย่างนั้นรหัสที่อาศัยลักษณะการทำงานเฉพาะของภาษาจะแตกถ้ามันทำงานในรุ่นใหม่ สรุปมันขึ้นมาใน 2 คำ: เข้ากันได้ย้อนหลัง

สิ่งที่ฉันไม่เข้าใจ: ทำไมฉันจึงควรใช้ PHP ย้อนหลังได้ ถ้าฉันปล่อย PHP เวอร์ชัน 8 พร้อมแก้ไขปัญหาเหล่านั้นฉันจะเตือนไม่ได้ว่า: "อย่ารันโค้ดเก่าในเวอร์ชั่นนี้!"?

มีสิ่งที่เรียกว่าการคัดค้าน เรามีมันมาหลายปีและใช้งานได้ ในบริบทของ PHP: ดูว่าคนสมัยนี้ไม่สนับสนุนการใช้mysql_*ฟังก์ชั่น (และแนะนำmysqli_*และ PDO) การเลิกทำงาน เราสามารถใช้มัน เราควรใช้มัน ถ้ามันใช้งานได้กับฟังก์ชั่นทำไมมันไม่เหมาะกับทั้งภาษา

สมมติว่าฉัน (ผู้พัฒนา PHP) ทำสิ่งนี้:

• เปิดตัว PHP เวอร์ชันใหม่ (สมมุติว่า 8) โดยมีการแก้ไขข้อบกพร่องทั้งหมด
• โครงการใหม่จะเริ่มใช้เวอร์ชันนั้นเนื่องจากจะดีกว่าชัดเจนกว่าปลอดภัยกว่าเป็นต้น
• อย่างไรก็ตามเพื่อที่จะไม่ละทิ้ง PHP เวอร์ชันเก่าฉันจะทำการอัปเดตต่อไปแก้ไขปัญหาด้านความปลอดภัยข้อผิดพลาดและอื่น ๆ สิ่งนี้เหมาะสมสำหรับเหตุผลที่ฉันไม่ได้แสดงรายการไว้ที่นี่ มันเป็นเรื่องธรรมดา: ดูตัวอย่างว่า Oracle ทำการอัปเดตเวอร์ชัน 5.1.x ของ MySQL ได้อย่างไรแม้ว่าส่วนใหญ่จะเน้นที่รุ่น 5.5.x
• หลังจากผ่านไปประมาณ 3 หรือ 4 ปีฉันหยุดอัปเดต PHP เวอร์ชันเก่าแล้วปล่อยให้มันตาย นี่เป็นเรื่องดีเนื่องจากใน 3 หรือ 4 ปีโครงการส่วนใหญ่จะเปลี่ยนเป็น PHP 8 ต่อไป

คำถามของฉันคือ: ขั้นตอนเหล่านี้เหมาะสมหรือไม่ มันยากไหมที่จะทำ? ถ้าสามารถทำได้แล้วทำไมมันไม่ทำ?

ใช่ข้อเสียคือคุณทำลายความเข้ากันได้ไปข้างหลัง แต่นั่นไม่ใช่ราคาที่คุ้มค่าหรือไม่ ในแง่กลับหัวกลับหางใน 3 หรือ 4 ปีคุณจะมีภาษาที่มีปัญหา 90% ของปัญหาได้รับการแก้ไข .... ภาษาที่น่าทำงานมากขึ้น ชื่อของมันจะรับประกันความนิยม

แก้ไข : ตกลงดังนั้นฉันไม่ได้แสดงตัวเองอย่างถูกต้องเมื่อฉันกล่าวว่าใน 3 หรือ 4 ปีผู้คนจะย้ายไปที่สมมุติ PHP 8 สิ่งที่ฉันหมายถึงคือ: ใน 3 หรือ 4 ปีผู้คนจะใช้ PHP 8 ถ้าพวกเขาเริ่ม โครงการใหม่.

มันฟังดูดี แต่ไม่ค่อยได้ผลในทางปฏิบัติ ผู้คนลังเลที่จะเปลี่ยนรหัสการใช้งานและแม้แต่โครงการสีเขียวใหม่พวกเขายังลังเลที่จะเปลี่ยนวิธีใช้จากภาษา / รุ่นที่พวกเขารู้อยู่แล้ว

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

(เห็นได้ชัดว่าสิ่งนี้ส่วนใหญ่ไม่ได้ใช้กับโปรเจ็กต์ที่เขียนโดยมือสมัครเล่นเพียงเพื่อความพอใจของตัวเองอย่างไรก็ตาม (นี่คือ Flamebait ... ) PHP นั้นไม่ค่อยถูกเลือกโดยแฮ็กเกอร์เพราะมันเป็นความสุข )

คุณดูถูกดูแคลนผลกระทบของความเข้ากันได้ย้อนหลัง ประมาณการของคุณว่าโครงการที่ใช้งานอยู่ทั้งหมดจะย้ายใน 3 หรือ 4 ปีนั้นมองในแง่ดีเกินไป

สมมติว่าฉันเป็นนักพัฒนา PHP PHP มีข้อบกพร่อง แต่ฉันรู้วิธีแก้ไขข้อบกพร่องเหล่านั้น - นั่นเป็นส่วนหนึ่งของเหตุผลที่ฉันได้รับเงินในฐานะนักพัฒนา PHP ตอนนี้สมมติว่า PHP 8 ออกมาและแก้ไขข้อบกพร่องเหล่านั้น แต่มันไม่เข้ากันได้ย้อนหลัง ผลที่ตามมา:

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

เมื่อพิจารณาถึงสิ่งนี้จะมีแรงจูงใจอย่างมากที่จะไม่ย้ายไปที่ PHP 8 แม้ว่าจะเป็น "ดีกว่าชัดเจนกว่าปลอดภัยกว่า ฯลฯ " ประมาณว่ายังมีอีกหลายพันล้านบรรทัดของ COBOL (!) - แม้ว่าจะมีเทคโนโลยีที่ดีกว่าอย่างเห็นได้ชัดค่าใช้จ่ายของการอัปเดตรวมกับความเสี่ยงของข้อผิดพลาดเพียงแค่ไม่คุ้มค่า

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

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

ดูไพ ธ อนสำหรับตัวอย่าง 3.x เปิดให้บริการมาสี่ปีแล้วและยังไม่ได้รับการยอมรับอย่างกว้างขวาง ผู้คนพยายามใช้มันสำหรับโครงการใหม่เอี่ยม แต่ฉันคิดว่าคุณประเมินต่ำเกินไปว่ามีการบำรุงรักษาโค้ดเพียงใด

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

สำหรับภาษาอื่นที่ไม่ใช่ PHP ฉันว่าใช่นั่นก็สมเหตุสมผลแล้ว! นั่นคือสิ่งที่ Python ทำกับสวิตช์เป็น Python 3

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

ชุมชน PHP นั้นช้ามากในการปรับตัวใหม่ ๆ register_globalsเพียงแค่มองนานเท่าใดจึงจะได้รับการกำจัด เป็นที่ทราบกันว่ามีความเสี่ยงด้านความปลอดภัยตั้งแต่ปี 2000 และในที่สุดก็ถูกลบออกไปในอีก 12 ปีต่อมา อีกตัวอย่างหนึ่งเมื่อมีการแนะนำ PHP5 มันเป็นการปรับปรุงที่ดีกว่า PHP4 แต่ชุมชนก็ไม่ได้ปรับตัว ฉันใช้เวลา 4 ปีและการกระทำที่ยิ่งใหญ่เช่นGoPHP5เพื่อเริ่มต้นการยอมรับ และนั่นก็ไม่ได้มีการเปลี่ยนแปลงที่เข้ากันไม่ได้อย่างมีนัยสำคัญย้อนหลัง

ข้อจำกัดความรับผิดชอบ: ฉันจัดการกลุ่มผู้ใช้ ColdFusion

ColdFusion ทนทุกข์ทรมานปัญหาเดียวกัน: รักโดยหลายคนดูถูกโดยมาก นอกจากนี้ตันและตันของ FUD ขึ้นอยู่กับรุ่น pre-Java ColdFusion 10 ออกมาเมื่อปีที่แล้วเป็นผู้ขายรายใหญ่และเมื่อสัปดาห์ที่แล้วฉันลงทะเบียนเพื่อทดสอบรุ่นก่อนวางจำหน่ายของรุ่นที่ 11 นอกจากนี้ยังมีทางเลือกโอเพนซอร์ซสองทางเลือกหนึ่งที่ได้รับการสนับสนุนจาก JBoss

มีฟังก์ชันใหม่มากมายใน CF10 ที่ฉันชอบนำไปใช้ แต่การย้ายจาก CF 7 หรือ 8 อาจทำได้ยากขึ้นอยู่กับขนาดของฐานรหัสของคุณจำนวนโปรเจ็กต์ที่จะมาถึงและทรัพยากรที่คุณต้องทดสอบทุกอย่างเมื่อคุณถดถอย เป็นเวอร์ชั่นล่าสุด ฉันพบความแตกต่างของการสร้างประโยคต่างกันเล็กน้อยระหว่าง 8 และ 9 รวมถึงกรณีขอบที่รหัสไม่ได้รวบรวมในลักษณะเดียวกัน เมื่อพบแล้วฉันบันทึกไว้ในมาตรฐานการเข้ารหัสของเราเพื่อไม่ให้ใช้ในโครงการในอนาคตหรือโดยนักพัฒนาใหม่

ที่กล่าวว่าหาก ColdFusion 11 (หรือภาษาการเขียนโปรแกรมใด ๆ ) ต้องเลิกใช้งานฟังก์ชั่นและไวยากรณ์บางอย่างอย่างสมบูรณ์ระดับของความพยายามในการค้นหาและแทนที่ฟังก์ชั่นอาจมหาศาล ความพยายามในการทดสอบอาจมีขนาดใหญ่ บริษัท ต่างๆจะจ่ายเงินให้นักพัฒนา QA และผู้จัดการโครงการเพื่อค้นหาแทนที่และทดสอบสิ่งที่เลิกใช้แล้วหรือไม่? น่าสงสัย

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

ในฐานะ บริษัท เราต้องกังวลเกี่ยวกับความพึงพอใจของลูกค้าและส่งมอบความต้องการของพวกเขาเพื่อเรียกเก็บเงินบริการสร้างธุรกิจและรับสมัครลูกค้ามากขึ้น

FWIW ฉันชอบที่จะพาเราไปสู่ ​​jQuery รุ่นล่าสุดในบางจุด แต่เนื่องจากฟังก์ชั่นบางอย่างถูกคัดค้านไม่กี่รุ่นหลังจากสิ่งที่เราใช้และปริมาณ JavaScript ที่เรามีอยู่ในระบบฉันไม่รู้ เราจะดึงมันออกมา

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

นี่คือ (ความคิดของฉัน) ความแตกต่างระหว่างรุ่นใหญ่รุ่นรองและรุ่น ตามหลักการทั่วไป:

• การเปิดตัวที่สำคัญจะมีการเปลี่ยนแปลงที่ไม่คาดคิด
• รุ่นเล็กอาจเปลี่ยนแปลงพฤติกรรมเล็กน้อย
• การแก้ไขควรมีความเข้ากันได้ข้าม

ตัวอย่างเช่นถ้าฉันเขียนบางสิ่งในภาษา v2.3 ฉันไม่คาดหวังว่าจะสังเกตเห็นความแตกต่างใด ๆ หากฉันอัปเกรดเป็น v2.3.2 ถ้าฉันอัพเกรดเป็น v2.4 แล้วบางสิ่งอาจเปลี่ยนแปลง - ปรับแต่งไวยากรณ์ขนาดเล็กฟังก์ชั่นบางอย่างทำงานแตกต่างกันเล็กน้อยดังนั้นฉันต้องปรับแต่งตรรกะ ฯลฯ ถ้าฉันอัพเกรดเป็น v3.0 ฉันจะไม่แปลกใจถ้ามันพัง ทั้งหมด - ฟังก์ชั่นที่เลิกใช้หรือหายไปการดำเนินการไม่ได้รับการสนับสนุนหรือเปลี่ยนแปลงมากจนฉันไม่สามารถบิดมันกลับเข้าแถวได้ฉันต้องเขียนฟังก์ชั่นบางอย่างเพื่อรับการเปลี่ยนแปลงใหม่

แก้ไข:

กระดาษกลยุทธ์ขั้นสูงในการแยกสาขาของ SCMของ Steve Vance กล่าวไว้ดังนี้:

โดยทั่วไปจะมีการปล่อยสองถึงสามระดับตั้งชื่อโดยตัวเลขที่เชื่อมต่อกับจุด (เช่น 1.2.3) [... ] ในโครงสร้างนี้หมายเลขแรกมีความเกี่ยวข้องกับรุ่นใหญ่ระบุว่ามันมีคุณสมบัติที่สำคัญและการปรับปรุงการทำงานจากก่อนหน้า; อาจมีความไม่ลงรอยกันอย่างมีนัยสำคัญที่ต้องมีการย้าย หมายเลขที่สองแสดงถึงรุ่นรองซึ่งประกอบด้วยคุณสมบัติที่น้อยกว่าและการปรับปรุงฟังก์ชันจำนวนการแก้ไขข้อบกพร่องจำนวนมากและไม่มีความเข้ากันไม่ได้ หมายเลขที่สามหมายถึงระดับแพตช์ซึ่งบ่งบอกถึงการรวบรวมการแก้ไขข้อบกพร่องเกือบเฉพาะ ไม่มีการปรับปรุงคุณสมบัติหรือฟังก์ชั่นและไม่อนุญาตให้ใช้งานร่วมกันไม่ได้ระหว่างระดับแพตช์

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

ขึ้นอยู่กับเป้าหมายของภาษา - ประเภทของแอปพลิเคชั่นที่ต้องการสร้างด้วยภาษา

ตัวอย่างเช่นการละเว้น Android, Java ส่วนใหญ่จะใช้ในระบบองค์กรขนาดใหญ่และเครื่องกลาง; แอปพลิเคชันประเภทนี้มีแนวโน้มที่จะมีขนาดใหญ่มากทั้งขนาดและเวลา เรื่องนี้มีความหมายบางอย่าง; จินตนาการถึงระบบที่มี 500K + LoC ซึ่งวิศวกร 50+ คนในช่วงการพัฒนา โดยทั่วไปแล้วระบบประเภทนี้จะเข้าสู่การบำรุงรักษาหลังจากนี้ด้วย 10 นักพัฒนาพูด; ตอนนี้หากการเปลี่ยนแปลงภาษาและการเปลี่ยนแปลงไม่เข้ากันได้ย้อนหลังโครงการไม่สามารถโยกย้ายไปยังเวอร์ชันใหม่ได้อย่างง่ายดายเพราะโปรแกรมเมอร์ที่เขียนบางส่วนหายไปและไม่มีใครอยากสัมผัส นี่เป็นปัญหาที่เล็กกว่าปัญหาที่ใหญ่กว่านั้นประกอบไปด้วยความจริงที่ว่ามีราคาแพงในการปรับแอปพลิเคชัน 500 LoC ให้เป็นข้อ จำกัด ด้านภาษาใหม่ ตัวอย่างเช่นถ้า generics ไม่ได้ใช้งานกับการลบประเภทและList list = new List(); จะไม่รวบรวมรหัสหลายล้านบรรทัดจะต้องมีการเขียนใหม่ - ซึ่งมีค่าใช้จ่ายที่ดี

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

หนึ่งสามารถโต้แย้ง Microsoft ดำเนินการเปลี่ยนแปลงที่คล้ายกันกับ ASP.NET (เป็นตัวตายตัวแทน ASP คลาสสิก) หรือกับ VB.NET (แม้ว่าพวกเขาทำสัมปทานจำนวนมากด้วยหลังซึ่งส่วนใหญ่ผลประโยชน์ของ "รีบูต" ภาษาที่หายไป)

อย่างไรก็ตามหากใครจำฝันร้ายของการย้ายรหัส VB6 ไปยัง VB.NET แม้จะได้รับความช่วยเหลือจากเครื่องมือการโยกย้ายพวกเขาจะเห็นด้วยทันทีว่าเครื่องมือการโยกย้ายภาษานั้นทำงานได้ไม่ดีสำหรับการอัปเดตภาษาที่สำคัญ

อาจเป็นไปได้ที่จะย้ายแพลตฟอร์มไปข้างหน้า แต่คุณควรให้การสนับสนุน API "ที่เลิกใช้แล้ว" ผ่านการแก้ไขอย่างน้อยสองสามครั้ง

คน "ข้อบกพร่อง" หลายคนกรีดร้องเกี่ยวกับภาษาการเขียนโปรแกรมยอดนิยมไม่ใช่พวกเขาเป็นสิ่งที่ของเล่นโปรดของนักโวยวายในวันนั้นมีภาษานั้นขาดไปดังนั้นภาษานั้นก็มีข้อบกพร่องพื้นฐานเพราะขาดมัน
การโฆษณาครั้งต่อไปมารอบ ๆ ภาษาก็มีข้อบกพร่องในทันทีเพราะมันไม่ได้เป็นไปตามการโฆษณานั้น

การขาดการปิดใน Java เป็นตัวอย่างคลาสสิก นั่นไม่ได้เป็นข้อบกพร่องในภาษาเลยและการเปลี่ยนภาษา (เช่นเศร้าในวาระ) เพื่อรวมพวกเขาจะ IMO พื้นฐานพิการหรืออย่างน้อยทำให้ยากมากที่จะอ่านและเข้าใจ

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

เพิ่มดังที่คนอื่น ๆ ชี้ให้เห็นว่าความเข้ากันได้แบบย้อนหลังนั้นมีความสำคัญต่อการรักษาผู้ใช้ที่มีอยู่ซึ่งหลายคนไม่ได้ใช้เวลาหลายพันชั่วโมงและหลายล้านดอลลาร์ / ยูโรเพื่อติดตั้งฐานรหัสล้านบรรทัดของพวกเขา กว่ารุ่นของภาษาที่พวกเขาใช้มานานหลายปีแล้วและคุณมีข้อโต้แย้งที่ดีมากที่จะปล่อยให้อยู่คนเดียวได้ดีและถ้าคุณต้องการเล่นกับความคิดใหม่ ๆ ที่น่าตื่นเต้นนั่นคือ "นักฆ่า java" คนต่อไปของคุณ เล่นให้ดีที่สุดกับของเล่นชิ้นนั้นแทนที่จะร้องว่า "Java iz อุทิศ" เว้นแต่ว่า "ได้รับการแก้ไข" เพื่อให้เป็นของเล่นที่ทำเลียนแบบ

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

ตัวอย่างเช่นถ้าฉันออกแบบภาษาใหม่คล้ายกับ Java หรือ C # ฉันจะห้ามการแปลงประเภทโดยนัยในบริบทบางอย่างที่ภาษาเหล่านั้นอนุญาต เป็นตัวอย่างง่ายๆใน C # ที่ได้รับ

int someInt;
double someDouble;

การแสดงออกsomeInt.Equals(someDouble)รับประกันการกลับเท็จโดยไม่คำนึงถึงเนื้อหาของตัวแปร มันคอมไพล์เพราะdoubleสามารถแปลงเป็นObjectและintมีEqualsโอเวอร์โหลดสำหรับประเภทนั้นคอมไพเลอร์ทำการแปลงและทำการโทร ถ้าฉันออกแบบ C # และ. NET Framework เวอร์ชันใหม่ฉันจะห้ามการแปลงมวยเพราะมันอาจจะไม่ทำสิ่งใดที่มีประโยชน์ มีความเป็นไปได้ว่ามีบางโปรแกรมที่ทำการเปรียบเทียบในลักษณะที่ไร้ประโยชน์ แต่ไม่เป็นอันตรายและการคอมไพเลอร์ปฏิเสธรหัสดังกล่าวอาจทำให้โปรแกรมนั้นแตก แต่การแก้ไขหรือลบรหัสที่ไร้ประโยชน์นั้นจะเป็นการปรับปรุง

เป็นตัวอย่างที่ชัดเจนน้อยกว่าเล็กน้อยสมมติว่า

float f=16777216f;
int i=16777217;

f==iและพิจารณาการแสดงออก เป็นไปได้ว่าบางรหัสไม่ลอยเปรียบเทียบ / จำนวนเต็มและทำงานได้อย่างถูกต้อง แต่รหัสควรจะเขียนใหม่เป็นอย่างใดอย่างหนึ่งf==(float)i, (double)f==i;หรือ(double)f==(double)i;[ intการdoubleโปรโมชั่น lossless เพื่อให้ทั้งสองฝ่ายจะเทียบเท่า] โค้ดบางตัวที่เปรียบเทียบโดยตรงfloatและintegerค่าอาจจัดการกับตัวเลขที่มีขนาดเล็กเพียงพอfloatและdoubleการเปรียบเทียบจะทำงานเหมือนกัน แต่โดยทั่วไปคอมไพเลอร์ไม่สามารถรู้ได้ รหัสควรทำให้ชัดเจนว่าต้องการการเปรียบเทียบแบบใดแทนที่จะหวังว่ากฎของภาษาจะตรงกับความตั้งใจของโปรแกรมเมอร์

มันเป็นการดีที่สุดที่จะไม่หยุดย้อนหลังความเข้ากันได้

Microsoft แทนที่ภาษาการเขียนโปรแกรม VB6 ด้วยภาษาใหม่ที่ทำลายความเข้ากันได้โดยสิ้นเชิง ดังนั้นแม้กระทั่งทุกวันนี้ VB6 อายุ 16 ปียังคงได้รับความนิยมมากกว่ารุ่น dotNet (ดัชนี Tiobe สิงหาคม 2014) และการ์ตเนอร์ประเมินว่ายังคงมีการใช้รหัส VB6 อยู่ 14 พันล้านบรรทัด

ในปี 2014 Microsoft ได้ประกาศอีกครั้งว่าพวกเขาจะไม่อัปเดตหรือโอเพนซอร์ส VB6 แม้จะมีความต้องการจากชุมชนการเขียนโปรแกรม Visual Basic แต่พวกเขาได้ขยายการรองรับ VB6 ไปจนถึง 'อย่างน้อย' 2024 และทำงานได้ดีบน Windows 7 และ 8 ซึ่งจะสนับสนุนมากกว่า 26 ปีสำหรับ VB6 รุ่นเดียวกัน

เหตุใดซอฟต์แวร์การทำงานที่มีอยู่ควรจะถูกเขียนซ้ำอีกครั้งแม้ Microsoft จะไม่เคย "อัพเดท" Office เพื่อใช้ dotNet?

มีปัญหาที่แตกต่างกันเล็กน้อยเกี่ยวกับความเข้ากันได้ย้อนหลัง ปัญหาบางอย่างเกิดขึ้นจากความจริงที่ว่าภาษาการเขียนโปรแกรมส่วนใหญ่ยังเป็นแพลตฟอร์ม (ล่าม / รันไทม์) ปัญหาอื่น ๆ เกิดจากการสันนิษฐานของธรรมชาติของมนุษย์

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

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

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

D. เอกสารใหม่จะต้องได้รับการเก็บรักษาและบำรุงรักษา เป็นประสบการณ์ที่ค่อนข้างสับสนในการค้นหาสิ่งต่าง ๆ บน Google และพบว่าคุณกำลังอ่านเอกสารสำหรับรุ่นที่แตกต่างจากที่คุณใช้อยู่ในปัจจุบัน

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

Facebook สร้างความรำคาญให้กับผู้คนเมื่อมันเปลี่ยน UI หรือ API ของนักพัฒนา ในอดีตมันทำให้แพลตฟอร์มยากที่จะทำงานด้วย ในบางกรณี APIs ก็หยุดทำงานจากสีน้ำเงิน แต่ผู้คนก็ยังใช้มันอยู่และตอนนี้ API และ UIs ก็เป็นก้าวกระโดดที่ดีกว่าเมื่อ 5 ปีก่อน ผู้คนจะบ่นเกี่ยวกับการเปลี่ยนแปลงไม่ว่าจะดีหรือไม่ดีสำหรับพวกเขา แต่การบ่น (บ่น) ไม่ใช่เหตุผลที่ดีที่จะละทิ้งการเปลี่ยนแปลงนั้น น่าเสียดายที่ผู้พัฒนาโปรแกรมภาษาใช้สิ่งนี้เป็นเหตุผลในการทำให้ปัญหาภาษาของพวกเขายังคงอยู่

ดังนั้นอีกสองเหตุผลสำหรับภาษาที่ไม่ทำให้เกิดการเปลี่ยนแปลงเพื่อปรับปรุงตนเองคือ:

E. นักพัฒนาภาษาคิดว่าผู้ใช้กลัวการเปลี่ยนแปลงเป็นเหตุผลที่ดีในการทำให้ภาษาชะงักงัน

F. นักพัฒนาภาษาชอบภาษาของพวกเขาเมื่อพวกเขาทำมันและพวกเขาอาจคิดว่ามันดีกับข้อบกพร่องของมัน

G. ภาษาในขณะที่พวกเขาโตขึ้นมักจะหยุดที่จะมีชุดหลักของนักพัฒนาและกลายเป็นสัตว์ที่สร้างขึ้นจากคณะกรรมการมากขึ้น นี่หมายถึงการตัดสินใจเกี่ยวกับภาษาเหล่านั้นช้าและมักอนุรักษ์และไม่สร้างสรรค์

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

บ่อยครั้งที่นักออกแบบภาษาไม่จำเป็นต้องเป็นนักออกแบบเครื่องมือดังนั้นพวกเขาจึงไม่คิดถึงวิธีแก้ปัญหาที่ดีสำหรับปัญหานี้หรือพวกเขาไม่สามารถทำงานได้ดี นี่คือวิธีแก้ปัญหาบางอย่างที่ฉันสามารถนึกถึงในการแก้ปัญหาการเปลี่ยนแปลง:

1. เลิกใช้สิ่งที่ดีล่วงหน้าเมื่อพวกเขาจะถูกลบออก

2. มอบเครื่องมือแปลงที่ดีและเป็นมาตรฐาน Python ให้เครื่องมือ 2to3 แต่มันไม่ได้โฆษณาที่ดีไม่ได้มาตรฐานด้วย python 3 ตามที่ฉันจำได้และไม่ทำงานได้ดีมาก (ฉันจำได้ว่าต้องผ่านโปรแกรมที่สร้างโดย 2to3 ด้วยตนเองเพื่อแก้ไขปัญหา ไม่ได้แก้ไข) เครื่องมือแปลงนี้สามารถทำงานได้โดยอัตโนมัติหากคอมไพเลอร์ / ล่ามของคุณตรวจพบเวอร์ชันที่เก่ากว่า อะไรจะง่ายไปกว่านี้?

ฉันไม่รู้ว่าเป็นปัญหาสำหรับรหัส PHP หรือไม่ แต่ในหลาย ๆ ภาษาเก่ารหัสมรดกไม่เคยอัปเดตหลังจากหลายปีหรือบางครั้งแม้แต่ทศวรรษเพราะมันใช้งานได้มันมีความสำคัญอย่างยิ่งต่อธุรกิจที่ใช้งานและมีขนาดใหญ่เกินไป (พูด SLOC นับล้านรายการ) ดังนั้นจึงไม่มีเหตุผลที่จะเขียนใหม่ นั่นเป็นเหตุผลว่าทำไมจาวาสร้างความเข้ากันได้แบบย้อนหลังเป็นประเด็นทางศาสนาเกือบทั้งที่รู้ปัญหาเก่าโดยเฉพาะในห้องสมุด (แม้ว่าจะง่ายต่อการอัพเดท) ฉันเดาว่าโค้ดจำนวนมากจากเคอร์เนล Linux ไม่ได้รับการปรับปรุงมานานหลายทศวรรษเช่นกันแม้จะมีการใช้มาตรฐานเช่น C99 และ C11

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

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