Tôi chỉ có thể cho bạn biết ý kiến tổ chức của tôi về vấn đề này. Chúng tôi đang trong quá trình chuyển sang các mô-đun, cho mọi dự án đơn lẻ mà chúng tôi đang thực hiện. Những gì chúng tôi đang xây dựng về cơ bản là các dịch vụ vi mô + một số thư viện máy khách. Đối với các dịch vụ vi mô, việc chuyển đổi sang modulesbằng cách nào đó có mức độ ưu tiên thấp hơn: mã ở đó đã bị cô lập bằng cách nào đó trong bộ chứa docker, vì vậy việc "thêm" các mô-đun vào đó dường như (đối với chúng tôi) không quan trọng lắm. Công việc này đang được thực hiện chậm, nhưng mức độ ưu tiên thấp.
Mặt khác, thư viện khách hàng là một câu chuyện hoàn toàn khác. Tôi không thể cho bạn biết sự lộn xộn mà chúng tôi có đôi khi. Tôi sẽ giải thích một điểm mà tôi ghét trước đây jigsaw. Bạn hiển thị giao diện cho khách hàng, cho mọi người sử dụng. Tự động đó interfacelà public- tiếp xúc với thế giới. Thông thường, những gì tôi làm, sau đó có một số package-privatelớp, không được tiếp xúc với máy khách, sử dụng giao diện đó. Tôi không muốn khách hàng sử dụng nó, nó là nội bộ. Nghe hay không? Sai lầm.
Vấn đề đầu tiên là khi các package-privatelớp đó phát triển và bạn muốn có nhiều lớp hơn, cách duy nhất để ẩn mọi thứ là tạo các lớp trong cùng một gói:
package abc:
-- Usage.java
-- HelperUsage.java
-- FactoryUsage.java
....
Khi nó phát triển (trong trường hợp của chúng tôi là như vậy), những gói đó quá lớn. Bạn nói chuyển sang một gói riêng? Chắc chắn, nhưng sau đó HelperUsagevà FactoryUsagesẽ được publicvà chúng tôi cố gắng tránh điều đó ngay từ đầu.
Vấn đề thứ hai: bất kỳ người dùng / người gọi nào của khách hàng của chúng tôi có thể tạo cùng một tên gói và mở rộng các lớp ẩn đó. Nó đã xảy ra một vài lần với chúng tôi rồi, những lần vui vẻ.
modulesgiải quyết vấn đề này theo một cách hay: publickhông thực sự public nữa; Tôi có thể có friendquyền truy cập thông qua exports tochỉ thị. Điều này làm cho vòng đời và quản lý mã của chúng tôi dễ dàng hơn nhiều. Và chúng tôi thoát khỏi địa ngục classpath. Tất nhiên maven/gradlexử lý điều đó cho chúng tôi là chủ yếu, nhưng khi có vấn đề, nỗi đau sẽ rất thực tế. Cũng có thể có nhiều ví dụ khác.
Điều đó nói rằng, quá trình chuyển đổi vẫn (vẫn) không dễ dàng. Trước hết, mọi người trong nhóm cần phải được liên kết; thứ hai có các rào cản. Hai điểm lớn nhất mà tôi vẫn thấy là: làm thế nào để bạn tách từng mô-đun, dựa trên cái gì, cụ thể là gì? Tôi chưa có câu trả lời chắc chắn. Thứ hai là split-packages, ồ đẹp "cùng một lớp được xuất bởi các mô-đun khác nhau". Nếu điều này xảy ra với các thư viện của bạn, có nhiều cách để giảm thiểu; nhưng nếu đây là những thư viện bên ngoài ... không có dễ dàng.
Nếu bạn phụ thuộc vào jarAvà jarB(các mô-đun riêng biệt), nhưng cả hai đều xuất abc.def.Util, bạn sẽ ngạc nhiên. Tuy nhiên, có nhiều cách để giải quyết vấn đề này. Bằng cách nào đó đau đớn, nhưng có thể giải quyết.
Nhìn chung, kể từ khi chúng tôi chuyển sang mô-đun (và vẫn vậy), mã của chúng tôi đã trở nên sạch hơn nhiều . Và nếu công ty của bạn là công ty "tiên phong", điều này rất quan trọng. Mặt khác, tôi đã từng tham gia vào các công ty bị các kiến trúc sư cấp cao coi là "quá đắt", "không có lợi".