Việc chia một ứng dụng nguyên khối có khả năng thành nhiều ứng dụng nhỏ hơn có giúp ngăn ngừa lỗi không? [đóng cửa]

Một cách khác để hỏi điều này là; Tại sao các chương trình có xu hướng nguyên khối?

Tôi đang nghĩ về một cái gì đó giống như một gói hoạt hình như Maya, mà mọi người sử dụng cho các quy trình công việc khác nhau.

Nếu các khả năng hoạt hình và mô hình hóa được tách thành ứng dụng riêng của chúng và được phát triển riêng, với các tệp được truyền giữa chúng, chúng sẽ không dễ bảo trì hơn?

Đúng. Nói chung, hai ứng dụng nhỏ hơn ít phức tạp sẽ dễ bảo trì hơn nhiều so với một ứng dụng lớn.

Tuy nhiên, bạn gặp một loại lỗi mới khi tất cả các ứng dụng hoạt động cùng nhau để đạt được mục tiêu. Để làm cho chúng hoạt động cùng nhau, chúng phải trao đổi thông điệp và sự phối hợp này có thể sai theo nhiều cách khác nhau, mặc dù mọi ứng dụng có thể hoạt động hoàn hảo. Có một triệu ứng dụng nhỏ có vấn đề đặc biệt của riêng mình.

Một ứng dụng nguyên khối thực sự là tùy chọn mặc định mà bạn kết thúc khi bạn thêm nhiều tính năng hơn vào một ứng dụng. Đó là cách tiếp cận dễ nhất khi bạn xem xét từng tính năng của riêng mình. Chỉ khi nó phát triển lớn, bạn mới có thể nhìn tổng thể và nói "bạn biết gì không, điều này sẽ hoạt động tốt hơn nếu chúng ta tách ra X và Y".

Việc chia một ứng dụng nguyên khối có khả năng thành nhiều ứng dụng nhỏ hơn có giúp ngăn ngừa lỗi không

Mọi thứ hiếm khi đơn giản trong thực tế.

Chia tách chắc chắn không giúp ngăn chặn những lỗi đó ngay từ đầu. Nó đôi khi có thể giúp tìm lỗi nhanh hơn. Một ứng dụng bao gồm các thành phần nhỏ, tách biệt có thể cho phép nhiều thử nghiệm riêng lẻ hơn (loại "đơn vị" -) cho các thành phần đó, điều này đôi khi có thể dễ dàng phát hiện ra nguyên nhân gốc của một số lỗi nhất định và do đó cho phép nó khắc phục chúng nhanh hơn.

Tuy nhiên,

• ngay cả một ứng dụng dường như nguyên khối từ bên ngoài cũng có thể bao gồm rất nhiều thành phần có thể kiểm tra đơn vị bên trong, do đó, kiểm tra đơn vị không nhất thiết khó hơn đối với ứng dụng nguyên khối

• như Ewan đã đề cập, sự tương tác của một số thành phần giới thiệu các rủi ro và lỗi bổ sung. Và gỡ lỗi một hệ thống ứng dụng với giao tiếp liên tiến trình phức tạp có thể khó hơn đáng kể so với gỡ lỗi một ứng dụng xử lý đơn

Điều này cũng phụ thuộc rất nhiều vào việc một ứng dụng lớn hơn có thể phân chia thành các thành phần tốt như thế nào và mức độ rộng của các giao diện giữa các thành phần và cách các giao diện đó được sử dụng.

Nói tóm lại, đây thường là một sự đánh đổi và không có gì mà câu trả lời "có" hoặc "không" nói chung là chính xác.

Tại sao các chương trình có xu hướng nguyên khối

Họ có làm không? Nhìn xung quanh bạn, có rất nhiều ứng dụng web trên thế giới trông không nguyên khối đối với tôi, hoàn toàn ngược lại. Ngoài ra còn có rất nhiều chương trình có sẵn cung cấp mô hình plugin (AFAIK ngay cả phần mềm Maya mà bạn đề cập).

họ sẽ không dễ dàng hơn để duy trì

"Bảo trì dễ dàng hơn" ở đây thường xuất phát từ thực tế là các phần khác nhau của ứng dụng có thể được phát triển dễ dàng hơn bởi các nhóm khác nhau, do đó khối lượng công việc phân tán tốt hơn, các nhóm chuyên ngành có trọng tâm rõ ràng hơn và trên.

Tôi sẽ không đồng ý với đa số về điều này. Việc tách một ứng dụng thành hai phần riêng biệt không tự nó làm cho mã dễ dàng hơn để duy trì hoặc lý do.

Việc tách mã thành hai tệp thực thi chỉ làm thay đổi cấu trúc vật lý của mã, nhưng đó không phải là điều quan trọng. Điều quyết định mức độ phức tạp của một ứng dụng, là mức độ kết hợp chặt chẽ giữa các phần khác nhau tạo nên nó. Đây không phải là một tài sản vật lý, mà là một tài sản hợp lý .

Bạn có thể có một ứng dụng nguyên khối có sự phân tách rõ ràng giữa các mối quan tâm khác nhau và các giao diện đơn giản. Bạn có thể có một kiến ​​trúc microservice dựa trên các chi tiết triển khai của các dịch vụ siêu nhỏ khác và được kết hợp chặt chẽ với tất cả các dịch vụ khác.

Điều đúng là quá trình phân tách một ứng dụng lớn thành các ứng dụng nhỏ hơn, rất hữu ích khi cố gắng thiết lập các giao diện và yêu cầu rõ ràng cho từng phần. Trong DDD, điều đó sẽ xảy ra với bối cảnh bị ràng buộc của bạn. Nhưng cho dù sau đó bạn tạo ra nhiều ứng dụng nhỏ hay một ứng dụng lớn có cùng cấu trúc logic thì đó là một quyết định kỹ thuật.

Dễ dàng hơn để duy trì một khi bạn đã hoàn thành việc tách chúng, vâng. Nhưng chia tách chúng không phải lúc nào cũng dễ dàng. Cố gắng tách một phần của chương trình thành một thư viện có thể sử dụng lại cho thấy các nhà phát triển ban đầu không nghĩ đến nơi các đường nối nên ở đâu. Nếu một phần của ứng dụng tiếp cận sâu vào một phần khác của ứng dụng, có thể khó khắc phục. Việc trích xuất các đường nối buộc bạn phải xác định các API bên trong rõ ràng hơn và đây là điều cuối cùng làm cho cơ sở mã dễ bảo trì hơn. Khả năng tái sử dụng và bảo trì là cả hai sản phẩm của các đường nối được xác định rõ.

Điều quan trọng cần nhớ là sự tương quan không phải là quan hệ nhân quả.

Xây dựng một khối nguyên khối lớn và sau đó tách nó thành nhiều phần nhỏ có thể hoặc không thể dẫn đến một thiết kế tốt. (Nó có thể cải thiện thiết kế, nhưng nó không được đảm bảo.)

Nhưng một thiết kế tốt thường dẫn đến một hệ thống được xây dựng thành nhiều phần nhỏ thay vì nguyên khối lớn. (Một tảng đá nguyên khối có thể là thiết kế tốt nhất, nó ít có khả năng hơn.)

Tại sao các bộ phận nhỏ tốt hơn? Bởi vì họ dễ dàng hơn để lý do về. Và nếu dễ dàng lý luận về tính đúng đắn, bạn có nhiều khả năng nhận được kết quả chính xác.

Để trích dẫn CAR Hoare:

Có hai cách để xây dựng một thiết kế phần mềm: Một cách là làm cho nó đơn giản đến mức rõ ràng là không có thiếu sót, và cách khác là làm cho nó phức tạp đến mức không có thiếu sót rõ ràng .

Nếu đó là lý do, tại sao mọi người sẽ xây dựng một giải pháp nguyên khối hoặc phức tạp không cần thiết? Hoare cung cấp câu trả lời trong câu tiếp theo:

Phương pháp đầu tiên là khó khăn hơn nhiều.

Và sau đó trong cùng một nguồn (Bài giảng Giải thưởng Turing năm 1980):

Giá của độ tin cậy là sự theo đuổi của sự đơn giản tối đa. Đó là một cái giá mà những người rất giàu khó trả nhất.

Đây không phải là một câu hỏi với một câu trả lời có hoặc không. Câu hỏi không chỉ là dễ bảo trì, nó còn là một câu hỏi sử dụng hiệu quả các kỹ năng.

Nói chung, một ứng dụng nguyên khối được viết tốt là hiệu quả. Giao tiếp giữa các quá trình và liên thiết bị không rẻ. Phá vỡ một quá trình duy nhất làm giảm hiệu quả. Tuy nhiên, thực thi mọi thứ trên một bộ xử lý có thể làm quá tải bộ xử lý và làm chậm hiệu suất. Đây là vấn đề khả năng mở rộng cơ bản. Khi mạng vào hình ảnh, vấn đề trở nên phức tạp hơn.

Một ứng dụng nguyên khối được viết tốt có thể hoạt động hiệu quả như một quy trình duy nhất trên một máy chủ có thể dễ dàng duy trì và không có lỗi, nhưng vẫn không được sử dụng hiệu quả các kỹ năng mã hóa và kiến ​​trúc. Bước đầu tiên là chia quy trình thành các thư viện vẫn thực thi như cùng một quy trình, nhưng được mã hóa độc lập, tuân theo các quy tắc gắn kết và khớp nối lỏng lẻo. Một công việc tốt ở cấp độ này cải thiện khả năng bảo trì và hiếm khi ảnh hưởng đến hiệu suất.

Giai đoạn tiếp theo là chia nguyên khối thành các quy trình riêng biệt. Điều này là khó hơn bởi vì bạn nhập vào lãnh thổ khó khăn. Thật dễ dàng để giới thiệu lỗi điều kiện cuộc đua. Chi phí liên lạc tăng lên và bạn phải cẩn thận với "giao diện trò chuyện". Phần thưởng rất tuyệt vời vì bạn phá vỡ một rào cản về khả năng mở rộng, nhưng khả năng khiếm khuyết cũng tăng lên. Các ứng dụng đa quy trình dễ duy trì hơn ở cấp độ mô-đun, nhưng hệ thống tổng thể phức tạp hơn và khó khắc phục sự cố hơn. Các bản sửa lỗi có thể rất phức tạp.

Khi các quy trình được phân phối cho các máy chủ riêng biệt hoặc thực hiện kiểu đám mây, các vấn đề sẽ trở nên khó khăn hơn và phần thưởng lớn hơn. Khả năng mở rộng tăng vọt. (Nếu bạn đang xem xét việc triển khai đám mây không mang lại khả năng mở rộng, hãy suy nghĩ kỹ.) Nhưng những vấn đề xảy ra ở giai đoạn này có thể cực kỳ khó xác định và suy nghĩ thấu đáo.

Không . nó không làm cho nó dễ dàng hơn để duy trì. Nếu bất cứ điều gì chào đón nhiều vấn đề hơn.

Tại sao?

• Các chương trình không trực giao mà họ cần để bảo vệ lẫn nhau làm việc cho đến nay là hợp lý, điều này hàm ý một sự hiểu biết chung.
• Nhiều mã của cả hai chương trình là giống hệt nhau. Bạn đang duy trì một thư viện chia sẻ chung, hay duy trì hai bản sao riêng biệt?
• Bây giờ bạn có hai nhóm phát triển. Họ giao tiếp thế nào?

• Bây giờ bạn có hai sản phẩm cần:

  • một kiểu giao diện người dùng chung, các cơ chế tương tác, v.v ... Vì vậy, bây giờ bạn có vấn đề về thiết kế. (Làm thế nào để các nhóm dev liên lạc lại?)
  • khả năng tương thích ngược (có thể nhập modeller v1 vào animator v3 không?)
  • tích hợp mạng / đám mây (nếu là một tính năng) hiện phải được cập nhật trên gấp đôi số sản phẩm.

• Bây giờ bạn có ba thị trường tiêu dùng: Modeller, Animators và Modeller Animators

  • Họ sẽ có những ưu tiên xung đột
  • Họ sẽ có những nhu cầu hỗ trợ mâu thuẫn
  • Họ sẽ có phong cách sử dụng mâu thuẫn
• Các Modeller Animators có phải mở hai ứng dụng riêng biệt để hoạt động trên cùng một tệp không? Có ứng dụng thứ ba với cả hai chức năng, một ứng dụng có tải các chức năng của ứng dụng kia không?
• Vân vân...

Điều đó có nghĩa là các cơ sở mã nhỏ hơn dễ bảo trì hơn ở cấp ứng dụng, bạn sẽ không được ăn trưa miễn phí. Đây là vấn đề tương tự tại trung tâm của Micro-Service / Any-Modular-Architecture. Nó không phải là thuốc chữa bách bệnh, khó bảo trì ở cấp ứng dụng được giao dịch cho các khó khăn bảo trì ở cấp phối hợp. Những vấn đề đó vẫn là vấn đề, chúng không còn trong cơ sở mã nữa, chúng sẽ cần phải được tránh hoặc giải quyết.

Nếu việc giải quyết vấn đề ở cấp độ phối hợp đơn giản hơn thì giải quyết nó ở mỗi cấp độ ứng dụng thì việc chia nó thành hai cơ sở mã và giải quyết các vấn đề phối hợp là điều hợp lý.

Nếu không, chỉ cần không làm điều đó, bạn sẽ được phục vụ tốt hơn bằng cách cải thiện tính mô đun bên trong của chính ứng dụng. Đẩy các phần mã thành gắn kết và dễ dàng hơn để duy trì các thư viện mà ứng dụng hoạt động như một plugin. Xét cho cùng, một tảng đá chỉ là lớp phối hợp của một cảnh quan thư viện.

Có rất nhiều câu trả lời hay nhưng vì gần như đã chia tay nên tôi cũng sẽ ném mũ vào vòng.

Theo kinh nghiệm của tôi là một kỹ sư phần mềm, tôi đã thấy đây không phải là một vấn đề đơn giản. Nó thực sự phụ thuộc vào kích thước , quy mô và mục đích của ứng dụng. Các ứng dụng cũ hơn theo quán tính cần thiết để thay đổi chúng, nói chung là nguyên khối vì đây là một thông lệ trong một thời gian dài (Maya sẽ đủ điều kiện trong danh mục này). Tôi giả sử bạn đang nói về các ứng dụng mới hơn nói chung.

Trong các ứng dụng đủ nhỏ, ít nhiều liên quan đến đơn lẻ, chi phí cần thiết để duy trì nhiều bộ phận riêng biệt thường vượt quá tiện ích của việc tách. Nếu nó có thể được duy trì bởi một người, nó có thể được làm nguyên khối mà không gây ra quá nhiều vấn đề. Ngoại lệ cho quy tắc này là khi bạn có nhiều phần khác nhau (phần đầu, phần cuối, có lẽ một số lớp dữ liệu ở giữa) được phân tách thuận tiện (về mặt logic).

Trong các ứng dụng rất quan tâm thậm chí rất lớn, việc chia nhỏ nó có ý nghĩa trong trải nghiệm của tôi. Bạn có lợi ích trong việc giảm một tập hợp con của lớp lỗi có thể để đổi lấy các lỗi khác (đôi khi dễ giải quyết hơn). Nói chung, bạn cũng có thể có các nhóm người làm việc riêng rẽ giúp cải thiện năng suất. Tuy nhiên, nhiều ứng dụng ngày nay được phân chia khá tốt, đôi khi gây bất lợi cho chính họ. Tôi cũng đã ở trong các đội nơi ứng dụng được chia thành nhiều dịch vụ không cần thiết đến mức nó giới thiệu rất nhiều chi phí khi mọi thứ ngừng nói chuyện với nhau. Ngoài ra, việc phải nắm giữ tất cả kiến ​​thức về cách mỗi phần nói chuyện với các phần khác trở nên khó khăn hơn nhiều với mỗi lần phân chia liên tiếp. Có một sự cân bằng, và như bạn có thể nói bằng các câu trả lời ở đây, cách làm không rõ ràng lắm,

Đối với các ứng dụng UI, không có khả năng giảm tổng số lỗi nhưng sẽ chuyển sự cân bằng của hỗn hợp lỗi sang các vấn đề do giao tiếp gây ra.

Nói về người dùng phải đối mặt với các ứng dụng / trang web UI - người dùng cực kỳ không kiên nhẫn và yêu cầu thời gian phản hồi thấp. Điều này làm cho bất kỳ sự chậm trễ truyền thông thành lỗi. Kết quả là người ta sẽ giao dịch giảm các lỗi tiềm ẩn do giảm độ phức tạp của một thành phần duy nhất với các lỗi rất khó và yêu cầu về thời gian của quá trình giao tiếp chéo / máy chéo.

Nếu các đơn vị dữ liệu mà chương trình xử lý lớn (ví dụ như hình ảnh) thì bất kỳ độ trễ quá trình chéo nào sẽ dài hơn và khó loại bỏ hơn - một cái gì đó như "áp dụng chuyển đổi thành hình ảnh 10mb" sẽ ngay lập tức tăng thêm + 20mb IO / mạng chuyển đổi thành 2 từ định dạng trong bộ nhớ sang định dạng serializabe và ngược lại. Bạn thực sự không thể làm gì nhiều để che giấu thời gian cần thiết để làm như vậy với người dùng.

Ngoài ra, bất kỳ giao tiếp nào và đặc biệt là IO của đĩa đều chịu sự kiểm tra của AntiVirus / Tường lửa - điều này chắc chắn sẽ thêm một lớp lỗi khó tái tạo và thậm chí nhiều sự chậm trễ hơn.

Chia tách "chương trình" nguyên khối tỏa sáng trong đó sự chậm trễ trong giao tiếp là không nghiêm trọng hoặc không thể tránh khỏi

• xử lý hàng loạt thông tin song song trong đó bạn có thể trao đổi các độ trễ nhỏ thêm để cải thiện đáng kể các bước riêng lẻ (đôi khi loại bỏ nhu cầu cho các thành phần tùy chỉnh bằng cách sử dụng ngoài giá một lần). Dấu chân bước nhỏ riêng lẻ có thể cho phép bạn sử dụng nhiều máy rẻ hơn thay vì một máy đắt tiền chẳng hạn.
• tách các dịch vụ nguyên khối thành các dịch vụ vi mô ít kết hợp hơn - gọi song song một số dịch vụ thay vì một dịch vụ nhiều khả năng sẽ không thêm độ trễ (thậm chí có thể giảm thời gian chung nếu mỗi cá nhân nhanh hơn và không có phụ thuộc)
• di chuyển ra khỏi các hoạt động mà người dùng mong đợi sẽ mất nhiều thời gian - hiển thị cảnh / phim 3d phức tạp, tính toán các số liệu phức tạp về dữ liệu, ...
• tất cả các loại "tự động hoàn thành", "kiểm tra chính tả" và các công cụ hỗ trợ tùy chọn khác có thể và thường được thực hiện bên ngoài - ví dụ rõ ràng nhất là đề xuất tự động url của trình duyệt nơi đầu vào của bạn gửi đến dịch vụ bên ngoài (công cụ tìm kiếm) mọi lúc .

Lưu ý rằng điều này áp dụng cho các ứng dụng trên máy tính để bàn cũng như các trang web - phần người dùng phải đối mặt với chương trình có xu hướng "nguyên khối" - tất cả mã tương tác người dùng được liên kết với một phần dữ liệu thường chạy trong một quy trình duy nhất (không phải là bất thường để phân tách các quy trình trên cơ sở từng phần dữ liệu như trang HTML hoặc hình ảnh nhưng nó trực giao với câu hỏi này). Ngay cả đối với hầu hết các trang web cơ bản có đầu vào của người dùng, bạn sẽ thấy logic xác thực chạy ở phía máy khách ngay cả khi làm cho phía máy chủ sẽ có tính mô đun hơn và giảm độ phức tạp / sao chép mã.

[Nó] có giúp ngăn ngừa lỗi không?

Ngăn chặn? Vâng, không, không thực sự.

• Nó giúp phát hiện lỗi .
  Cụ thể là tất cả các lỗi mà bạn thậm chí không biết là mình có, mà bạn chỉ phát hiện ra khi bạn cố gắng chia toàn bộ mớ hỗn độn đó thành các phần nhỏ hơn. Vì vậy, theo một cách nào đó, nó đã ngăn những con bọ đó xuất hiện trong sản xuất - nhưng những con bọ đã ở đó.
• Nó giúp giảm tác động của lỗi .
  Lỗi trong các ứng dụng nguyên khối có khả năng làm sập toàn bộ hệ thống và khiến người dùng không tương tác với ứng dụng của bạn. Nếu bạn chia ứng dụng đó thành các thành phần, hầu hết các lỗi sẽ thiết kế củabyby chỉ ảnh hưởng đến một trong các thành phần.
• Nó tạo ra một kịch bản cho các lỗi mới .
  Nếu bạn muốn giữ trải nghiệm của người dùng như cũ, bạn sẽ cần bao gồm logic mới cho tất cả các thành phần đó để giao tiếp (thông qua các dịch vụ REST, thông qua các cuộc gọi hệ điều hành, những gì có bạn) để chúng có thể tương tác liền mạch từ POV của người dùng.
  Một ví dụ đơn giản: ứng dụng nguyên khối của bạn cho phép người dùng tạo mô hình và làm động nó mà không cần rời khỏi ứng dụng. Bạn chia ứng dụng thành hai thành phần: mô hình hóa và hoạt hình. Bây giờ người dùng của bạn phải xuất mô hình của ứng dụng mô hình thành một tệp, sau đó tìm tệp và sau đó mở nó bằng ứng dụng hoạt hình ... Hãy đối mặt với nó, một số người dùng sẽ không thích điều đó, vì vậy bạn phải đưa logic mới cho ứng dụng mô hình hóa để xuất tệp vàtự động khởi chạy ứng dụng hoạt hình và làm cho nó mở tệp. Và logic mới này, đơn giản như nó có thể, có thể có một số lỗi liên quan đến tuần tự hóa dữ liệu, truy cập tệp và quyền, người dùng thay đổi đường dẫn cài đặt của ứng dụng, v.v.
• Đó là lý do hoàn hảo để áp dụng tái cấu trúc rất cần thiết .
  Khi bạn quyết định tách một ứng dụng nguyên khối thành các thành phần nhỏ hơn, bạn (hy vọng) sẽ làm như vậy với nhiều kiến ​​thức và kinh nghiệm về hệ thống hơn so với khi nó được thiết kế lần đầu tiên và nhờ đó bạn có thể áp dụng một số bộ cấu trúc để tạo mã sạch hơn, đơn giản hơn, hiệu quả hơn, đàn hồi hơn, an toàn hơn. Và việc tái cấu trúc này có thể, theo một cách nào đó, giúp ngăn ngừa lỗi. Tất nhiên, bạn cũng có thể áp dụng cách tái cấu trúc tương tự cho ứng dụng nguyên khối để ngăn ngừa các lỗi tương tự, nhưng bạn không vì nó quá nguyên khối đến nỗi bạn sợ chạm vào thứ gì đó trong giao diện người dùng và phá vỡ logic kinh doanh \ _ () _ /

Vì vậy, tôi sẽ không nói rằng bạn đang ngăn chặn lỗi chỉ bằng cách phá vỡ một ứng dụng nguyên khối thành các thành phần nhỏ hơn, nhưng bạn thực sự làm cho việc tiếp cận điểm dễ dàng hơn trong đó các lỗi có thể dễ dàng ngăn chặn hơn.