Tư vấn thiết kế ứng dụng web với tuổi thọ hơn 40 năm

Kịch bản

Hiện tại, tôi ngoài một dự án chăm sóc sức khỏe có yêu cầu chính là thu thập dữ liệu với các thuộc tính không xác định bằng cách sử dụng biểu mẫu do người dùng tạo bởi các nhà cung cấp dịch vụ chăm sóc sức khỏe. Yêu cầu thứ hai là tính toàn vẹn dữ liệu là chìa khóa và ứng dụng sẽ được sử dụng trong hơn 40 năm. Chúng tôi hiện đang di chuyển dữ liệu của khách hàng từ 40 năm qua từ nhiều nguồn khác nhau (Paper, Excel, Access, v.v.) sang cơ sở dữ liệu. Yêu cầu trong tương lai là:

• Quản lý quy trình làm việc của các biểu mẫu
• Lịch trình quản lý biểu mẫu
• Quản lý dựa trên bảo mật / vai trò
• Công cụ báo cáo
• Hỗ trợ điện thoại di động / máy tính bảng

Tình hình

Chỉ sau 6 tháng, kiến ​​trúc sư / lập trình viên cao cấp hiện tại đã ký hợp đồng "nhanh" và đã thiết kế một hệ thống kém. Cơ sở dữ liệu không được chuẩn hóa, mã được ghép nối, các tầng không có mục đích chuyên dụng và dữ liệu bắt đầu bị mất do anh ta đã thiết kế một số hạt để thực hiện "xóa" trên cơ sở dữ liệu. Cơ sở mã cực kỳ cồng kềnh và có những công việc chỉ để đồng bộ hóa dữ liệu do cơ sở dữ liệu không được chuẩn hóa. Cách tiếp cận của ông là dựa vào các công việc sao lưu để khôi phục dữ liệu bị thiếu và dường như không tin vào việc bao thanh toán lại.

Sau khi trình bày những phát hiện của tôi với Thủ tướng, kiến ​​trúc sư sẽ bị loại bỏ khi hợp đồng của anh ta kết thúc. Tôi đã được giao nhiệm vụ tái kiến ​​trúc ứng dụng này. Nhóm của tôi bao gồm tôi và một lập trình viên cơ sở. Chúng tôi không có tài nguyên khác. Chúng tôi đã được cấp đóng băng yêu cầu 6 tháng, trong đó chúng tôi có thể tập trung vào việc xây dựng lại hệ thống này.

Tôi đã đề nghị sử dụng một hệ thống CMS như Drupal, nhưng vì lý do chính sách tại tổ chức của khách hàng, hệ thống phải được xây dựng từ đầu.

Đây là lần đầu tiên tôi sẽ thiết kế một hệ thống có tuổi thọ hơn 40. Tôi mới chỉ làm việc với các dự án có tuổi thọ 3-5 năm, vì vậy tình huống này rất mới, nhưng thú vị.

Câu hỏi

• Những cân nhắc thiết kế nào sẽ làm cho hệ thống "bằng chứng trong tương lai" hơn?
• Những câu hỏi nào nên được hỏi cho khách hàng / PM để làm cho hệ thống "bằng chứng trong tương lai" hơn?

Dữ liệu là vua

Tôi nghĩ rằng hơi bất hợp lý khi hy vọng một ứng dụng web vào khoảng năm 2013 sẽ vẫn hoạt động và có thể chạy được vào năm 2053. Công nghệ sẽ thay đổi. Nền tảng sẽ đến và đi. HTML có thể là một bộ nhớ kỳ lạ sau đó. Nhưng dữ liệu của bạn sẽ vẫn còn xung quanh.

Vì vậy, dữ liệu là trọng tâm chính của bạn. Miễn là dữ liệu của bạn vẫn còn, mọi người sẽ có thể thích nghi với bất kỳ công nghệ mới nào xuất hiện. Hãy chắc chắn rằng các lược đồ dữ liệu của bạn được cân nhắc kỹ lưỡng và phù hợp để mở rộng. Hãy dành thời gian của bạn để chỉ ra chúng.

Về các ứng dụng thực tế, công ty của bạn có lẽ đúng ở đây khi có chỉ thị 'xây dựng từ đầu'. Tôi duy trì một vài ứng dụng web hơn 10 năm tuổi và tôi rất vui vì chúng không bị khóa trong các hệ thống CMS thịnh hành năm 2003. Chúng sử dụng các khung rất đơn giản được trồng tại nhà. Tôi nghĩ đối với một cái gì đó như thế này, bạn tốt hơn với một khung rất cơ bản mà bạn tạo ra một cách cụ thể cho các nhu cầu của dự án.

Nhưng thực tế là, sau hơn 40 năm, công ty sẽ (hy vọng) sẽ tạo ra khá nhiều dịch vụ mặt trước và mặt sau để thích ứng với các nền tảng phát triển. Vì vậy, tôi sẽ nhắm mục tiêu trọn đời 5-10 năm cho các ứng dụng dành cho người dùng cá nhân.

Chúng tôi sản xuất phần mềm đã được sử dụng bằng cách trả tiền cho khách hàng trong hơn 20 năm. Các codebase đã tồn tại lâu hơn một số thế hệ công cụ kiểm soát nguồn. Phần mềm của chúng tôi đạt tất cả các điểm đạn của bạn ngoại trừ điều máy tính bảng.

Một số mối quan tâm bao gồm ESIGN và UETA . Luật sư của chúng tôi tin rằng chúng tôi cần giữ hồ sơ điện tử có thể đọc được trong tối thiểu 10 năm. Đối với các tài liệu được giữ lại toàn bộ, bạn nên xem xét PDF / A .

Đối với cơ sở dữ liệu của bạn, đừng quá lo lắng về việc chuẩn hóa. Thay vào đó, bạn nên quan tâm đến việc ghi nhật ký mọi thứ và có các bảng kiểm toán theo dõi các thay đổi / xóa trong dữ liệu. Khi nâng cấp các phiên bản, hãy lên kế hoạch thử nghiệm các phiên bản mới song song để có đủ thời gian để đảm bảo rằng bạn đã di chuyển dữ liệu của mình. Thử nghiệm phiên bản mới này cũng bao gồm các hệ điều hành mới - chúng tôi đã có một số bất ngờ rất khó chịu trong những năm qua. Bảo quản phương tiện cài đặt và khóa cấp phép trong trường hợp cần khôi phục. Kiểm tra sao lưu. Nếu bạn định tuần tự hóa các đối tượng để lưu trữ trong cơ sở dữ liệu, hãy làm như XML thay vì tuần tự hóa được cung cấp bởi khung phát triển của bạn.

Đối với nhân viên của bạn, cơ sở mã dài hạn cần bộ nhớ dài hạn. Lý tưởng nhất là bạn muốn những người xung quanh đã có từ lâu. Nếu điều đó là không thể về mặt thể chế, thì bạn cần ghi lại tất cả mọi thứ trong một cái gì đó như wiki. Và lời khuyên của tôi là một wiki có thể liên kết với hệ thống theo dõi lỗi của bạn.

Đối với cơ sở mã của bạn, hãy đảm bảo bạn có ý kiến ​​trong mã của mình. Di chuyển từ một hệ thống kiểm soát phiên bản này sang hệ thống khác hầu như sẽ luôn mất bình luận đăng ký của bạn. Tôi là một fan hâm mộ của việc đặt tên thử nghiệm đơn vị sau thông số kỹ thuật và số lỗi. Bằng cách đó, nếu bài kiểm tra đơn vị Test_Bug_1235 bị hỏng, thì bạn sẽ biết những gì và nơi để theo dõi những gì được cho là đang kiểm tra. Nó không "gợi cảm" như đặt tên cho các thử nghiệm của bạn Check_File_Save_Networked_Drivesnhưng loại thử nghiệm đó khó có thể quay lại các thông số kỹ thuật, yêu cầu hoặc lỗi không giống như Test_requirement_54321_case_2.

Thay vì cố gắng tìm hiểu ứng dụng này sẽ còn hoạt động như thế nào sau 20 năm nữa, tôi nghĩ bạn nên dành sáu tháng để khắc phục các sự cố mà bạn thấy rằng kiến ​​trúc sư ban đầu đã gây ra, đặt một kiến ​​trúc hợp lý, mạnh mẽ và tiến lên từ đó

Việc không chuẩn hóa một phần cơ sở dữ liệu không nhất thiết là hoàn toàn bất ngờ trong môi trường y tế. Một số phần của cơ sở dữ liệu y tế có các đặc điểm khiến chúng phù hợp với mô hình EAV (Thực thể / Thuộc tính / Giá trị) .

Trả lời từ góc độ phía trước:

Đừng nghe mọi người nói rằng điều đó không thể thực hiện được, bởi vì một dịch vụ web thử nghiệm của Đại học bang San Francisco mà tôi đã viết vào năm 1996 cuối cùng đã lên thiên đường Internet vài năm trước và không bao giờ cần một bản sửa lỗi tương thích trình duyệt trong thời gian đó ; đó là gần một nửa mục tiêu 40 năm của bạn. Và giao diện người dùng dựa trên JavaScript này tôi đã thực hiện vào năm 1998 cho một dự án của Viện nghiên cứu Stanford đã được thay thế bằng một thứ gì đó chớp nhoáng hơn một vài năm sau đó, nhưng không có lý do gì mà giao diện người dùng ban đầu vẫn không thể chạy được với các bản sửa lỗi tương thích nhỏ.

Mẹo nhỏ là đảm bảo ứng dụng của bạn chỉ sử dụng các tiêu chuẩn W3C / ECMA được hỗ trợ rộng rãi và có thiết kế rõ ràng dưới sự kiểm soát của bạn. Mặc dù rất nhiều ứng dụng web được viết cho công nghệ thời thượng của thập niên 90 sẽ không hoạt động tốt hoặc hoàn toàn không có ngày nay, các ứng dụng web có từ thời 90 được viết theo các tiêu chuẩn chính vẫn còn. Họ có thể trông bị động, nhưng họ làm việc.

Mục tiêu ở đây không phải là viết một ứng dụng web sẽ xuất hiện trên máy chủ của họ và tồn tại ở đó trong 40 năm mà không có ai chạm vào nó nữa. Đó là để xây dựng một nền tảng vẫn có thể được sử dụng trong nhiều thập kỷ, có thể phát triển để hỗ trợ các tính năng mới mà không phải xây dựng lại từ đầu.

Trước hết, bạn phải viết mã theo tiêu chuẩn chính thức và chỉ theo tiêu chuẩn chính thức. Không có tính năng JavaScript nào không phải là một phần của tiêu chuẩn ECMAScript đã được phê chuẩn; ES5.1 là phiên bản hiện tại và thường được hỗ trợ để nhắm mục tiêu an toàn. Tương tự, các phiên bản hiện tại của HTML5, CSS và Unicode đều tốt. Không có tính năng JavaScript, CSS3 hoặc HTML thử nghiệm (những tính năng có tiền tố nhà cung cấp hoặc không có thỏa thuận 100% giữa các trình duyệt). Và không có hack tương thích trình duyệt cụ thể. Bạn có thể bắt đầu sử dụng một tính năng mới một khi nó có trong tiêu chuẩn và mọi người đều hỗ trợ nó mà không cần tiền tố.

Hỗ trợ ES5 có nghĩa là bỏ IE8 hoặc sớm hơn, điều mà tôi đề xuất dù sao đi nữa vì nó yêu cầu các bản hack dành riêng cho trình duyệt sẽ vô dụng trong một vài năm. Tôi đề nghị Chế độ nghiêm ngặt của ES5 để có cơ hội tốt nhất về tuổi thọ, điều này thực sự đặt khả năng tương thích trình duyệt cơ bản của bạn tại IE10 và các phiên bản gần đây của mọi người khác . Các trình duyệt này cũng có hỗ trợ riêng cho nhiều tính năng xác thực mẫu và giữ chỗ của HTML5, sẽ hữu ích trong một thời gian rất dài.

Các phiên bản mới của ECMAScript duy trì khả năng tương thích với các phiên bản cũ hơn, do đó việc áp dụng các tính năng sắp tới sẽ dễ dàng hơn nhiều nếu mã của bạn được viết theo các tiêu chuẩn hiện hành. Ví dụ, các lớp được xác định bằng classcú pháp sắp tới sẽ có thể hoán đổi hoàn toàn với các lớp được xác định bằng constructor.prototypecú pháp hiện tại . Vì vậy, trong năm năm, một nhà phát triển có thể viết lại các lớp thành định dạng ES6 trên cơ sở từng tệp mà không vi phạm bất cứ điều gì - tất nhiên, giả sử rằng bạn cũng có các bài kiểm tra đơn vị tốt.

Thứ hai, tránh các khung ứng dụng JavaScript hợp thời trang, đặc biệt nếu chúng thay đổi cách bạn mã hóa ứng dụng của mình. Xương sống là tất cả các cơn thịnh nộ, sau đó SproutCore và Ember, và bây giờ Angular là khuôn khổ mà mọi người yêu thích để thúc đẩy. Chúng có thể hữu ích, nhưng chúng cũng có một điểm chung: chúng thường phá vỡ các ứng dụng và yêu cầu thay đổi mã khi các phiên bản mới xuất hiện và tuổi thọ của chúng là nghi vấn. Gần đây tôi đã cập nhật một ứng dụng Angular 1.1 lên 1.2 và khá nhiều thứ phải viết lại. Tương tự như vậy, đi từ Backbone 2 đến 3 đòi hỏi rất nhiều thay đổi HTML. Các tiêu chuẩn chuyển động chậm vì một lý do, nhưng các khung này di chuyển nhanh và những thứ phá vỡ định kỳ là chi phí.

Thêm vào đó, các tiêu chuẩn chính thức mới thường khiến các khung cũ bị lỗi thời và khi điều đó xảy ra, các khung đó sẽ bị đột biến (với các thay đổi vi phạm) hoặc bị bỏ lại phía sau. Bạn có biết điều gì sẽ xảy ra với tất cả các thư viện hứa hẹn cạnh tranh trên thế giới sau khi ECMAScript 6 được phê chuẩn và tất cả các trình duyệt đều hỗ trợ lớp Promise được tiêu chuẩn hóa của nó không? Họ sẽ trở nên lỗi thời và các nhà phát triển của họ sẽ ngừng cập nhật chúng. Nếu bạn chọn đúng khung, mã của bạn có thể thích nghi đủ tốt và nếu bạn đoán kém, bạn sẽ xem xét một cấu trúc lại chính.

Vì vậy, nếu bạn đang nghĩ đến việc áp dụng thư viện hoặc khung của bên thứ ba, hãy tự hỏi bản thân sẽ khó xóa như thế nào trong tương lai. Nếu đó là một khung như Angular không thể bị xóa mà không xây dựng lại ứng dụng của bạn từ đầu, thì đó là một dấu hiệu tốt, nó không thể được sử dụng trong kiến ​​trúc 40 năm. Nếu đó là tiện ích lịch của bên thứ ba mà bạn đã trừu tượng hóa với một số phần mềm trung gian tùy chỉnh, việc thay thế nó sẽ mất vài giờ.

Thứ ba, cung cấp cho nó một cấu trúc ứng dụng tốt, sạch sẽ. Ngay cả khi bạn không sử dụng khung ứng dụng, bạn vẫn có thể tận dụng các công cụ dành cho nhà phát triển, xây dựng tập lệnh và thiết kế sạch sẽ. Cá nhân tôi là một fan hâm mộ của quản lý phụ thuộc của Bộ công cụ đóng cửa vì nó nhẹ và chi phí hoàn toàn bị loại bỏ khi xây dựng ứng dụng của bạn. LessCSS và SCSS cũng là những công cụ tuyệt vời để tổ chức các bảng định kiểu của bạn và xây dựng các bảng định kiểu CSS dựa trên tiêu chuẩn để phát hành.

Bạn cũng có thể tổ chức mã của riêng mình thành các lớp sử dụng một lần với cấu trúc MVC. Điều đó sẽ giúp việc trở lại tương lai dễ dàng hơn nhiều trong tương lai và biết bạn đang nghĩ gì khi bạn viết một cái gì đó, và chỉ thay thế những phần cần nó.

Bạn cũng nên làm theo lời khuyên của W3C và giữ thông tin trình bày hoàn toàn khỏi HTML của bạn. . đến các nền tảng mới trong tương lai. Cũng sẽ dễ dàng hơn để thêm hỗ trợ cho các trình duyệt chuyên dụng cho người mù hoặc người khuyết tật.

Thứ tư, tự động hóa các bài kiểm tra của bạn và đảm bảo bạn có phạm vi bảo hiểm gần đầy. Viết các bài kiểm tra đơn vị cho mọi lớp, cho dù phía máy chủ hoặc bằng JavaScript. Ở mặt trước, đảm bảo mỗi lớp thực hiện theo thông số kỹ thuật của nó trong mọi trình duyệt được hỗ trợ. Tự động hóa các thử nghiệm này từ bot xây dựng của bạn cho mỗi cam kết. Điều này rất quan trọng đối với cả tuổi thọ và độ tin cậy, vì bạn có thể bắt lỗi sớm ngay cả khi các trình duyệt hiện tại che khuất chúng. Cả hai khung thử nghiệm dựa trên JSUnit của Jasmine và Google Clos đều tốt.

Bạn cũng sẽ muốn chạy các bài kiểm tra chức năng UI đầy đủ, mà Selenium / WebDriver rất giỏi. Về cơ bản, bạn viết một chương trình bước qua UI của bạn và sử dụng nó như thể một người đang thử nghiệm nó. Dây những người lên đến bot xây dựng là tốt.

Cuối cùng, như những người khác đã đề cập dữ liệu của bạn là vua. Hãy suy nghĩ thông qua mô hình lưu trữ dữ liệu của bạn và đảm bảo rằng nó được xây dựng để tồn tại. Đảm bảo rằng lược đồ dữ liệu của bạn là vững chắc và đảm bảo rằng nó đã được kiểm tra kỹ lưỡng trên mỗi cam kết. Và chắc chắn rằng kiến ​​trúc máy chủ của bạn có thể mở rộng. Điều này thậm chí còn quan trọng hơn bất cứ điều gì bạn làm ở mặt trước.

Bỏ qua các vấn đề về những kỳ vọng không hợp lý của khách hàng của bạn và tập trung vào các vấn đề thiết kế, tôi sẽ không đi xa tới 40 năm, nhưng vấn đề mà bạn dường như có, về khả năng phát triển lâu dài, chính xác là những gì REST tạo ra . Điều đó thực sự có nghĩa là REST là một phong cách kiến ​​trúc, không phải là sự phát triển theo hướng từ thông dụng thường được liên kết với thuật ngữ ngày nay.

Ở một mức độ nào đó, mọi người hiểu REST vì tôi không bao gồm đủ chi tiết về thiết kế loại phương tiện trong luận án của mình. Đó là vì tôi đã hết thời gian, không phải vì tôi nghĩ nó không quan trọng bằng các khía cạnh khác của REST. Tương tự như vậy, tôi nghi ngờ rất nhiều người hiểu sai vì họ chỉ đọc mục Wikipedia về chủ đề này, không dựa trên các nguồn có thẩm quyền.

Tuy nhiên, tôi nghĩ rằng hầu hết mọi người chỉ phạm sai lầm rằng nó nên đơn giản để thiết kế những thứ đơn giản. Trong thực tế, nỗ lực cần thiết để thiết kế một cái gì đó tỷ lệ nghịch với sự đơn giản của kết quả. Theo phong cách kiến ​​trúc, REST rất đơn giản.

REST là thiết kế phần mềm trên quy mô hàng thập kỷ : mọi chi tiết đều nhằm thúc đẩy tuổi thọ phần mềm và tiến hóa độc lập.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Bạn đã đề cập rằng bạn có ý định sử dụng giao diện RESTful. Nhận xét đó tự nó cho thấy bạn nên thực hiện một số nghiên cứu nghiêm túc về điều đó và cố gắng hiểu REST thực sự là về cái gì. Có lẽ bạn chỉ liên kết nó với việc ánh xạ các phương thức HTTP sang các hoạt động CRUD mà hầu hết mọi người nghĩ REST là, nhưng nó không liên quan gì đến điều đó.

Hãy nghĩ về REST như một sự chính thức hóa kiến ​​trúc của chính web. Bằng cách này hay cách khác, có nhiều phần của web được viết cách đây một thập kỷ hoặc nhiều hơn vẫn có sẵn và có thể được sử dụng với một khách hàng được thực hiện ngày hôm nay, vì vậy chúng tôi có một cái gì đó ngay trong bộ phận đó. Nó sẽ là rất nhiều công việc, tôi đảm bảo với bạn, bởi vì làm REST đúng là khó, nhưng lợi ích lâu dài là xứng đáng.

Sau khi tôi đọc câu hỏi và các câu trả lời khác (được suy nghĩ rất kỹ), tôi đã nghĩ rằng mình cũng sẽ để lại hai xu của mình. Lưu ý: Tôi không phải duy trì bất kỳ ứng dụng / phần mềm thực sự cũ nào cả. Những gì tôi sử dụng làm tài liệu tham khảo là ứng dụng web sở thích đang tiến hành của riêng tôi, lấy một số dữ liệu chính phủ mở, phân tích cú pháp và hiển thị nó ở các định dạng khác nhau. Ứng dụng bắt đầu như một dự án mà tôi không đơn độc và chính phủ đã thông báo rằng họ sẽ cung cấp dữ liệu này vào lúc nào đó. Vì vậy, rõ ràng là rất nhiều thứ sẽ thay đổi theo thời gian. Và họ đã làm. Những gì tôi học được từ nó:

• Chia nhỏ mọi thứ trong các ứng dụng nhỏ. Mỗi người hoàn toàn có thể tự hoàn thành nhiệm vụ của mình. Điều này làm cho việc chuyển ra một mảnh rất nhanh, rất an toàn và rất dễ dàng. Và khi bạn phải quay trở lại, thực sự không khó để hiểu được lý do tại sao mọi thứ xảy ra và cách bạn xảy ra. Nếu bạn hoặc ai đó sẽ phải thay đổi một cái gì đó sau này, việc thay thế một bộ phận sẽ dễ dàng hơn so với toàn bộ mọi thứ.
• Nhận một phần mềm trung gian / lớp đơn liên tục được sử dụng để liên lạc giữa các phần khác nhau. Trong trường hợp này tôi đã sử dụng JSON, nhưng XML, ini hoặc các tiêu chuẩn tương tự cũng sẽ ổn. Thật dễ dàng để lặp lại và có thể biến thành gần như mọi thứ. Tất cả đều được chứng minh là tiêu chuẩn sẽ tồn tại khá lâu. Ngay cả khi dữ liệu cơ bản và / hoặc mô hình lưu trữ sẽ thay đổi. Mỗi ứng dụng có thể sử dụng lưu trữ dữ liệu của riêng họ cho nhiệm vụ cụ thể của nó. Điều này làm cho lượng dữ liệu được quét cho một tác vụ nhỏ hơn, do đó dễ xử lý và bảo trì hơn và dễ trao đổi hơn.
• Đừng lo lắng về các quyết định ngôn ngữ lập trình. Những người sẽ thay đổi theo thời gian. Chỉ cần đảm bảo rằng bạn sử dụng ngôn ngữ mà bạn thấy thoải mái hoặc phù hợp nhất với nhiệm vụ.
• Đảm bảo rằng bộ lưu trữ dữ liệu của bạn "có thể mở rộng theo chiều ngang" và thật dễ dàng để cắm thêm các mô-đun lưu trữ.
• Lấy một điểm chung (trong trường hợp của tôi là URI) trong đó các ứng dụng nhỏ được gọi và / hoặc trao đổi dữ liệu.

Tóm tắt: Điều tôi quan tâm nhất là sự phân tách mối quan tâm và khả năng trao đổi của các bộ phận được phân công cho các nhiệm vụ. Bạn chỉ cần biết rằng trong 40 năm (thậm chí trong 5 hoặc 10) phần cứng, giao diện, lưu trữ, v.v ... sẽ thay đổi rất nhiều. Và các nhà phát triển sau này sẽ phải phản ứng với những thay đổi đó và trao đổi các phần trong ứng dụng của bạn, có thể là bộ chứa dữ liệu hoặc các bộ phận của Giao diện người dùng.

Để làm cho mọi thứ càng "bằng chứng trong tương lai" càng tốt, hãy lên kế hoạch thay đổi. Đó là, cố gắng hết sức để không tối ưu hóa cho bất cứ điều gì khác ngoài khả năng dễ dàng thay đổi. Vì vậy, không bình thường hóa, không xác nhận nghiêm ngặt, và galore khớp nối lỏng lẻo.

• Sử dụng các công nghệ nguồn mở lớn. Đối với dữ liệu, các hệ thống nguồn đóng là một nguồn rủi ro chính vì người ta không thể lên kế hoạch cho các công ty sẽ thực hiện hoặc thay đổi chiến lược, với tất cả quyền truy cập vào dữ liệu. Ngoài ra, các dự án nguồn mở nhỏ không có cộng đồng sôi động cũng có nhiều khả năng mất hỗ trợ.

• Sử dụng cơ sở dữ liệu NoQuery không có lược đồ. Các loại dữ liệu phi cấu trúc đang được sử dụng gần như không có trong sách giáo khoa cho một kho lưu trữ tài liệu như MongoDB. Cơ sở dữ liệu quan hệ truyền thống và chuẩn hóa của chúng là tốt khi bạn biết dữ liệu của mình sẽ được cấu trúc như thế nào, nhưng đó thực sự là một hư cấu, đặc biệt là ở đây. Chi phí thay đổi lược đồ trong RDBS sẽ ngày càng lớn hơn khi hệ thống mở rộng. Biết rằng bất cứ cấu trúc nào được chọn bây giờ sẽ kết thúc thay đổi.

• Tách rời hệ thống sử dụng nhiều tiêu chuẩn được chấp nhận rộng rãi. Phá vỡ tất cả các truy cập dữ liệu và đột biến vào các dịch vụ web là một bước hướng tới điều này. Kết hợp điều đó với hàng đợi tin nhắn để gửi thay đổi và như vậy sẽ giúp các bộ phận riêng lẻ của hệ thống thay đổi ngôn ngữ hoặc công nghệ theo thời gian.

OK, vì vậy tôi sẽ nói một số điều ở đây có lẽ sẽ khá phổ biến, nhưng hãy gắn bó với tôi ở đây.

Vì đây là dự án đầu tiên của bạn, nơi dữ liệu và / hoặc ứng dụng được cho là tồn tại hơn 20 năm và bạn là người dẫn dắt dự án, bạn cần lùi lại một bước và suy nghĩ về tỷ lệ thành công của dự án này là gì . Bởi vì chúng cơ bản là bên cạnh số không.

Bạn cần dành một lượng lớn thời gian tập trung vào thiết kế cơ sở dữ liệu và làm cho đúng. Để dự án này thành công, bạn cần đưa một kiến ​​trúc sư dữ liệu vào dự án, và sớm hơn là sau đó. Không có ai có kinh nghiệm trong thiết kế cơ sở dữ liệu và là người thực hành tốt trong việc mong đợi làm thế nào dữ liệu có thể được sử dụng trong tương lai, tỷ lệ của dữ liệu vẫn còn hữu ích sau 5 năm ít hơn 40 năm là không có gì.

Mong đợi hai người (một trong số họ có danh hiệu là nhà phát triển) xây dựng một cái gì đó từ đầu dự kiến ​​kéo dài 40 năm, có lẽ sẽ không thành công. Cần có một đội ngũ nhiều người có kinh nghiệm làm việc với các dự án lớn như thế này, những người đang làm việc về thiết kế dữ liệu, thiết kế API và thiết kế ứng dụng. Một cái gì đó như thế này không phải là một dự án 2 người.

Muốn gắn kết dự án với một cái gì đó như Drupal cho thấy lý do tại sao dự án cần những người đã quen làm việc với các loại dự án này. Bạn không muốn buộc ứng dụng vào bất cứ thứ gì có thể lỗi mốt chỉ trong vài năm. Nếu bạn đã làm như vậy, việc tìm ai đó để làm việc trên hệ thống trong 5-10 năm có thể rất khó khăn rất nhanh.

Tôi sẽ đưa lời khuyên này cho quản lý và giải thích với họ rằng bạn cần có thêm người cao cấp trong dự án. Nếu không, dự án sẽ thất bại, và có lẽ cuối cùng bạn sẽ là người chịu trách nhiệm cho nó.

Ứng dụng này không cần tồn tại 40 năm mà không có bất kỳ sự tiến hóa nào. Nhưng, bởi vì nó sẽ hoặc nên được xây dựng từ đầu, nó vẫn có thể là 'hoạt động'.

Điều quan trọng nhất là "kiến trúc dữ liệu" cho phép sự ổn định và quản trị cũng như có thể mở rộng.

Chúng tôi đã thiết kế kiến ​​trúc dữ liệu và phân loại gần như có thể tồn tại đến tận cùng của nhân loại nhưng vẫn có thể mở rộng. Bạn đã tìm thấy một người KIẾN TRÚC DỮ LIỆU / KIẾN TRÚC DỮ LIỆU thực sự để làm việc này cho bạn.

Chìa khóa ở đây là tập trung vào cơ sở dữ liệu (như một số điều đã nói ở trên). Điều này cần phải được mạch lạc và mô tả đầy đủ các hoạt động. Nó cần phải phát triển với các hoạt động khi nó thay đổi. Nếu không dễ thay đổi thì nó sẽ hết hạn và đó là nụ hôn của thần chết. Phần còn lại tương đối ít quan trọng.

Tôi không đồng ý với những người ở trên, những người đề nghị bình thường hóa không quan trọng, mặc dù luôn có những trường hợp các hệ thống hiện tại không phù hợp với công việc. Trong những trường hợp này không chuẩn hóa nhưng đảm bảo cơ sở dữ liệu xử lý việc ghi / thay đổi thêm như là một phần của giao dịch nguyên tử. Bằng cách đó bạn có thể bỏ qua vấn đề một cách hiệu quả cho đến khi bạn có thể khắc phục nó.

Công ty tôi làm việc trước khi nghỉ hưu đang điều hành một hệ thống được viết từ đầu và đã phát triển gần như liên tục trong 25 năm, và bao gồm hầu như tất cả các khía cạnh của một nhà bán lẻ vừa. Các khía cạnh của hệ thống này mà tôi cảm thấy quan trọng là:

• Tích hợp là rất quan trọng.
• Cơ sở dữ liệu cần phải chính xác và dễ hiểu đối với cả nhân viên CNTT và các nhân viên khác, vì vậy cần phải có sự nhấn mạnh gần như hoang tưởng vào việc đặt tên. Chúng tôi có các bảng ghi nhớ được xác định, sau đó được kết hợp để tạo thành tên bảng và trường và tất cả các mã mã hóa, tên được đặt tên tương tự như các hằng số và được lưu trữ trong cấu trúc bảng EAV.
• Chúng tôi gói gọn logic kinh doanh vào các kích hoạt cơ sở dữ liệu. Điều này ban đầu rất khó khăn và đòi hỏi công việc bổ sung để truyền thông báo lỗi đến máy khách và cho phép thay đổi linh hoạt mà không khóa toàn bộ bảng trên một số hệ thống, nhưng điều này nhanh chóng trở thành một trình tiết kiệm thời gian lớn và buộc cơ sở dữ liệu phải chính xác hơn nhiều hơn khác
• Giả sử bạn sẽ giữ ít nhất các bảng tham chiếu (lý tưởng nhất là tất cả các giao dịch nhanh nhất và ít quan trọng nhất) cho vòng đời của hệ thống, ngay cả khi đã xóa xóa vì vậy các tham chiếu của bạn là chính xác.
• Bởi vì ở trên, đảm bảo bất kỳ số nhận dạng và số giao dịch duy nhất nào có kích thước dài hạn. (Ban đầu tôi nói đùa rằng họ cần phải kéo dài cho đến khi tôi nghỉ hưu).

Tôi sẽ đề nghị sử dụng tìm nguồn cung ứng sự kiện và phân tách trách nhiệm truy vấn . Điều này chủ yếu là vì điều duy nhất mà bạn có thể chắc chắn là các sự kiện đã xuất hiện. Các loại sự kiện mới có thể đến. Vì vậy, ngay cả khi bạn đặt những suy nghĩ nặng nề lên một mô hình, chắc chắn rằng điều này sẽ trở nên lỗi thời. Di chuyển tất cả dữ liệu với mỗi bản phát hành có thể không khả thi. Vì vậy, tốt nhất là có một mô hình phù hợp với nhu cầu hiện tại của bạn và được tính toán từ các sự kiện đã được ghi lại mỗi khi bạn cần và sau đó loại bỏ các sự kiện được tính từ trạng thái hiện tại của mô hình đó.

Cũng có thử nghiệm trong tâm trí. Nếu ứng dụng được sử dụng trong mười năm kể từ bây giờ, người kiểm tra phải đảm bảo rằng nó vẫn đang làm những gì nó phải làm. Vì vậy, làm cho thử nghiệm tích hợp ứng dụng của bạn dễ dàng nhất có thể.