Làm thế nào để bạn tiếp cận các xung đột phụ thuộc quá độ chỉ được biết đến trong thời gian chạy? [đóng cửa]

Làm thế nào để bạn thường tiếp cận các vấn đề phụ thuộc quá độ xảy ra trong thời gian chạy trong các dự án phần mềm lớn?

Trong ba tuần qua, tôi đã cố gắng khởi động một thành phần của một phần mềm lớn bên trong một thành phần khác của phần mềm, nhưng nó bị chết liên tục do các vấn đề phụ thuộc quá độ chỉ được biết đến trong thời gian chạy.

Theo các vấn đề phụ thuộc quá độ, tôi có nghĩa là các phụ thuộc nhất định của các phụ thuộc của dự án nhất định xung đột với các phụ thuộc khác trong thời gian chạy, gây mất ổn định hoặc thất bại ngay lập tức.

Có hàng trăm, trên hàng trăm phụ thuộc được sử dụng và có khoảng 50 dự án con được liên kết với công cụ được các nhóm khác làm việc riêng rẽ, trong đó tất cả các mô-đun có các phụ thuộc lồng nhau sâu sắc. Không ai biết tất cả các dự án con được sử dụng để làm gì, với quy mô và mức độ phức tạp của dự án.

Trong tình huống này, bạn có cố gắng tạo ra một đại diện trực quan của DAG cho từng phụ thuộc của thành phần bị ảnh hưởng và cố gắng xác định nơi va chạm có thể xảy ra trong thời gian chạy không? Tôi không kiểm soát cách quản lý các phụ thuộc trong các dự án con khác và không thể thay đổi bất kỳ mã Java nào được viết bởi các nhà phát triển khác

Các giải pháp tôi đã đưa ra chỉ hoạt động trong một hoặc hai giờ và sau đó chúng ngừng hoạt động do những thay đổi trong các thành phần ngược dòng. Một ví dụ về một thành phần ngược dòng là một tạo tác mà dự án mà tôi đang làm việc phụ thuộc vào nó được xây dựng ở giai đoạn trước trong đường ống CI.

Theo yêu cầu của người khác , tôi sẽ đưa vào thông tin về công nghệ nào đang được sử dụng, có nguy cơ bị đóng câu hỏi vì cung cấp quá nhiều thông tin hoặc cơ thể trở nên quá dài:

• Maven được sử dụng để quản lý phụ thuộc; và
• Mùa xuân được sử dụng như một container DI;
• Hầu hết các vấn đề phụ thuộc liên quan đến bối cảnh đậu chồng chéo do bối cảnh của các mô-đun khác được tải vào thời gian chạy
• Sản phẩm hoạt động đúng, và có các thử nghiệm đơn vị và kiểm tra tích hợp để tránh sự đúng đắn về chức năng của chương trình

Nói chung, tôi đang tìm kiếm một cách tiếp cận bất khả tri về ngôn ngữ để xác định các cách giải quyết xung đột phụ thuộc mà không liệt kê thông qua tất cả các kết hợp có thể có của các phụ thuộc của dự án nhất định.

Tôi không thể tái kiến ​​trúc dự án, thêm các cổng chất lượng bổ sung, thúc đẩy thay đổi mô hình trên toàn công ty hoặc chuyển đổi ngôn ngữ dưới dạng độ phân giải.

Có thể giải quyết vấn đề của bạn bằng cách sử dụng trình nạp lớp tùy chỉnh để cung cấp cho mỗi mô-đun trong môi trường thực thi riêng của ứng dụng.

Về cơ bản, bạn sẽ xác định một môi trường cốt lõi bao gồm một hạt nhân nhỏ của ứng dụng, cùng với bất kỳ sự phụ thuộc nào được thống nhất trên toàn cầu và tất cả các giao diện cần thiết để các mô-đun giao tiếp với nhau. Sau đó, mỗi mô-đun bạn tải sẽ có trình nạp lớp riêng có thể truy cập (1) lớp từ môi trường thời gian chạy, (2) lớp từ lõi ứng dụng và (3) lớp từ mô-đun đó và các phụ thuộc trực tiếp của nó. Tất cả các giao tiếp giữa các mô-đun đều đi qua các giao diện được xác định trong lõi để không có mô-đun nào phụ thuộc trực tiếp vào mô-đun khác.

Kỹ thuật này được sử dụng trong các máy chủ ứng dụng để cho phép các ứng dụng có các phụ thuộc có thể xung đột, do đó bạn có thể thấy việc triển khai kỹ thuật này, ví dụ, trong Tomcat (và, nếu bạn may mắn, bạn có thể sử dụng Tomcat thực hiện với ít thay đổi).

Tôi chưa bao giờ làm việc với Maven hoặc Spring, nhưng để đưa ra câu trả lời chung cho một câu hỏi chung: khi gặp vấn đề phụ thuộc, hệ thống của bạn nên được thiết kế để phát hiện chúng vào thời điểm sớm nhất có thể và khi phát hiện ra những vấn đề đó , họ cần được báo hiệu ngay lập tức, bao gồm cả nguyên nhân có thể của họ.

Lý tưởng nhất, thời điểm này không phải là "thời gian chạy sản xuất". Điểm tốt nhất trong thời gian là "xây dựng thời gian", nhưng điều đó dường như là không thể trong trường hợp của bạn. Vì vậy, lựa chọn tốt thứ hai là chạy thử nghiệm thời gian. Bạn nói với chúng tôi rằng có "kiểm tra tích hợp", nhưng vì chúng không phát hiện ra các vấn đề phụ thuộc, nên chúng dường như chưa hoàn chỉnh hoặc chúng không kiểm tra các va chạm phụ thuộc nói chung. Đó là nơi bạn nên bắt đầu cố gắng giải quyết vấn đề.

Hơn nữa, để làm cho các bài kiểm tra hiệu quả hơn, các thành phần của bạn cần "thất bại nhanh" khi có vấn đề phụ thuộc phát sinh. Điều đó có nghĩa là, ngay khi một phụ thuộc được giải quyết và một thành phần được tải, các xung đột phụ thuộc tiềm năng cần được kiểm tra và báo hiệu ngay lập tức. Nếu hệ thống đầu tiên chạy trong một giờ trước khi phát hiện va chạm, sẽ rất khó để phát hiện ra nguyên nhân gây ra sự cố. Tôi không biết liệu Maven / Spring đã cung cấp cho bạn chiến lược "thất bại nhanh" được xây dựng hay chưa, nhưng nếu đây không phải là trường hợp, hãy thử suy nghĩ theo hướng đó.

Để giảm thiểu các vấn đề trong sản xuất, hệ thống của bạn phải được thiết kế để không chết hoàn toàn khi xảy ra xung đột phụ thuộc với một thành phần phụ ít quan trọng hơn. Tất nhiên, không nên che dấu lỗi, nhưng hệ thống nên từ chối tải thành phần đó, ghi nhật ký và / hoặc báo hiệu sự cố và ở trạng thái ổn định. Khi thành phần được tải trước, hệ thống sẽ không ổn định và bạn chỉ phát hiện sự cố sau đó, sau đó bạn có thể sẽ phải tắt máy và khởi động lại hệ thống hoàn toàn, điều mà tôi đoán là điều bạn nên tránh.

Ví dụ: nếu hệ thống của bạn là một cửa hàng Web và mô hình con của bạn cho "đăng ký bản tin" không thể được tải trong vài giờ, thì đó là thứ có thể được chấp nhận dễ dàng hơn như thể toàn bộ cửa hàng không còn hoạt động nữa.

Cuối cùng, điều này có thể không phải là một lựa chọn trong trường hợp của bạn, nhưng nếu các thành phần có thể được thực hiện cách ly tốt hơn với nhau và nếu điều đó có thể tránh va chạm phụ thuộc, đó có thể là một cách tiếp cận đáng để suy nghĩ.

Hãy xem xét điều này tôi chỉ nghĩ lớn tiếng ở đây. Tùy thuộc vào yêu cầu / hạn chế thời gian, tôi có thể xem xét điều này:

1) tạo một danh sách các giao diện và việc triển khai chúng (sử dụng sự phản chiếu, nếu có)

2) tạo ra một loại bao bọc xung quanh DI của bạn. Khi một DI được yêu cầu cung cấp triển khai cụ thể, hãy xem liệu đã có quy tắc DI chưa; nếu quy tắc tồn tại - chỉ cần trả lại những gì DI của bạn cung cấp; mặt khác, nếu có một triển khai giao diện duy nhất và bạn có thể tạo một cá thể - nhật ký và trả về một thể hiện; Nếu không thì đăng nhập và thất bại.

Tôi phụ thuộc vào mức độ tham gia mà bạn muốn nhận, tôi đoán, nhưng cuối cùng bạn chỉ muốn có một danh sách đầy đủ những gì đòi hỏi những gì - giải pháp này cuối cùng sẽ tạo ra danh sách đó.

Tuy nhiên, có thể cho rằng đây là rất nhiều công việc và không đáng tin cậy - điều gì sẽ xảy ra nếu bạn có một điều kiện kỳ ​​quặc đòi hỏi sự phụ thuộc nhất định một lần trong một mặt trăng xanh?

Ý bạn là gì khi bạn nói "những thay đổi trong các thành phần ngược dòng"?

Nếu tôi theo dõi bạn một cách chính xác, vấn đề là mã bạn cần sử dụng có phụ thuộc thời gian chạy vào các mô-đun được thể hiện trong Spring XML, nhưng maven không được nói về chúng. Vì vậy, khi bạn sử dụng chúng, những thứ họ cần (phụ thuộc bắc cầu) không nằm trong đường dẫn lớp của bạn và họ không làm những gì họ nên làm.

Tôi đoán khi bạn hỏi các đồng nghiệp của mình 'làm thế nào để tôi làm việc này?', Họ nói 'rõ ràng bạn cần danh sách 35 mô-đun và phiên bản này , làm sao bạn không biết điều đó?'

Có lẽ khi kiểm thử tích hợp được thực hiện, các mô-đun cần thiết được khai báo là phụ thuộc kiểm tra. Vì vậy, giải pháp có hệ thống là thiết lập kiểm tra các pom thử nghiệm tích hợp để đảm bảo chúng không có gì ngoài các công cụ kiểm tra của bên thứ 3 được tuyên bố là phụ thuộc kiểm tra. Điều này thậm chí có thể được tự động hóa bởi plugin thực thi maven .

Rõ ràng bạn không thể làm điều đó, vì vậy lựa chọn tốt nhất của bạn có thể được tìm thấy ở đây .