Phát triển các ứng dụng web cho tuổi thọ dài (hơn 20 năm)

Tôi hiện đang phát triển một ứng dụng web cho quy hoạch đất đai của chính phủ. Ứng dụng chạy chủ yếu trong trình duyệt, sử dụng ajax để tải và lưu dữ liệu.

Tôi sẽ làm việc phát triển ban đầu, và sau đó tốt nghiệp (đó là công việc của sinh viên). Sau này, phần còn lại của nhóm sẽ thêm tính năng không thường xuyên khi cần thiết. Họ biết cách viết mã, nhưng họ chủ yếu là các chuyên gia quy hoạch đất đai.

Xem xét tốc độ thay đổi công nghệ Javascript, làm cách nào tôi có thể viết mã vẫn hoạt động được 20 năm kể từ bây giờ? Cụ thể, những thư viện, công nghệ và ý tưởng thiết kế nào tôi nên sử dụng (hoặc tránh) để chứng minh mã của mình trong tương lai?

Phần mềm lập kế hoạch cho tuổi thọ như vậy rất khó, bởi vì chúng ta không biết tương lai sẽ ra sao. Một chút bối cảnh: Java đã được xuất bản năm 1995, 21 năm trước. XmlHttpRequest lần đầu tiên có sẵn dưới dạng tiện ích mở rộng độc quyền cho Internet Explorer 5, được xuất bản 1999, 17 năm trước. Phải mất khoảng 5 năm cho đến khi nó có sẵn trên tất cả các trình duyệt chính. 20 năm bạn đang cố gắng nhìn về phía trước chỉ là khoảng thời gian các ứng dụng web phong phú thậm chí còn tồn tại.

Một số điều chắc chắn vẫn giữ nguyên kể từ đó. Đã có một nỗ lực tiêu chuẩn hóa mạnh mẽ, và hầu hết các trình duyệt đều tuân thủ tốt các tiêu chuẩn khác nhau có liên quan. Một trang web hoạt động trên các trình duyệt 15 năm trước vẫn sẽ hoạt động như nhau, miễn là nó hoạt động vì nó nhắm mục tiêu tập hợp con chung của tất cả các trình duyệt, chứ không phải vì nó sử dụng cách giải quyết cho mỗi trình duyệt.

Những thứ khác đến và đi - nổi bật nhất là Flash. Flash có nhiều vấn đề dẫn đến sự sụp đổ của nó. Quan trọng nhất, nó đã được kiểm soát bởi một công ty duy nhất. Thay vì cạnh tranh bên trong nền tảng Flash, đã có sự cạnh tranh giữa Flash và HTML5 - và HTML5 đã giành chiến thắng.

Từ lịch sử này, chúng ta có thể thu thập một vài manh mối:

• Giữ cho nó đơn giản: Làm những gì hoạt động ngay bây giờ, mà không phải sử dụng bất kỳ cách giải quyết. Hành vi này có thể sẽ tồn tại lâu dài trong tương lai vì lý do tương thích ngược.

• Tránh phụ thuộc vào các công nghệ độc quyền, và thích các tiêu chuẩn mở.

Thế giới JavaScript ngày nay tương đối biến động với lượng thư viện và khung công tác cao. Tuy nhiên, gần như không ai trong số họ sẽ quan trọng trong 20 năm - khung duy nhất mà tôi chắc chắn sẽ vẫn được sử dụng trước đó là Vanilla JS .

Nếu bạn muốn sử dụng thư viện hoặc công cụ vì nó thực sự giúp phát triển dễ dàng hơn nhiều, trước tiên hãy đảm bảo rằng nó được xây dựng trên các tiêu chuẩn được hỗ trợ tốt ngày nay. Sau đó, bạn phải tải xuống thư viện hoặc công cụ và bao gồm nó với mã nguồn của bạn. Kho lưu trữ mã của bạn nên bao gồm mọi thứ cần thiết để có được hệ thống có thể chạy được. Bất cứ điều gì bên ngoài là một sự phụ thuộc có thể phá vỡ trong tương lai. Một cách thú vị để kiểm tra điều này là sao chép mã của bạn vào ổ đĩa ngón tay cái, đi đến một máy tính mới có hệ điều hành khác, ngắt kết nối nó khỏi internet và xem liệu bạn có thể làm cho giao diện của mình hoạt động không. Miễn là dự án của bạn bao gồm HTML + CSS + JavaScript đơn giản cộng với có lẽ một số thư viện, bạn có thể sẽ vượt qua.

Điều thậm chí còn quan trọng hơn mã của bạn tồn tại trong 20 năm là dữ liệu của bạn tồn tại trong 20 năm. Rất có thể, đó là điều đáng để bảo tồn. Nếu dữ liệu của bạn dễ làm việc, việc xây dựng một hệ thống thay thế trên đầu trang với công nghệ mới hơn sẽ dễ dàng.

• Vì vậy, bắt đầu với một mô hình dữ liệu rõ ràng và tài liệu tốt.
• Sử dụng một hệ thống cơ sở dữ liệu được thiết lập, được hỗ trợ tốt, chẳng hạn như Oracle ^[1] hoặc SQL Server.
• Sử dụng các tính năng cơ bản, đừng cố gắng sử dụng các tính năng mới.
• Thích đơn giản hơn thông minh .
• Chấp nhận rằng khả năng duy trì trong tương lai có thể phải trả giá bằng các khía cạnh như hiệu suất. Ví dụ, bạn có thể muốn sử dụng các quy trình được lưu trữ, nhưng chúng có thể hạn chế khả năng bảo trì trong tương lai nếu chúng ngăn người khác chuyển hệ thống sang một giải pháp lưu trữ đơn giản hơn.

Khi bạn đã có điều đó, việc chứng minh ứng dụng trong tương lai sẽ đơn giản hơn, bởi vì đó là trình bao bọc xung quanh mô hình dữ liệu và có thể được thay thế nếu trong 10 năm nữa, chẳng ai sử dụng Javascript nữa, và bạn cần di chuyển ứng dụng sang WASM hoặc một cái gì đó. Giữ mọi thứ theo mô-đun, ít phụ thuộc lẫn nhau, cho phép bảo trì dễ dàng hơn trong tương lai.

^[1] Hầu hết các ý kiến ​​cho câu trả lời này đều có lập trường mạnh mẽ chống lại việc sử dụng Oracle cho DB, trích dẫn rất nhiều lý do hoàn toàn chính đáng tại sao Oracle phải chịu khó làm việc, có đường cong học tập dốc và chi phí cài đặt. Đây là những mối quan tâm hoàn toàn hợp lệ khi chọn Oracle làm DB, nhưng trong trường hợp của chúng tôi, chúng tôi không tìm kiếm một DB có mục đích chung, mà một trong những mối quan tâm chính là khả năng duy trì . Oracle đã xuất hiện từ cuối những năm 70 và có thể sẽ được hỗ trợ trong nhiều năm tới, và có một hệ thống tư vấn và lựa chọn hỗ trợ khổng lồ có thể giúp bạn duy trì hoạt động. Đây có phải là một mớ hỗn độn quá cao cho nhiều công ty? Chắc chắn rồi. Nhưng nó sẽ giữ cho cơ sở dữ liệu của bạn chạy trong 20 năm ? Rất có thể.

Câu trả lời trước của amon rất hay, nhưng có hai điểm bổ sung không được đề cập:

• Nó không chỉ là về trình duyệt; thiết bị cũng quan trọng

  amon đã đề cập đến một thực tế rằng một trang web trên mạng đã hoạt động trên các trình duyệt 15 năm trước vẫn sẽ hoạt động giống như vậy , điều này là đúng. Tuy nhiên, hãy nhìn vào các trang web được tạo ra không phải mười lăm, mà là mười năm trước, khi được tạo ra, đã hoạt động trong hầu hết các trình duyệt cho hầu hết người dùng. Ngày nay, một phần lớn người dùng sẽ không thể sử dụng các trang web đó, không phải vì trình duyệt đã thay đổi mà vì các thiết bị đã làm. Các trang web đó sẽ trông khủng khiếp trên màn hình nhỏ của thiết bị di động và cuối cùng không hoạt động nếu các nhà phát triển quyết định dựa vào clicksự kiện JavaScript mà không biết rằng tapsự kiện đó cũng quan trọng.

• Bạn đang tập trung vào một chủ đề sai.

  Thay đổi công nghệ là một chuyện, nhưng một điều quan trọng hơn là những thay đổi của yêu cầu . Sản phẩm có thể cần được thu nhỏ hoặc có thể cần phải có các tính năng bổ sung hoặc có thể cần thay đổi các tính năng hiện tại của sản phẩm.

  Không có vấn đề gì sẽ xảy ra với trình duyệt, hoặc thiết bị, hoặc W3C, hoặc ... bất cứ điều gì.

  Nếu bạn viết mã theo cách có thể tái cấu trúc , sản phẩm sẽ phát triển cùng với công nghệ.

  Nếu bạn viết mã theo cách mà không ai có thể hiểu và duy trì nó, thì công nghệ không thành vấn đề: mọi thay đổi môi trường sẽ khiến ứng dụng của bạn bị hỏng, chẳng hạn như di chuyển sang một hệ điều hành khác, hoặc thậm chí là một điều đơn giản là tăng trưởng dữ liệu tự nhiên .

  Ví dụ, tôi làm việc trong lĩnh vực phát triển phần mềm trong mười năm. Trong số hàng chục và hàng chục dự án, chỉ có hai dự án tôi quyết định thay đổi vì công nghệ , chính xác hơn là vì PHP đã phát triển rất nhiều trong mười năm qua. Thậm chí đó không phải là quyết định của khách hàng: anh ta sẽ không quan tâm nếu trang web sử dụng không gian tên hoặc đóng cửa của PHP. Tuy nhiên, những thay đổi liên quan đến yêu cầu mới và khả năng mở rộng, có rất nhiều!

Bạn không có kế hoạch kéo dài 20 năm. Đơn giản và đơn giản. Thay vào đó, bạn chuyển mục tiêu của mình sang ngăn cách.

Là cơ sở dữ liệu ứng dụng của bạn bất khả tri? Nếu bạn phải chuyển đổi cơ sở dữ liệu ngay bây giờ, bạn có thể. Là ngôn ngữ logic bất khả tri của bạn. Nếu bạn phải viết lại ứng dụng bằng một ngôn ngữ hoàn toàn mới ngay bây giờ, bạn có thể không? Bạn có tuân theo các nguyên tắc thiết kế tốt như SRP và DRY không?

Tôi đã có các dự án sống lâu hơn 20 năm và tôi có thể nói với bạn rằng mọi thứ thay đổi. Giống như cửa sổ bật lên. 20 năm trước bạn có thể dựa vào một cửa sổ bật lên, ngày nay bạn không thể. XSS không phải là một điều 20 năm trước, bây giờ bạn phải tính đến CORS.

Vì vậy, những gì bạn làm là đảm bảo logic của bạn được phân tách độc đáo và bạn tránh sử dụng công nghệ BẤT K that khóa bạn vào một nhà cung cấp cụ thể.

Điều này có thể rất khó khăn đôi khi. Ví dụ, .NET rất tuyệt vời trong việc đưa ra logic và phương thức cho bộ điều hợp cơ sở dữ liệu MSSQL không có tương đương trong các bộ điều hợp khác. MSSQL có vẻ như là một kế hoạch tốt ngày hôm nay nhưng nó sẽ duy trì như vậy trong 20 năm? Ai biết. Một ví dụ về cách vượt qua điều này để có một lớp dữ liệu tách biệt hoàn toàn với các phần khác của ứng dụng. Sau đó, trường hợp xấu nhất, bạn chỉ phải viết lại toàn bộ lớp dữ liệu, phần còn lại của ứng dụng của bạn không bị ảnh hưởng.

Nói cách khác nghĩ về nó giống như một chiếc xe hơi. Xe của bạn sẽ không làm cho nó 20 năm. Nhưng, với lốp mới, động cơ mới, hộp số mới, cửa sổ mới, thiết bị điện tử mới, v.v ... Chiếc xe đó cũng có thể đi trên đường trong một thời gian rất dài.

Câu trả lời của @amon và một số người khác là tuyệt vời, nhưng tôi muốn đề nghị bạn xem xét điều này từ một góc độ khác.

Tôi đã làm việc với các nhà sản xuất lớn và các cơ quan chính phủ, những người đã dựa vào các chương trình hoặc cơ sở mã đã được sử dụng hơn 20 năm và tất cả họ đều có một điểm chung - công ty kiểm soát phần cứng. Có một cái gì đó chạy và có thể mở rộng trong hơn 20 năm không khó khi bạn kiểm soát những gì nó chạy. Các nhân viên tại các nhóm này đã phát triển mã trên các máy hiện đại nhanh hơn hàng trăm lần so với các máy triển khai ... nhưng các máy triển khai đã bị đóng băng kịp thời.

Tình huống của bạn rất phức tạp, bởi vì một trang web có nghĩa là bạn cần lập kế hoạch cho hai môi trường - máy chủ và trình duyệt.

Khi nói đến máy chủ, bạn có hai lựa chọn chung:

• Dựa vào hệ điều hành cho các chức năng hỗ trợ khác nhau có thể nhanh hơn nhiều, nhưng có nghĩa là HĐH có thể cần phải "đóng băng kịp thời". Nếu đó là trường hợp, bạn sẽ muốn chuẩn bị một số bản sao lưu cài đặt hệ điều hành cho máy chủ. Nếu một cái gì đó gặp sự cố trong 10 năm, bạn không muốn làm cho ai đó phát điên khi cố gắng cài đặt lại hệ điều hành hoặc viết lại mã để làm việc trong một môi trường khác.

• Sử dụng các thư viện được phiên bản trong một ngôn ngữ / khung nhất định, chậm hơn, nhưng có thể được đóng gói trong môi trường ảo và có thể chạy trên các hệ điều hành hoặc kiến ​​trúc khác nhau.

Khi nói đến trình duyệt, bạn sẽ cần lưu trữ mọi thứ trên máy chủ (tức là bạn không thể sử dụng CDN toàn cầu để lưu trữ tệp). Chúng tôi có thể giả định rằng các trình duyệt trong tương lai vẫn sẽ chạy HTML và Javascript (ít nhất là để tương thích), nhưng đó thực sự là một phỏng đoán / giả định và bạn không thể kiểm soát điều đó.

Cốt lõi của hầu hết các ứng dụng là dữ liệu. Dữ liệu là mãi mãi. Mã là chi tiêu nhiều hơn , thay đổi, dễ uốn nắn. Các dữ liệu phải được bảo tồn, mặc dù. Vì vậy, tập trung vào việc tạo ra một mô hình dữ liệu thực sự vững chắc. Giữ lược đồ và dữ liệu sạch sẽ. Dự đoán, một ứng dụng mới có thể được xây dựng trên cùng một cơ sở dữ liệu.

Chọn một cơ sở dữ liệu có khả năng thực thi các ràng buộc toàn vẹn. Các ràng buộc không được ràng buộc có xu hướng bị vi phạm khi thời gian trôi qua. Không ai thông báo. Sử dụng tối đa các phương tiện như khóa ngoại, các ràng buộc duy nhất, kiểm tra các ràng buộc và có thể kích hoạt để xác nhận. Có một số thủ thuật để lạm dụng các quan điểm được lập chỉ mục để thực thi các ràng buộc về tính duy nhất của bảng chéo.

Vì vậy, có thể bạn cần chấp nhận rằng ứng dụng sẽ được viết lại vào một lúc nào đó. Nếu cơ sở dữ liệu sạch sẽ sẽ có rất ít công việc di chuyển. Di cư là vô cùng tốn kém về lao động và khiếm khuyết gây ra.

Từ góc độ công nghệ, có thể là một ý tưởng tốt để đặt hầu hết các ứng dụng trên máy chủ chứ không phải ở dạng JavaScript trên máy khách. Có lẽ bạn sẽ có thể chạy cùng một ứng dụng trong cùng một hệ điều hành trong một thời gian cực kỳ dài nhờ ảo hóa . Điều đó không thực sự tốt nhưng nó đảm bảo ứng dụng sẽ hoạt động được 20 năm kể từ bây giờ mà không phải trả bất kỳ chi phí bảo trì và phần cứng đắt đỏ nào. Làm điều này bạn ít nhất có được dự phòng an toàn và rẻ tiền khi tiếp tục chạy mã cũ, hoạt động.

Ngoài ra, tôi thấy rằng một số ngăn xếp công nghệ ổn định hơn những cái khác . Tôi muốn nói rằng .NET có câu chuyện tương thích ngược tốt nhất có thể hiện tại. Microsoft đã chết nghiêm trọng về nó. Java và C / C ++ cũng thực sự ổn định. Python đã chứng minh rằng nó rất không ổn định với các thay đổi phá vỡ Python 3. JavaScript thực sự có vẻ khá ổn định đối với tôi vì phá web không phải là một lựa chọn cho bất kỳ nhà cung cấp trình duyệt nào. Bạn có lẽ không nên dựa vào bất cứ điều gì thử nghiệm hoặc sôi nổi, mặc dù. ("Funky" được định nghĩa là "Tôi biết điều đó khi tôi nhìn thấy nó").

Các câu trả lời khác có ý nghĩa. Tuy nhiên, tôi cảm thấy các ý kiến ​​về công nghệ khách hàng là quá phức tạp. Tôi đã làm việc như một nhà phát triển trong 16 năm qua. Theo kinh nghiệm của tôi, miễn là bạn giữ mã khách hàng của mình trực quan, bạn sẽ ổn thôi. Vì vậy, không có "hack" với khung / iframe, v.v. Chỉ sử dụng các chức năng được xác định rõ trong trình duyệt.

Bạn luôn có thể sử dụng các chế độ tương thích trong trình duyệt để giữ cho chúng hoạt động.

Để chứng minh quan điểm của tôi, chỉ một vài tháng trước, tôi đã sửa một lỗi thiên niên kỷ trong mã javascript cho một khách hàng, người đã chạy ứng dụng web của họ trong 17 năm. Vẫn hoạt động trên các máy gần đây, cơ sở dữ liệu gần đây, hệ điều hành gần đây.

Kết luận: giữ cho nó đơn giản và sạch sẽ và bạn sẽ ổn.

Một vài tiên đề:

• Sự thật tồn tại. Trong bối cảnh này, đó sẽ là các thuật toán và mô hình dữ liệu - mà mô tả trung thực "cái gì" và "cách thức" của không gian vấn đề của bạn. Mặc dù, luôn có tiềm năng để sàng lọc và cải thiện, hoặc một sự tiến hóa của chính vấn đề.
• Ngôn ngữ phát triển. Điều này đúng với ngôn ngữ máy tính cũng như ngôn ngữ tự nhiên.
• Tất cả các công nghệ dễ bị lỗi thời. Nó chỉ có thể mất nhiều thời gian hơn cho một số công nghệ so với những công nghệ khác

Các công nghệ và tiêu chuẩn ổn định nhất (những công nghệ ít bị tổn thương nhất) có xu hướng là những công nghệ không độc quyền và đã được áp dụng rộng rãi nhất. Việc áp dụng càng rộng, quán tính càng lớn đối với hầu hết mọi hình thức thay đổi. "Tiêu chuẩn" độc quyền luôn dễ bị tổn thương trước vận may và ý thích của chủ sở hữu và lực lượng cạnh tranh của họ.

Hai mươi năm là một thời gian rất dài trong ngành công nghiệp máy tính. Năm năm là một mục tiêu thực tế hơn. Trong năm năm tới, toàn bộ vấn đề mà ứng dụng của bạn muốn giải quyết có thể được xác định lại hoàn toàn.

Một vài ví dụ để minh họa:

C và C ++ đã có từ rất lâu. Họ có triển khai trên mọi nền tảng. C ++ tiếp tục phát triển, nhưng các tính năng "phổ quát" (những tính năng có sẵn trên tất cả các nền tảng) được đảm bảo khá nhiều để không bao giờ bị từ chối.

Flash gần như đã trở thành một tiêu chuẩn phổ quát, nhưng nó là độc quyền. Các quyết định của công ty không hỗ trợ nó trên các nền tảng di động phổ biến về cơ bản đã khiến nó bị hủy hoại ở mọi nơi - nếu bạn là tác giả cho web, bạn muốn nội dung của mình có sẵn trên tất cả các nền tảng; bạn không muốn bỏ lỡ thị trường di động lớn đã trở thành.

WinTel (Windows / x86) mặc dù là độc quyền của Microsoft và Intel, nhưng đã bắt đầu trên nền tảng kém tối ưu hơn (16 bit bên trong / 8 bit bên ngoài 8088 so với Apple Macintosh 32 bit bên trong / 16 bit bên ngoài 68000) và xói mòn đối với Apple trong thị trường tiêu dùng vẫn là một lựa chọn thực tế cho các nền tảng kinh doanh. Trong suốt thời gian đó (25 năm), một cam kết về khả năng tương thích ngược đã vừa phát triển trong tương lai vừa truyền cảm hứng cho sự tự tin đáng kể rằng những gì hoạt động trên hộp cũ vẫn sẽ hoạt động trên hộp mới.

Suy nghĩ cuối cùng

JavaScript có thể không phải là lựa chọn tốt nhất để triển khai logic kinh doanh. Vì lý do toàn vẹn và bảo mật dữ liệu, logic nghiệp vụ nên được thực hiện trên máy chủ, do đó, JavaScript phía máy khách nên được giới hạn ở hành vi UI. Ngay cả trên máy chủ, JavaScript có thể không phải là lựa chọn tốt nhất. Mặc dù dễ làm việc hơn các ngăn xếp khác (Java hoặc C #) cho các dự án nhỏ, nhưng nó thiếu tính hình thức có thể giúp bạn viết các giải pháp tốt hơn, có tổ chức hơn khi mọi thứ trở nên phức tạp hơn.