การพัฒนาเว็บแอปพลิเคชันสำหรับอายุการใช้งานที่ยาวนาน (20+ ปี)

160

ฉันกำลังพัฒนาเว็บแอปพลิเคชันสำหรับการวางแผนที่ดินของรัฐบาล แอปพลิเคชันส่วนใหญ่ทำงานในเบราว์เซอร์โดยใช้ Ajax เพื่อโหลดและบันทึกข้อมูล

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

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

javascript web-development future-proof

— แดน
แหล่งที่มา

94

ฉันเริ่มเขียนโปรแกรมที่ Fortran ในปลายปี 1966 ดังนั้นฉันจึงมีเวลาเหลือเฟือที่จะคิดเกี่ยวกับปัญหาแบบนั้น หากคุณเคยเจอคำตอบที่น่าเชื่อถือถึง 50% โปรดแจ้งให้เราทราบ ในขณะที่เพียงแค่คิดว่าล้าสมัยหลีกเลี่ยงไม่ได้เกือบบางอย่าง "รักษาความปลอดภัยงาน" :)

— จอห์น Forkosh

11

ไม่มีอะไรจะคงอยู่ตลอดไปใน Software Engineery เพียงโฮสต์ที่ธนาคารและเพราะไม่มีใครกล้าที่จะอัปเดตระบบที่สำคัญเช่นนี้ ฉันคิดว่าโปรแกรมที่ทำงานใน Voyager ก็มีค่าเช่นกัน

— Laiv

9

@Laiv บางครั้งฉันก็ทำงานกับแอพพลิเคชั่นการโอนเงินสำหรับ Bankers Trust โดยใช้ Swift Messaging ที่ทำงานบน Vax / VMS ไม่กี่ปีต่อมา Swift eol'ed (end-of-life'ed) สนับสนุนทั้งหมด VMS เด็กชายนั่นเป็นสาเหตุของปัญหา ... และมอบสัญญาอีกฉบับหนึ่งให้กับฉันที่ BTCo อย่างที่ฉันได้กล่าวไว้ข้างต้น "ความปลอดภัยของงาน" :) ยังไงก็ตามประเด็นของฉันก็คือแม้การใช้งานในตลาดการเงินที่สำคัญไม่ได้รับการยกเว้นล้าสมัย

— John Forkosh

102

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

— David Starkey

38

เพียงใช้ HTML ธรรมดาแบบเก่าไม่มี JS ไม่มีปลั๊กอินไม่มีอะไรแฟนซี ถ้ามันทำงานในคมก็ดีตลอดเวลา

— ออกุสตุส

132

การวางแผนซอฟต์แวร์สำหรับอายุการใช้งานนั้นยากเพราะเราไม่รู้ว่าอนาคตจะเป็นอย่างไร บริบทนิดหน่อย: Java เผยแพร่เมื่อปี 1995 21 ปีที่แล้ว XmlHttpRequest ครั้งแรกพร้อมใช้งานเป็นส่วนขยายที่เป็นกรรมสิทธิ์สำหรับ Internet Explorer 5 เผยแพร่เมื่อปี 1999 เมื่อ 17 ปีก่อน ใช้เวลาประมาณ 5 ปีจนกระทั่งเบราว์เซอร์หลัก ๆ ทั้งหมดใช้งานได้ 20 ปีที่คุณพยายามที่จะมองไปข้างหน้าเป็นเพียงเกี่ยวกับเวลาที่เว็บแอปพลิเคชันที่มีอยู่มากมายยังคงมีอยู่

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

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

จากประวัติศาสตร์นี้เราสามารถรวบรวมเบาะแสสองสาม:

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

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

หากคุณต้องการใช้ห้องสมุดหรือเครื่องมือเพราะมันทำให้การพัฒนาง่ายขึ้นมากก่อนอื่นตรวจสอบให้แน่ใจว่ามันสร้างขึ้นบนมาตรฐานที่รองรับในปัจจุบัน จากนั้นคุณต้องดาวน์โหลดไลบรารีหรือเครื่องมือและรวมไว้ในซอร์สโค้ดของคุณ ที่เก็บรหัสของคุณควรรวมทุกอย่างที่จำเป็นเพื่อให้ระบบสามารถทำงานได้ สิ่งภายนอกคือการพึ่งพาที่อาจทำลายในอนาคต วิธีที่น่าสนใจในการทดสอบนี้คือการคัดลอกรหัสของคุณไปยังฮาร์ดไดรฟ์ไปที่คอมพิวเตอร์เครื่องใหม่ที่มีระบบปฏิบัติการอื่นถอดการเชื่อมต่อจากอินเทอร์เน็ตและดูว่าคุณสามารถใช้ส่วนหน้าทำงานได้หรือไม่ ตราบใดที่โครงการของคุณประกอบด้วย HTML + CSS + JavaScript ธรรมดาบวกกับห้องสมุดบางแห่งคุณอาจจะผ่าน

— อมร
แหล่งที่มา

4

แอพพลิเคชั่นขนาดใหญ่นั้นไม่เคยหยุดนิ่งในวานิลลา ES6 ได้แก้ไขปัญหานี้แล้ว แต่ก็มีสาเหตุที่ทำให้กระแสหรือ TypeScript ได้รับความนิยม

— Andy

34

@DavidPacker แน่นอน TypeScript ฯลฯ นั้นยอดเยี่ยมและทำให้การพัฒนาง่ายขึ้น แต่ทันทีที่ฉันแนะนำกระบวนการสร้างเครื่องมือทั้งหมดที่จำเป็นสำหรับกระบวนการสร้างกลายเป็นการพึ่งพา: NodeJS, Gulp, NPM - ใครบอกว่า NPM จะยังคงออนไลน์ใน 20 ปี ฉันจะต้องเรียกใช้รีจิสทรีของตัวเองเพื่อให้แน่ใจ มันเป็นไปไม่ได้ แต่ในบางจุดมันเป็นการดีกว่าที่จะปล่อยให้สิ่งต่าง ๆ ที่ทำให้การพัฒนาง่ายขึ้นในทันทีเท่านั้น แต่ไม่ใช่ในระยะยาว

— amon

30

@DavidPacker มีภาษาแบบไดนามิกมากมายและน่าแปลกใจที่ระบบที่ประสบความสำเร็จจำนวนมากถูกสร้างขึ้นด้วย Smalltalk, Ruby, Perl, Python แม้กระทั่งกับ PHP และ JS ในขณะที่ภาษาที่พิมพ์แบบคงที่มีแนวโน้มที่จะรักษาได้มากขึ้นในขณะที่ภาษาแบบไดนามิกมีแนวโน้มที่จะดีกว่าสำหรับการสร้างต้นแบบอย่างรวดเร็วมันเป็นไปไม่ได้ที่จะเขียน JS แบบบำรุงรักษาได้ ในกรณีที่ไม่มีคอมไพเลอร์ทักษะค่ามัธยฐานสูงในทีมงานฝีมือและการเน้นเป็นพิเศษเกี่ยวกับการจัดระเบียบรหัสที่ชัดเจนยิ่งทวีความสำคัญยิ่งขึ้น ฉันคิดว่าประเภททำให้ทุกอย่างง่ายขึ้น แต่ไม่มีกระสุนเงิน

— amon

4

ฉันเพิ่งอ่านว่า "รับ usb และทดสอบกับเครื่องอื่น" หรือไม่? ทำไมไม่เพียงหมุนเวอร์ช่วลบ็อกซ์หรือใช้โหมดไม่ระบุตัวตน (ปิดการใช้งาน ethX)

— Kyslik

5

ฉันไม่แน่ใจวานิลลา JS จะเป็นสิ่งที่แน่นอน 20 ปีนับจากนี้ ประวัติของมันนั้นเต็มไปด้วยหินและมีการทดลองและมันก็หยิบเอา cruft จำนวนพอสมควรไปตามทางแม้ว่ามันจะกลายเป็นภาษาที่น่ายินดีและมีประสิทธิภาพ (ฉันเองชอบ JavaScript หรือ TypeScript เอง) ไม่ยากเลยที่จะจินตนาการว่าผู้ขายอาจต้องการที่จะทิ้งบางส่วนหรือทั้งหมดของ cruft ไม่ว่าจะหมายถึงการเริ่มเสนอภาษาทางเลือกใหม่ - เนื่องจาก Google ดูเหมือนจะเสนอให้กับ Dart แต่ดูเหมือนว่าจะไม่ไปไหน - หรือโดยการคัดค้านแล้วกำจัดส่วนของ JS

— KRyan

178

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

ดังนั้นเริ่มต้นด้วยรูปแบบข้อมูลที่ชัดเจนและมีเอกสารที่ดี
ใช้ระบบฐานข้อมูลที่ได้รับการสนับสนุนที่ดีเช่น Oracle ^[1]หรือ SQL Server
ใช้คุณสมบัติพื้นฐานอย่าพยายามบีบหน้าจอใหม่ที่ฉูดฉาด
ต้องการง่ายกว่าฉลาด
ยอมรับว่าการบำรุงรักษาในอนาคตอาจมีค่าใช้จ่ายด้านต่างๆเช่นประสิทธิภาพ ตัวอย่างเช่นคุณอาจถูกล่อลวงให้ใช้โพรซีเดอร์ที่เก็บไว้ แต่สิ่งเหล่านี้อาจ จำกัด การบำรุงรักษาในอนาคตหากพวกเขาป้องกันไม่ให้บางคนย้ายระบบไปสู่โซลูชันสตอเรจที่เรียบง่าย

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

^[1]ความคิดเห็นส่วนใหญ่เกี่ยวกับคำตอบนี้ใช้จุดยืนที่แข็งแกร่งในการใช้ Oracle กับฐานข้อมูลโดยอ้างเหตุผลที่ถูกต้องอย่างสมบูรณ์ว่าเหตุใดออราเคิลจึงเจ็บปวดในการทำงานด้วยมีช่วงการเรียนรู้ที่สูงชันและค่าใช้จ่ายในการติดตั้ง เหล่านี้เป็นความกังวลที่ถูกต้องอย่างสิ้นเชิงเมื่อเลือกออราเคิลเป็น DB แต่ในกรณีที่เราไม่ได้มองหา DB อเนกประสงค์ แต่อย่างหนึ่งที่กังวลหลักคือการบำรุงรักษา Oracle มีมาตั้งแต่ปลายทศวรรษ 70 และจะได้รับการสนับสนุนเป็นเวลาหลายปีและมีระบบที่ปรึกษาและตัวเลือกการสนับสนุนมากมายที่สามารถช่วยให้คุณทำงานต่อไปได้ นี่เป็นสิ่งที่เกินราคาสำหรับหลาย ๆ บริษัท หรือไม่ แน่ใจ แต่มันจะทำให้ฐานข้อมูลของคุณทำงานได้เป็นเวลา 20 ปีหรือไม่ มีโอกาสมาก

— Avner Shahar-Kashtan
แหล่งที่มา

141

ฉันขอโทษ แต่ฉันต้องพูดแบบนี้ หากคุณใช้ Oracle คุณจะต้องยิงทุกคนด้วยความเคารพ "ง่ายต่อการทำงาน" Oracle เป็นไม่ง่ายต่อการทำงานในน้อย ฟังก์ชั่นมากมายที่ SQL Server, PostgreSQL และบางทีแม้แต่ MySQL ก็จะทำให้ง่ายออราเคิลก็ไม่ได้มีปัญหาหรือทำให้ยากเกินไป ฉันไม่เคยมีปัญหาโง่ ๆ กับฐานข้อมูลอื่น ๆ เท่าที่ฉันมีกับ Oracle; แม้เพียงแค่การตั้งค่าลูกค้าเป็นความเจ็บปวดอย่างมากในก้น แม้แต่สิ่งที่ Google ก็เป็นเรื่องยาก หากคุณต้องการ "ใช้งานง่าย" ให้อยู่ห่างจาก Oracle

— jpmc26

4

+1 สำหรับการรักษาข้อมูลให้ง่ายที่สุด ใช้ SQL มาตรฐานสำหรับสิ่งนี้เช่นใช้OUTER JOINแทนโอเปอเรเตอร์เฉพาะ+ของ oracle ใช้เค้าโครงตารางอย่างง่าย อย่าทำให้ตารางของคุณกลับสู่ระดับปกติสูงสุด ตัดสินใจว่าบางตารางสามารถมีข้อมูลที่ซ้ำซ้อนหรือถ้าคุณต้องสร้างตารางใหม่เพื่อให้ทุกค่ามีอยู่เพียงครั้งเดียว ผู้ขายขั้นตอนการจัดเก็บเฉพาะหรือไม่ ถ้าใช่ก็อย่าใช้มัน อย่าใช้คุณสมบัติที่ร้อนแรงที่สุดของภาษาที่คุณเลือก: ฉันเคยเห็นโปรแกรมภาษาโคบอลเพิ่มเติมโดยไม่ต้องมีคุณสมบัติของ OOPแล้วกับพวกเขา และนั่นก็โอเคเลย

— some_coder

3

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

— Avner Shahar-Kashtan

8

หลีกเลี่ยง Oracle อย่างแน่นอน ฐานข้อมูลเดียวที่มีอยู่ในปัจจุบันที่ดูเหมือนว่าจะเป็นตัวเลือกที่ไม่ดีใน 20 ปีคือ Postgresql

— Joshua

3

ฉันต้องการเพิ่มว่า DBMS โอเพ่นซอร์สที่ดีนั้นดีกว่าเพราะมีโอกาสที่ดีที่พวกเขาจะไม่ตาย ถ้า Oracle หยุดทำเงินใน 10 ปีดังนั้นใน 11 จะหายไป PostreSQL ดูเหมือนจะเป็นม้าที่ดีที่สุดที่จะเดิมพัน

— Shautieh

36

คำตอบก่อนหน้านี้โดย amonนั้นยอดเยี่ยม แต่มีอีกสองจุดที่ไม่ได้กล่าวถึง:

มันไม่ได้เกี่ยวกับเบราว์เซอร์เท่านั้น อุปกรณ์ก็มีความสำคัญเช่นกัน

amon กล่าวถึงความจริงที่ว่า"เว็บไซต์ที่ทำงานบนเบราว์เซอร์เมื่อ 15 ปีก่อนจะยังคงใช้งานได้เหมือนเดิม"ซึ่งเป็นเรื่องจริง อย่างไรก็ตามดูที่เว็บไซต์ที่สร้างขึ้นไม่ได้สิบห้า แต่สิบปีที่แล้วซึ่งเมื่อสร้างแล้วทำงานในเบราว์เซอร์ส่วนใหญ่สำหรับผู้ใช้ส่วนใหญ่ วันนี้ผู้ใช้ส่วนใหญ่จะไม่สามารถใช้เว็บไซต์เหล่านั้นได้เลยไม่ใช่เพราะเบราว์เซอร์เปลี่ยนไป แต่เป็นเพราะอุปกรณ์ทำ เว็บไซต์เหล่านั้นดูน่ากลัวบนหน้าจอขนาดเล็กของอุปกรณ์มือถือและในที่สุดก็ใช้งานไม่ได้เลยหากนักพัฒนาตัดสินใจที่จะพึ่งพาclickเหตุการณ์JavaScript โดยที่ไม่รู้ว่าtapกิจกรรมนั้นมีความสำคัญเช่นกัน
คุณมุ่งเน้นไปที่วัตถุที่ผิด

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

ไม่สำคัญว่าจะเกิดอะไรขึ้นกับเบราว์เซอร์หรืออุปกรณ์หรือ W3C หรือ ... อะไรก็ตาม

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

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

ตัวอย่างเช่นฉันทำงานในการพัฒนาซอฟต์แวร์เป็นเวลาสิบปี ในบรรดาโครงการหลายสิบโครงการมีเพียงสองโครงการเท่านั้นที่ฉันตัดสินใจที่จะเปลี่ยนแปลงเนื่องจากเทคโนโลยีและแม่นยำมากขึ้นเพราะ PHP พัฒนาขึ้นมากในช่วงสิบปีที่ผ่านมา มันไม่ได้เป็นการตัดสินใจของลูกค้า: เขาจะไม่แคร์น้อยลงหากไซต์ใช้ namespaces หรือการปิดของ PHP อย่างไรก็ตามการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อกำหนดใหม่และความสามารถในการขยายระบบมีมากมาย!

— Arseni Mourzenko
แหล่งที่มา

4

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

— null

9

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

— Arseni Mourzenko

อีกตัวอย่างที่ดีคือเหตุการณ์ 'โฮเวอร์' ที่มักใช้ในระบบเมนู หลายเมนูเหล่านั้นล้มเหลวอย่างน่าสังเวชกับอุปกรณ์สัมผัส

— Justas

คุณเป็น 110% (หรือมากกว่า) ที่ถูกต้องเกี่ยวกับอุปกรณ์และฉันสามารถให้คุณตัวอย่างที่มีอายุมากกว่าหลายทศวรรษ ย้อนกลับไปในช่วงปลายปี 1980 ฉันทำงานกับแอปพลิเคชั่น CICS ที่ทำงานบนเมนเฟรมของ IBM และเทอร์มินัล 3270 แบบซิงโครนัส ภูมิภาค CICS นั้นคล้ายคลึงกับแอพฝั่งเซิร์ฟเวอร์โดยส่งข้อมูลแบบเต็มหน้าจอไปยังเทอร์มินัลซิงโครนัสซึ่งคล้ายกับเบราว์เซอร์เฉพาะอุปกรณ์ และการเขียนโปรแกรม CICS อาจเป็น 80% Cobol, 20% PL / 1 ทั้งสองภาษาเหล่านี้ส่วนใหญ่ล้าสมัยในปัจจุบันและการปรากฏตัวของเวิร์กสเตชัน Unix (Sun และ Apollo) ในช่วงต้นปี 1990 CICS ถูกฆ่าตายสวยมากทั้งหมด

— John Forkosh

31

คุณไม่ได้วางแผนที่จะมีอายุ 20 ปี เรียบง่าย. แต่คุณเปลี่ยนเป้าหมายเป็นการแบ่งส่วน

ฐานข้อมูลแอปของคุณไม่เชื่อเรื่องพระเจ้าหรือไม่? หากคุณต้องเปลี่ยนฐานข้อมูลตอนนี้ ภาษาตรรกะของคุณไม่เชื่อเรื่องพระเจ้า หากคุณต้องเขียนแอพใหม่ในภาษาใหม่โดยสิ้นเชิงในตอนนี้ได้ไหม คุณทำตามแนวทางการออกแบบที่ดีเช่น SRP และ DRY หรือไม่

ฉันมีโครงการถ่ายทอดสดมานานกว่า 20 ปีแล้วและฉันสามารถบอกคุณได้ว่าสิ่งต่าง ๆ เปลี่ยนแปลง เหมือนป๊อปอัป 20 ปีที่แล้วคุณสามารถพึ่งพาป๊อปอัพวันนี้คุณไม่สามารถ XSS ไม่ใช่สิ่งที่เมื่อ 20 ปีก่อนตอนนี้คุณต้องพิจารณา CORS

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

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

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

— coteyr
แหล่งที่มา

2

"ถ้าคุณต้องเปลี่ยน data-base ตอนนี้คุณช่วยได้ไหม" นี่เป็นไปไม่ได้เลยที่จะทำสำเร็จถ้าคุณทำอะไรมากกว่า CRUD ในแต่ละครั้ง

— jpmc26

1

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

— coteyr

5

และ ORMs จะเป็นเครื่องมือที่ดีมากสำหรับงานเมื่อคุณทำมากกว่า CRUD ง่าย ๆ ในการบันทึกครั้งเดียว นั่นเป็นเหตุผลที่ฉันผ่านการรับรอง ฉันได้ลองแล้ว. เมื่อความซับซ้อนของแบบสอบถามเพิ่มขึ้นแม้แต่ ORM ที่ดีที่สุดก็ยิ่งมีปัญหามากกว่าเพียงแค่เขียนแบบสอบถามและแม้ว่าคุณจะบังคับให้แบบสอบถามของคุณกลายเป็นคุณก็พบว่าตัวเองกำลังใช้คุณสมบัติหรือการปรับแต่งเฉพาะฐานข้อมูลอย่างรวดเร็ว

— jpmc26

1

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

— jpmc26

4

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

— fgp

12

คำตอบของ @amon และคำตอบอื่น ๆ นั้นยอดเยี่ยม แต่ฉันอยากจะแนะนำให้คุณดูจากมุมมองอื่น

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

สถานการณ์ของคุณซับซ้อนเนื่องจากเว็บไซต์หมายความว่าคุณต้องวางแผนสำหรับสองสภาพแวดล้อม - เซิร์ฟเวอร์และเบราว์เซอร์

เมื่อพูดถึงเซิร์ฟเวอร์คุณมีสองตัวเลือกทั่วไป:

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

เมื่อมาถึงเบราว์เซอร์คุณจะต้องโฮสต์ทุกอย่างบนเซิร์ฟเวอร์ (เช่นคุณไม่สามารถใช้ CDN ทั่วโลกเพื่อโฮสต์ไฟล์) เราสามารถสันนิษฐานได้ว่าเบราว์เซอร์ในอนาคตจะยังคงใช้ HTML และ Javascript (อย่างน้อยก็เพื่อความเข้ากันได้) แต่นั่นเป็นการคาดเดา / สันนิษฐานและคุณไม่สามารถควบคุมมันได้

— Jonathan Vanasco
แหล่งที่มา

11

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

หากคุณไปตามเส้นทาง OS ที่ดีที่สุดคุณสามารถหวังได้ว่ามีการใช้แพตช์ความปลอดภัยและผู้ดูแลระบบในอนาคตจะสามารถป้องกันสิ่งต่าง ๆ ได้ที่เลเยอร์เครือข่าย ในการวางแผนสำหรับสิ่งต่าง ๆ ให้ทำงานเช่นนี้ในระยะยาว (โดยไม่ต้องใช้งบประมาณจำนวนมากเนื่องจาก OP เป็นนักเรียน) โดยทั่วไปคุณต้องยอมรับว่าใบสมัครและเซิร์ฟเวอร์ของคุณจะไม่ปลอดภัยในที่สุด ตัวอย่างเช่นใน 20 ปีจะมีการหาช่องโหว่ที่รู้จักสำหรับรุ่น SSL บนเซิร์ฟเวอร์ในที่สุด ... แต่ระบบปฏิบัติการอาจไม่เข้ากันได้กับรุ่น openssl ในระยะเวลา 10 ปี นี่คือทั้งหมดที่เกี่ยวกับการลดการแลกเปลี่ยนให้น้อยที่สุด

— Jonathan Vanasco

@FighterJet คุณสามารถเรียกใช้ไฟร์วอลล์บนระบบปฏิบัติการที่รองรับได้ตลอดเวลาจากนั้นคุณมีความเสี่ยงเพียงเล็กน้อยนอกเหนือจาก SQL injects และอื่น ๆ ที่คุณควรเขียนโปรแกรมไว้

— เอียน

@Ian: ฉันต้องการ มีไฟร์วอลล์ แต่ฉันไม่ได้เขียนรหัสฉันสืบทอดมา และใช่มีช่องโหว่ SQL หลายพันรายการที่ฉันหวังว่าฉันจะแก้ไขได้ แต่ปัญหาที่แท้จริงคือรหัสขึ้นอยู่กับ PHP4 รุ่นใดรุ่นหนึ่ง (ซึ่งเลิกใช้งานไปตลอดกาลและมีช่องโหว่ด้านความปลอดภัย) และ เวอร์ชันเฉพาะของไดรเวอร์ฐานข้อมูล (ซึ่งไม่ได้ทำงานบนระบบปฏิบัติการรุ่นใหม่กว่า) ซึ่งทำให้เราอัปเกรดเป็นฐานข้อมูลเวอร์ชันใหม่กว่า ... ประเด็นคือการพึ่งพาสิ่งที่เหมือนกันไม่ได้ผลเสมอไป สมมุติว่าฉันดีใจที่ฉันไม่ได้ทำงานที่นั่นอีกแล้ว

1

@FighterJet ที่จริงแล้วเป็นตัวอย่างที่ดีมากของสิ่งที่ฉันตั้งใจจะพูดถึง คุณได้รับรหัสที่ใช้งานได้กับ PHP4 รุ่นใดรุ่นหนึ่งเท่านั้นและไดรเวอร์ที่ทำงานบนระบบปฏิบัติการเฉพาะ ... ดังนั้นคุณจึงไม่สามารถอัปเกรดเซิร์ฟเวอร์ได้ ฉันจะไม่สนับสนุนให้ใครทำ แต่จะเกิดขึ้น -- มาก. FWIW ฉันเห็นด้วยกับคุณ แต่ฉันต้องการคำตอบของฉันในการส่งเสริมการคิดเกี่ยวกับสถานการณ์เหล่านั้นไม่ใช่คำแนะนำ

— Jonathan Vanasco

6

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

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

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

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

นอกจากนี้ผมพบว่าบางกองเทคโนโลยีมีเสถียรภาพมากขึ้นกว่าคนอื่น ๆ ฉันจะบอกว่า. NET มีความเข้ากันได้ย้อนหลังที่ดีที่สุดในขณะนี้ Microsoft ตายอย่างจริงจังเกี่ยวกับเรื่องนี้ Java และ C / C ++ มีความเสถียรเช่นกัน Python ได้พิสูจน์แล้วว่ามันไม่เสถียรอย่างมากกับ Python 3 ที่ทำลายการเปลี่ยนแปลง JavaScript ดูเหมือนจริงแล้วค่อนข้างเสถียรสำหรับฉันเนื่องจากการทำลายเว็บไม่ใช่ตัวเลือกสำหรับผู้ขายเบราว์เซอร์ใด ๆ คุณอาจไม่ควรพึ่งพาการทดลองหรือขี้ขลาดอะไร ("Funky" ถูกกำหนดเป็น "ฉันรู้เมื่อเห็น")

— usr
แหล่งที่มา

เกี่ยวกับ. net เรื่องความเข้ากันได้ย้อนหลัง - ฉันไม่คิดว่าฉันเคยเห็นแอป java ที่จะถามจาวาเวอร์ชั่นเก่ากว่า ที่อาจเปลี่ยนแปลงด้วย Java 9 ขึ้นไป แต่ยังไม่เคยเห็นมันเกิดขึ้น

— eis

มันเข้ากันได้อย่างน่าอัศจรรย์ในทางปฏิบัติและการติดตั้งรุ่นที่เก่ากว่าอยู่เคียงข้างกันก็ไม่มีปัญหา นอกจากนี้โปรดทราบว่า. NET BCL อยู่ในช่วงประมาณ 10-100x ซึ่งใหญ่กว่าคลาส Java ในตัว

— usr

ความเข้ากันได้ย้อนหลังหมายความว่าไม่จำเป็นต้องติดตั้งเวอร์ชั่นเก่า แต่เราพูดนอกเรื่องจากคำถามเดิมนี่ไม่เกี่ยวข้องกับ OP จริงๆ

— eis

0

คำตอบอื่น ๆ ที่เหมาะสม อย่างไรก็ตามฉันรู้สึกว่าความคิดเห็นเกี่ยวกับเทคโนโลยีของลูกค้านั้นซับซ้อนเกินความจำเป็น ฉันทำงานเป็นนักพัฒนาซอฟต์แวร์มา 16 ปีแล้ว จากประสบการณ์ของฉันตราบใดที่คุณรักษารหัสลูกค้าไว้ได้อย่างชาญฉลาดคุณก็น่าจะสบายดี ดังนั้นจึงไม่มี "แฮ็ก" ที่มี frames / iframes เป็นต้นใช้เฉพาะฟังก์ชันที่กำหนดไว้อย่างดีในเบราว์เซอร์เท่านั้น

คุณสามารถใช้โหมดความเข้ากันได้ในเบราว์เซอร์เพื่อให้ทำงานได้ตลอดเวลา

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

สรุป: ทำให้มันง่ายและสะอาดและคุณควรจะดี

— Jonathan van de Veen
แหล่งที่มา

1

เฟรมและ iframes ถูกกำหนดไว้อย่างดีในสเป็ค HTML อะไรทำให้ไม่เหมาะสม

— อยากรู้อยากเห็น dannii

3

@curiousdannii: การใช้ iframes ไม่มาก (เฟรมไม่ได้รับการสนับสนุนใน HTML5 อีกต่อไป) เนื่องจากการใช้เฟรมและ iframes เพื่อโหลดเนื้อหาแบบอะซิงโครนัสผ่านสคริปต์ ฯลฯ สามารถใช้งานได้ดีในตอนนี้ แต่จะเสมอ อาจมีการเปลี่ยนแปลงความปลอดภัย

— Jonathan van de Veen

-2

สัจพจน์ไม่กี่:

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

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

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

ตัวอย่างที่แสดงให้เห็น:

C และ C ++ มีมานานแล้ว พวกเขามีการใช้งานในเกือบทุกแพลตฟอร์ม C ++ ยังคงพัฒนาต่อไป แต่คุณสมบัติ "สากล" (ที่มีอยู่ในทุกแพลตฟอร์ม) นั้นค่อนข้างรับประกันได้ว่าจะไม่ถูกคัดค้าน

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

WinTel (Windows / x86) แม้จะเป็นกรรมสิทธิ์ของ Microsoft และ Intel โดยเริ่มต้นจากแพลตฟอร์มที่ไม่เหมาะสม (16 บิตภายใน / 8 บิตภายนอก 8088 เทียบกับ 8088 เทียบกับ Apple Macintosh 32 บิตภายใน / 16 บิตภายนอก 68000) และการกัดเซาะ สำหรับ Apple ในตลาดผู้บริโภคยังคงเป็นตัวเลือกที่แท้จริงสำหรับแพลตฟอร์มธุรกิจ ในช่วงเวลานั้น (25 ปี) ความมุ่งมั่นในการใช้งานร่วมกันได้นั้นมีทั้งการพัฒนาในอนาคตและสร้างแรงบันดาลใจให้กับความมั่นใจว่าสิ่งที่ทำงานบนกล่องเก่าจะยังคงใช้งานได้

ความคิดสุดท้าย

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

— Zenilogix
แหล่งที่มา