Giải pháp phòng thu trực quan với số lượng lớn các dự án

Question

Tôi thấy các nhà phát triển thường xuyên phát triển dựa trên giải pháp chứa tất cả các dự án (27) trong một hệ thống. Điều này làm tăng các vấn đề về thời gian xây dựng (5 phút), hiệu năng của Visual Studio (chẳng hạn như độ trễ intellisense), cộng với nó không buộc nhà phát triển phải suy nghĩ về phụ thuộc dự án (cho đến khi họ nhận được một vấn đề tham chiếu vòng tròn).

Có nên chia nhỏ một giải pháp như thế này thành các giải pháp nhỏ hơn có khả năng tương thích và thử nghiệm độc lập với giải pháp "mẹ" không? Có bất kỳ cạm bẫy tiềm ẩn nào với cách tiếp cận này không?

Answer 1

Hãy để tôi trình bày lại câu hỏi của bạn:

có phải là một ý tưởng tốt để phá vỡ một giải pháp như thế này vào các giải pháp nhỏ

Các MSDN article you linked làm cho một tuyên bố khá rõ ràng:

Quan trọng Trừ khi bạn có lý do rất tốt để sử dụng mô hình đa giải pháp, bạn nên tránh điều này và chấp nhận eith er một mô hình giải pháp đơn lẻ hoặc trong các hệ thống lớn hơn, một mô hình giải pháp đơn lẻ được phân đoạn. Đây là những đơn giản hơn để làm việc và cung cấp một số lợi thế đáng kể so với mô hình đa giải pháp, được thảo luận trong các phần sau.

Ngoài ra, bài viết đề nghị bạn luôn có có một tệp giải pháp "chính" duy nhất trong quá trình tạo.

Có bất kỳ cạm bẫy tiềm ẩn nào với phương pháp này không?

Bạn sẽ phải đối phó với các vấn đề sau (mà thực sự có thể được khá khó khăn để làm, cùng một nguồn là trích dẫn ở trên):

Mô hình đa giải pháp bị những nhược điểm sau đây :

• bạn đang buộc phải sử dụng tài liệu tham khảo tập tin khi bạn cần phải tham khảo một hội đồng được tạo ra bởi một dự án trong một giải pháp riêng biệt. Những điều này (không giống như tham chiếu dự án) không tự động thiết lập phụ kiện xây dựng . Điều này có nghĩa là bạn phải giải quyết vấn đề xây dựng giải pháp đơn đặt hàng trong tập lệnh xây dựng hệ thống. Trong khi điều này có thể được quản lý, nó thêm sự phức tạp thêm vào quá trình xây dựng.
• Bạn cũng bị buộc tham chiếu đến cấu hình cụ thể của DLL (ví dụ: Bản phát hành hoặc Gỡ lỗi phiên bản). Tham khảo dự án tự động quản lý việc này và tham chiếu cấu hình hiện đang hoạt động trong Visual Studio.NET.
• Khi bạn làm việc với các giải pháp đơn lẻ, bạn có thể lấy mã mới nhất (có lẽ trong các dự án khác) đã phát triển bởi các thành viên khác trong nhóm để thực hiện thử nghiệm tích hợp cục bộ. Bạn có thể xác nhận rằng không có gì xảy ra trước khi bạn kiểm tra mã của bạn trở lại thành VSS sẵn sàng cho việc xây dựng hệ thống tiếp theo . Trong một hệ thống đa giải pháp , điều này khó thực hiện hơn, vì bạn có thể kiểm tra giải pháp của mình chỉ với các giải pháp khác bằng cách sử dụng kết quả của hệ thống trước đó .

Answer 2

Nó chắc chắn có những ưu điểm và nhược điểm của nó, phá vỡ một giải pháp thành nhiều dự án giúp bạn tìm thấy những gì bạn đang tìm kiếm một cách dễ dàng, nếu bạn đang tìm kiếm một cái gì đó về báo cáo bạn vào dự án báo cáo. nó cũng cho phép các đội lớn để chia công việc theo cách như vậy mà không ai làm điều gì đó để phá vỡ một ai đó mã của khác ...

Điều này đặt ra vấn đề về xây dựng thời gian

bạn có thể tránh điều đó bằng cách chỉ xây dựng các dự án mà bạn đã sửa đổi và để máy chủ CI thực hiện toàn bộ quá trình xây dựng

Answer 3

Chúng tôi có một giải pháp ~ 250 dự án.

Không sao, sau khi cài đặt bản vá cho Visual Studio 2005 để xử lý nhanh chóng với các giải pháp cực lớn [TODO add link].

Chúng tôi cũng có các giải pháp nhỏ hơn cho các đội có lựa chọn dự án yêu thích của họ, nhưng mọi dự án được bổ sung cũng sẽ được thêm vào giải pháp chính và nhiều người thích làm việc với nó.

Chúng tôi lập trình lại phím tắt F7 (xây dựng) để xây dựng dự án khởi động thay vì toàn bộ giải pháp. Cái đó tốt hơn.

Thư mục giải pháp dường như giải quyết được vấn đề tìm kiếm mọi thứ tốt.

Phụ thuộc chỉ được thêm vào các dự án cấp cao nhất (EXE và DLL) vì, khi bạn có thư viện tĩnh, nếu A là phụ thuộc của B và B là phụ thuộc của C, A có thể thường không cần phụ thuộc của C (để làm cho mọi thứ biên dịch và chạy một cách chính xác) và theo cách này, phụ thuộc circullar là OK cho trình biên dịch (mặc dù rất xấu cho sức khỏe tâm thần).

Tôi hỗ trợ có ít thư viện hơn, ngay cả khi có một thư viện có tên là "thư viện". Tôi thấy không có lợi thế đáng kể của việc tối ưu hóa bộ nhớ quá trình bằng cách đưa "chỉ những gì nó cần", và mối liên kết nên làm điều đó anyway trên cấp độ tập tin đối tượng.

Answer 4

Lần duy nhất tôi thực sự thấy cần nhiều giải pháp là cách ly chức năng. Các yêu cầu libs cho một cửa sổ dịch vụ có thể khác với một trang web. Mỗi giải pháp nên được tối ưu hóa để tạo ra một trang web thực thi hoặc trang web, IMO. Nó tăng cường tách mối quan tâm và làm cho nó dễ dàng để xây dựng lại một phần chức năng của ứng dụng mà không xây dựng mọi thứ khác cùng với nó.

Answer 5

Hiệu suất IntelliSense nên khá hơn một chút so với VS2010 so với VS2008. Ngoài ra, tại sao bạn cần phải xây dựng lại toàn bộ giải pháp tất cả các thời gian? Điều đó sẽ chỉ xảy ra nếu bạn thay đổi một cái gì đó gần gốc của cây phụ thuộc, nếu không bạn chỉ cần xây dựng dự án mà bạn đang làm việc.

Tôi luôn tìm thấy nó hữu ích để có mọi thứ trong một giải pháp vì tôi có thể điều hướng toàn bộ cơ sở mã dễ dàng.

Answer 6

Visual Studio 2010 Ultimate có một số công cụ để giúp bạn hiểu rõ hơn và quản lý phụ thuộc vào mã hiện tại:

• đồ thị phụ thuộc và Kiến trúc Explorer
• trình tự sơ đồ
• sơ đồ lớp và xác nhận

Để biết thêm thông tin, hãy xem Exploring Existing Code. Visualization and Modeling Feature Pack cung cấp hỗ trợ đồ thị phụ thuộc cho mã C++ và C.

Answer 7

Bạn nên chia nhỏ một giải pháp như thế này thành các giải pháp nhỏ hơn có khả năng tương thích và thử nghiệm độc lập với giải pháp "mẹ"? Có bất kỳ cạm bẫy tiềm ẩn nào với cách tiếp cận này không?

Có nó là một ý tưởng tốt vì:

• Bạn không muốn VS để làm chậm về một giải pháp với hàng chục dự án VS.
• Có thể thú vị khi chỉ tập trung vào một phần của mã, điều này thực thi khái niệm về địa phương mã là một điều tốt.

Nhưng điều quan trọng đầu tiên để đấu tranh là có ít dự án/hội đồng VS nhất có thể. Công ty của tôi đã xuất bản hai số free two white books giải thích sự ủng hộ/khuyết điểm của việc sử dụng các assembly/VS project/namespaces để phân vùng một cơ sở mã lớn.

• Partitioning code base through .NET assemblies and Visual Studio projects (8 trang)
• Defining .NET Components with Namespaces (7 trang)

Các trắng cuốn sách đầu tiên cũng giải thích rằng VS là khá chậm khi làm việc với một giải pháp với hàng chục dự án, và cho thấy thủ đoạn về cách khắc phục sự chậm chạp này.