Tách các dự án java


12

Tôi có một dự án java lớn và chúng tôi sử dụng maven cho chu trình xây dựng của mình. Dự án này được sử dụng rộng rãi - trong các dự án khác, trong các ứng dụng khác nhau, một số dự án được chứa trong đó và một số dự án khác ... Thành thật mà nói, đó là một mớ hỗn độn (các bit khác nhau được thêm vào vào các thời điểm khác nhau mục đích) và tôi muốn dọn dẹp nó một chút. Ngoài ra, nó chưa được kiểm tra đầy đủ (rất nhiều bit đã được thêm vào mà không có kiểm thử đơn vị và tích hợp thích hợp) và có một số thử nghiệm mất nhiều thời gian để chạy hoặc không thực sự vượt qua ... (uh-oh) - vì vậy các thử nghiệm được tắt trong chu trình xây dựng maven (một lần nữa, uh-oh).

Tôi đang suy nghĩ về việc tách dự án lớn này thành các dự án cụ thể nhỏ hơn, sao cho tiểu dự án 'cuối cùng' (hoặc một số tiểu dự án) sẽ nhận các dự án phụ khác nhau mà nó cần.

Suy nghĩ của tôi như sau:

  • nếu tôi tách dự án lớn thành các tiểu dự án khác nhau, điều này cho thấy rõ trách nhiệm của từng dự án là gì.
  • bằng cách tách thành các tiểu dự án, sau đó tôi có thể dọn sạch thử nghiệm của từng tiểu dự án và bật thử nghiệm cho dự án phụ đó trong chu trình xây dựng maven.

Tôi hơi lo ngại về những gì tác động này có thể có trong thời gian xây dựng.

  • Việc áp đặt một cấu trúc lên dự án lớn (tức là vào các dự án con nhỏ hơn) sẽ làm chậm trình biên dịch?

Ngoài ra, tôi có một chút lo ngại về tác động của việc này có thể có thời gian chỉnh sửa trong IDE (chủ yếu chúng tôi sử dụng Intellij). Intellij dường như xây dựng từng dự án lần lượt thông qua cây phụ thuộc - tức là nếu C phụ thuộc vào B phụ thuộc vào A và tôi thay đổi A, nó sẽ không cố gắng xây dựng B trừ khi A biên dịch, v.v. Có thể cho rằng đó là lợi thế, nhưng tôi đã thấy rằng nếu - ví dụ, tôi thay đổi giao diện trong A được sử dụng rộng rãi trong B và C, phải mất một thời gian để sửa tất cả các lỗi từ thay đổi đó ...

Một câu hỏi khác là làm thế nào để sử dụng các lớp học nhà máy. Một số khía cạnh của dự án phụ thuộc vào lọ bên ngoài. Thỉnh thoảng (rất may là không thường xuyên) những điều này được cập nhật và chúng tôi phải di chuyển. Chúng tôi có xu hướng xử lý việc này bằng cách sử dụng lớp Factory chỉ ra các phiên bản chính xác của mã bên ngoài (vì vậy chúng tôi không phải thay đổi tất cả các triển khai trong toàn bộ cơ sở mã).

Hiện tại đây là tất cả trong dự án lớn, nhưng tôi nghĩ rằng bằng cách chuyển sang các dự án phụ, tôi có thể phát triển một dự án mới để thực hiện mã bên ngoài mới, đảm bảo rằng dự án phụ có đầy đủ chức năng và được thử nghiệm, và sau đó chuyển đổi các phụ thuộc / lớp nhà máy trong dự án người dùng. Tuy nhiên, điều này trở nên phức tạp hơn khi sử dụng rộng rãi các giao diện trong suốt dự án lớn. Ví dụ

  • tiểu dự án A - chứa các giao diện
  • tiểu dự án B - phụ thuộc vào A cho các giao diện và bình ngoài cũ
  • tiểu dự án C - phụ thuộc vào B (và do đó là A và bình ngoài cũ) và chứa một lớp Factory sử dụng các triển khai giao diện của B

Nếu tôi cần thay đổi bình bên ngoài của B, tôi có thể:

  • tạo dự án con B_ii - một lần nữa phụ thuộc vào A, và bây giờ jar bên ngoài mới
  • một khi đầy đủ chức năng, tôi có thể thêm phụ thuộc của C vào B_ii và thay đổi lớp Factory để sử dụng các triển khai giao diện mới.
  • khi tất cả đều hoạt động, sau đó tôi có thể loại bỏ sự phụ thuộc của C vào B ban đầu và nếu muốn, hãy loại bỏ tiểu dự án B.

  • Đó có phải là một cách hợp lý để đi về điều này?

Vì vậy, nói chung, câu hỏi của tôi là:

  • Có ai có bất kỳ kinh nghiệm về việc phá vỡ các dự án lớn? Có bất cứ lời khuyên / thủ thuật nào mà bạn muốn chia sẻ không?
  • Điều này có tác động gì đến thời gian phát triển và xây dựng của bạn?
  • Bạn có thể đưa ra lời khuyên nào về việc cấu trúc một dự án như vậy?

Lưu ý rằng bạn có thể tạo một dự án mẹ với A, B và C được kiểm tra riêng bên cạnh nhau. Điều này cho phép, ví dụ IntelliJ có cả ba bộ nhớ cùng một lúc và thực hiện tái cấu trúc qua các ranh giới mô-đun.
Thorbjørn Ravn Andersen

Câu trả lời:


10

Tôi sẽ thực hiện cắt giảm nhanh đầu tiên tại đây (Q BTW tuyệt vời!):

Việc áp đặt một cấu trúc lên dự án lớn (tức là vào các dự án con nhỏ hơn) sẽ làm chậm trình biên dịch?

Không đủ để nó quan trọng, chi phí thực sự nằm trong các yêu cầu của Maven.

Ngoài ra, tôi có một chút lo ngại về tác động của việc này có thể có thời gian chỉnh sửa trong IDE (chủ yếu chúng tôi sử dụng Intellij). Intellij dường như xây dựng từng dự án lần lượt thông qua cây phụ thuộc - tức là nếu C phụ thuộc vào B phụ thuộc vào A và tôi thay đổi A, nó sẽ không cố gắng xây dựng B trừ khi A biên dịch, v.v. Có thể cho rằng đó là lợi thế, nhưng tôi đã thấy rằng nếu - ví dụ, tôi thay đổi giao diện trong A được sử dụng rộng rãi trong B và C, phải mất một thời gian để sửa tất cả các lỗi từ thay đổi đó ...

Các IDE khác nhau có các thế mạnh khác nhau liên quan đến các ràng buộc Maven và quản lý phụ thuộc. Trạng thái chơi hiện tại dường như là nó hầu như chỉ hoạt động trên Eclipse, Netbeans và IntelliJ mới nhất - nhưng bạn sẽ phải dạy cho các nhà phát triển của mình một cách khẩn cấp gấp đôi "Làm mới các tệp nguồn từ đĩa và xây dựng lại tất cả các dự án maven liên quan".

Tôi thấy rằng tôi phải làm điều đó ngày càng ít hơn trong những ngày này. Có một ổ SSD tạo ra sự khác biệt lớn ở đây BTW.

snip đoạn văn nhà máy

Quản lý phụ thuộc là vô cùng quan trọng, bất kể sử dụng công nghệ nào (Maven / Ivy / bất cứ thứ gì) để giúp bạn thực hiện nó.

Tôi sẽ bắt đầu bằng cách lấy báo cáo mở rộng ra khỏi plugin phụ thuộc Maven và nắm bắt những gì bạn có. Nói chung, bạn đặt sự phụ thuộc trong quản lý phụ thuộc của POM càng cao trong chuỗi thức ăn càng tốt, nhưng không cao hơn. Vì vậy, nếu hai trong số các mô hình con của bạn sử dụng một phụ thuộc bên ngoài, sau đó lôi nó vào POM gốc của chúng và cứ thế tiếp tục.

Nâng cấp JAR bên ngoài phải luôn luôn được thực hiện như một dự án nhỏ thích hợp. Đánh giá lý do tại sao bạn nâng cấp, thay đổi mã nguồn để tận dụng bất kỳ tính năng / sửa lỗi mới nào, v.v. Chỉ cần trả lại phiên bản mà không có phân tích này và công việc sẽ khiến bạn gặp rắc rối.

Vì vậy, nói chung, câu hỏi của tôi là:

Có ai có bất kỳ kinh nghiệm về việc phá vỡ các dự án lớn? Có bất kỳ> mẹo / thủ thuật nào mà bạn muốn chia sẻ không?

  • Giao diện và tiêm phụ thuộc là bạn của bạn.
  • Cuốn sách của Michael Feather về cách đối phó hiệu quả với mã kế thừa là phải đọc.
  • Kiểm tra tích hợp là bạn của bạn
  • Việc tách các dự án con thành foo-api (chỉ giao diện!) Và foo-core và việc có các mô-đun chỉ phụ thuộc vào foo-api giúp rất nhiều và thực thi sự tách biệt
  • Mô-đun Jboss và / hoặc OSGi có thể giúp thực thi phân tách sạch

Điều này có tác động gì đến thời gian phát triển và xây dựng của bạn?

Tác động rất nhỏ đến nhà phát triển và thời gian xây dựng - một mức tăng lớn trong thời gian cho đường ống phân phối liên tục chung của chúng tôi.

Bạn có thể đưa ra lời khuyên nào về việc cấu trúc một dự án như vậy?

Làm những điều nhỏ bé đúng và những điều lớn có xu hướng rơi ra sạch sẽ sau đó. Vì vậy, hãy phân chia mọi thứ từng chút một - đừng thực hiện tái cấu trúc toàn bộ lô trừ khi bạn có tỷ lệ bao phủ cao với các bài kiểm tra tích hợp của mình.

Viết các bài kiểm tra tích hợp trước khi chia - bạn nên ít nhiều nhận được cùng một kết quả sau khi chia.

Vẽ sơ đồ mô-đun bạn có bây giờ và nơi bạn muốn đến. Thiết kế các bước trung gian.

Đừng bỏ cuộc - một số cạo Yak bây giờ xây dựng nền tảng cho việc có thể để "nhanh chóng xây dựng và cấu trúc lại mà không sợ" Shameless plug -> từ Ben và tôi là The Well-căn cứ Java Developer .

May mắn nhất!


0

Tôi đảm nhận điều này chỉ riêng biệt khi cần thiết. Tuy nhiên, điều đó đưa đến câu hỏi tiếp theo: Làm thế nào để tôi xác định nếu cần thiết?

  • Khi tạo phẩm khác nhau (nghĩa là không xây dựng EAR, WAR, JAR, thử nghiệm tích hợp-jar trong cùng một dự án).
  • Khi trong quá trình phân tách, bạn nhận thấy rằng một số mã cần tồn tại trong nhiều hơn một thành phần tái cấu trúc chúng thành một mã mới.
  • Khi một số dự án khác bên ngoài nhóm của bạn muốn sử dụng một cái gì đó bạn có trong dự án của bạn.

Một lý do là các nhà phát triển phải đối phó với nhiều dự án và cố gắng tìm ra ngoài gói Java là dự án nào nên thuộc về. Tôi đã tham gia vào các dự án nơi nó thực sự thiếu máu và có một dự án chỉ có bốn lớp thực hiện một chức năng chỉ vì đó là hướng kiến ​​trúc. Điều này cũng đã trở lại trước khi Maven phổ biến vì vậy các đường dẫn lớp và những gì không cần phải được thiết lập trên cả tập lệnh IDE và Ant.

Lý do khác là bạn sẽ có nhiều bộ phận chuyển động hơn để xử lý các vấn đề về hệ thống ống nước xung quanh và bạn có thể có spaghetti phụ thuộc trước khi bạn biết.

Tái cấu trúc cũng dễ dàng hơn trong một dự án hơn là trên các dự án.

Nếu thời gian xây dựng là một vấn đề thì chỉ cần cung cấp phần cứng tốt hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.